Web Services before .NET - Don't Miss the Point
I've read alot of posts trying to blast "Web Services" into oblivion stating
that enterprise applications relying on a 3rd party web service would be
unreliable and probably make your app crash more often than not. Well guys,
this is a given! Whenever you rely on a subsystem outside of your project
for services, theres always a chance that subsystem might be down! Whether
your using port 80 and standard soap or port 4999 and RMI to connect to your
"resource", the subsystem may not be there to accept the request! Linking
servers that expose services is nothing new, just the fact that the interfaces
and protocols to these services are approaching standardization, thats the
next step, its unavoidable. Web services, in an ideal vision, allow you
to connect to _unknown_ servers, using UDDI lookups, for services which of
course is hard to fathom, but at the same time may make our apps NOT MORE
error prone, but LESS.
Lets say you needed to transparently charge a customer for an item in their
shopping cart using a visa card. Your app has maybe 2 web service servers
in its lookup tables which have priority and follow a standard debit interface.
If processing of this transaction failed on both servers, you have a few
ips in your lookup tables just for UDDI servers, where you lookup ANY debit
server that follows the standard interface and process the transaction.
In todays world, the second step of doing dynamic lookups doesn't exist!
On my current project at a bank, we have to rely on FTP to communicate with
one subsystem, SMTP to communicate with another external system and RMI with
internal systems is just plain aggravating and stupid. How can we trash
web services, when all it does is allow for dynamic lookups for services,
uses a standard protocol that can be handled by nearly every technology (simple
strings)and bypasses most NATS and firewalls because of port 80.? Even in
an internal environment, instead of using .NET remoting through proprietary
ports and binary data, using .NET remoting with HTTP (although it does have
some overhead) is probably a better design. You never know which remoting
mechanism is going to popup tomorrow, so using SOAP eliminates the need to
worry about this cause it interops seamlessly. If you say that Web Services
is somehow a new concept, you've never worked on an enterprise level piece
of software that wholly relies on subsystems. Any server that exposes data
or functionality is essentially exposing a service. If you access this service,
its better to standardize this access instead of cooking up new schemes every
single time.. Geesh,..