Okay, hopefully got your attention now...... I'm coming to the end of my final year at University, and I've been working all year on my project which is entitled "Evaluate the role of web services in a multi-user online gameing environment". Now, I've been using Apache axis, and I've created some services on my server that go out and read web pages and retrieve sports fixture/result information, which are then used by my application. That's fine. But I've now come to writing up my project, and have to give an overview of how web services work in the real world. Does anyone actually use them and take them seriously? Go to www.xmethods.com and you get maybe a hundred services, some of which are as trivial as a California highway traffic service. Are these things actually for real? What kind of business models are in place for companies which use them? How do they pay for them? I'm seriously starting to think that the Web Services "phenomenon" is a load of vaccuous hype, only talked about so much because vendors want to be first on the scene when or if Web Services "explode". Should I be this harsh? Can anyone really argue their use in modern distributed computing, with real examples, and understandable by anyone who reads english? If so, please reply, or post some relevant links. I feel like writing a scathing critique of the whole Web Services enigma, but I'm scared to do so in case I'm way off the mark. Any feedback very welcome. Thanks [ April 10, 2004: Message edited by: Dominic Clarke ]
The biggest selling point of web services technologies is interoperability. The services published at XMethods etc. are not what "real world projects" are all about. If 10 years ago Big Bank Plc. and Insane Investments Inc. decided to partner up and integrate their systems, they looked into opening a dedicated line between the offices and using something like CORBA (a bit far fetched but still) or EDI (much more likely) to collaborate. Now, the solution would likely be based on SOAP, XML Encryption, XML Digital Signatures, etc. Why? Because it's easier than the legacy alternatives and much better supported by tools these days. There is undoubtedly a lot of hype out there regarding web services, but there's also a large market which will benefit from the standardization in the field of integrating heterogeneous systems.
You are way off the mark because you've only heard the "hype" and not heard about the real payoff for Web Services -- in enterprise integration. Here's the basic problem. Step back 5 years to 1999. You're a big company and you've got half your enterprise developers developing in Java and half in Visual Basic (BTW, this is an ACTUAL scenario I'm describing). The problem is that the programs developed in one can't talk to the other. Furthermore, you've got a few dinosaur programmers who still write COBOL for you, but that COBOL code runs your business (the real $$$ are in the back end). How do you solve this problem? You'll pry their favorite tools out of your developer's cold, dead hands. What's more, you're finding the costs of interfacing all these enterprise systems with the back-end COBOL stuff going up every year as the number of enterprise systems increase. Enter Web Services. Finally, there's a protocol, a wire format, and an interface description (HTTP, SOAP and WSDL) everybody (M$, IBM and Sun) all agree to. You can talk between Java and Visual Basic with Web Services. Each of them can talk to your COBOL through Web Services. It all makes sense. Your costs go down and everybody's happy...at least until compatibility testing of the web services stacks starts... Kyle
I understand what you're both saying, and I totally agree with you, but I still think that they're overhyped. Sure, Web Services offer a framework for providing loosely coupled systems to interact with ease, but what about the whole service oriented architecture thing? Web Services have been touted as MUCH mure than just a cleaner, better alternative to CORBA, but to be honest that's all I see them as. Do companies actually have applications which dynamically go out and consult a UDDI registry to find the right type of services for whatever task they have? I just see web services as an easier and more universal way of different systems to interact. I really don't see any evidence of a "service architecture" existing anywhere. Any thoughts?
posted 16 years ago
It depends on your definition of a "services oriented architecture". Again, dynamic UDDI is not necessary to have an SOA -- in fact, Web Services aren't even necessary to have an SOA. An SOA simply means that you define your communication in terms of large-grained services described in a common interface definition (presumably WSDL). However, that could just as easily describe a system that is using CORBA for its communication as well. And that's fine, just not as interoperable as when you would use the Web Services stack. However, using the Web Services stack means you can put intermediaries between requestor and provider -- something quite difficult to do in CORBA, and very, very useful in many situations (imagine things like loggers, routers, security intermediaries, etc...) Kyle
Would it be correct to say that we can look at Web Services from two different perspectives? Firstly, there is the "traditional" Web Service protocol stack perspective -one which describes Web Services by means of discovery, description and invocation (UDDI, WSDL and SOAP respectively), and places more emphasis on Web Services as publicly avaiilable services which are very loosely-coupled, and can used by any software system. Secondly, Web Services existing primarily as a superior alternative to something like CORBA. Superior because of its un-reliance on specific client and server interfaces, and because it uses XML to transport all the data. The Web Service protocol stack isn't so important here because no UDDI registry need exist and WSDL isn't necessary either because surely whoever writes the services will be also be the ones to use them. Any thoughts?
posted 16 years ago
I would say that the WSDL is very essential in both scenarios -- how would you otherwise develop a client for a given web service (guessing what the SOAP messages should look like from a Java interface is hardly a pleasurable task...)?
Fair enough, but do you agree about the two different perspectives we can look at Web Services from (i.e. one which makes no use of UDDI)? I'm not trying to pigeonhole WS into two kinds of easily definable frameworks, if anything I'm trying to convince myself that WS's have a much wider scope than I first thought.
posted 16 years ago
Yes, I agree that there is a gap between applications that don't have a need for UDDI and applications that rely on such a registry. To date, I haven't seen but one web services project which did use an UDDI registry. For the rest, "agreeing on the endpoint URL" seems to be flexible enough.
Thanks to both Lasse and Kyle for your helpful replies. It's easy to get the wrong idea of Web Services reading purely from textbooks where the insistence is on UDDI, SOAP and XML. Now back to writing up my project report................
Make yourself as serene as a flower, as a tree. And on wednesdays, as serene as this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!