I'm sure this topic has been discussed numerous times but I really want to get some opinions and thoughts about whether web services are the silver bullet or just plain hype. Ive been around enough to know that its not in any vendors real interest to achieve inter-operability, because what makes sense business wise is to have a customer locked in (cant blame them, they are there to make money.) For me, web services technologies are very fragmented and standards are fluffy in numerous ways, and at the heart, its only another way to make remote calls, nothing more than RPC, RMI, CORBA, and even COM and DCOM !
So, ServerSide nation, what say you? Hype or not, and Why?
Based on my experiences, Web Services are like most interesting new technologies: they fill an important niche, and are very useful in that niche. Where things break down is when people try to use a new technology for *everything*.
There are three factors that make an application appropriate for web services:
1. You need to send messages through firewalls (there is no better alternative than web services here).
2. You need interoperability between diverse environments, and you have application components that are distributed on different machines. Web Services are surprising successful at being interoperable. (If all the components are located on the same machine, though, there are probably alternatives that will execute more quickly.)
3. You need to expose a service to external business partners with whom you do not have a pre-established network (basically, a lightweight replacement for EDI).
Things for which web services work poorly:
1. Internal-only applications where everyone is using the same environment (native protocols are much faster if firewalls are not an issue).
2. Anything that is performance intensive (web services are slow).
3. Anything involving transactions (For now at least. Once BTP or WS-Transactions becomes more wide spread, this may change).
The biggest remaining hurdle to making web services truly effective is resolving all the nasty security mess.
So long as you use Web Services in the appropriate niche, they are great. The only other thing I would add is that retrofitting an existing application to incorporate a SOAP interface is generally not a major undertaking, so adding web services later (if you need them) in an application's lifecycle is not a big deal.
Paul Strack wrote:
> Based on my experiences, Web Services ..
Excellent post. I might add that in some areas involving the integration of disparate architectures with services based integration strategies (like web services), it will take more than just investment in technology - FOR SYSTEMS THAT ARE A BIT OF AN "ARMS LENGTH AWAY". By that I mean: for political reasons, the systems are not integrated currently - and that they probably never will - no matter how many new technology solutions we throw at it.
In my opinion, such disparate systems will never collaborate without a strong political will from both sides to integrate. As such, you may find many half-hearted attempts at using integration strategies (including web services) that are more than likely doomed before they are even implemented.
2. Anything that is performance intensive (web services are slow)
Could you expand on this point. Are you saying that they are slow in comparison to other protocols? What aspect of them do you feel is slow e.g. xml marshalling? We're currently developing an application and are using apache axis to provide a web service interface. We've found that there is very little overhead (above and beyond actaully making the call across the network).
Yes, I have the same question. Also, if you have to integrate, say, Java and any Microsoft technology, I wonder what other "native" protocol will be even feasible, let alone performing. No doubt that any local invokation within the same JVM or process will be way faster than any remote technology. But I have hard time believing that there is a huge difference between XML marshaling and Java serialization or IIOP or RMI or whatever other protocol you may be able to use as an alternative.
It will be very interesting if someone conducts some benchmarking of, say, two app servers that exchange calls using
- Apache SOAP, RPC as well as hand-coded document style
- Apache Axis, RPC and document style
- remote EJB invocation with Java serialization
- IIOP invocation (don't know much about it, but I think that an app server that supports IIOP can automatically skip the Java serialization step and use better-performing IIOP to marshal parameters)
- hand-coded HTTP GET/POST to servlet with Java serialization
- hand-coded HTTP GET/POST to servlet with hand-coded XML
I have developed in the past a database synchronization process across the Internet. It exchanges an XML file, 2-3MB large. Works very reliably, the parsing time is negligable, and I can't think of any better way to exchange this much information between two distant machines.
" But I have hard time believing that there is a huge difference between XML marshaling and Java serialization or IIOP or RMI or whatever other protocol you may be able to use as an alternative. "
That's a bit foolish to say. The simple fact is it requires more bytes to say the same thing in XML via HTTP compared to many binary protocols like RMI which move over TCP.
An unbiased a repeatable test is within .NET. You may know .NET supports both binary and XML based serialization. Take your favorite serializable C# object, write to a file using each method and compare the file size.
Obviously interoperability may far outweigh performance, but to ignore this is short sighted.
The first wave of attention for XML focused on Web services, but it seems that it's really coming into play as a sort of lubricant for allowing data exchange between heterogeneous systems. Is that what you expected?
There is no doubt whatsoever that if you go into an environment where XML is really, truly being used right now, it's that lubricant role you described. It's lightweight, quick and dirty enterprise application integration. The world is a heterogeneous place. Given the pace of mergers and acquisitions and the desire to centralize in the enterprise, there's a lot of big, hard, ugly integration problems everybody faces. And it suddenly became apparent at some point that almost every application, no matter how old, had a Web server on it. And you could achieve remarkably acceptable results in enterprise application integration simply by binding a set of XML messages to ship back and forth. There's just an immense amount of that happening right now.
We've been using them internally to standardize access to a bunch of tools. We run a bunch of websites, several trading systems, and loads of back office process. We've got backoffice tools in C#, core systems in Java, and websites built on a mix of Java and coldfusion. Now more and more of these utility systems which were designed for use by one area of a particular business unit and then cloned or re-written for a different another. The simplicity of webservices integration means that we're exposing more and more of these systems. I took all of 10 minutes, to expose a java system via axis as a WS
and put together a simple C# client to consume it. It may not perform as
well as a tighter protocol might, but that's why it's so simple to expose and consume a WS.
The only thing I'm still really not finding a way to apply is UDDI, I just don't think it's all the relevent, both internal and external.
Who would even ask such a question? It's absurd. What's the alternative? Web services have been around since the web has been around. It's like asking whether plastics are hype. Now if you want to focus the question on whether a given standard proposal for publishing, discovering and accessing web-based services is being hyped that's another question entirely.