A rchive Date
[ 20-12-2003 ]
Category
[ Information Technologies ]
sub-Categoy
[ Networking ]
|
[http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2846997,00.html
What are Web services anyway?
ZDNet Tech Update contributing editor Eric Knorr's story on the state-of-the-state of Web Services is a must read. If you haven't figured out why Web services might be for you, Knorr's column will certainly whet your appetite.
By David Berlind
February 12, 2002
One thing Knorr doesn't tell you is: What are Web services? OK, maybe you know the answer, but apparently your peers do not.
At last fall's Gartner Symposium, just before an icebreaker session on Web services, I asked several attendees - presumably C-level technology executives - if they could give me a definition of Web services. Their answers fell into one of three camps: Web hosting, Internet service provider, and application service provider. No one knew. Before the session's end, over half the attendees had left because they were expecting a discussion about something else. Judging by the e-mail I receive almost daily, most everyone is still confused about what Web services are.
"Web services" is nothing more than a fancy moniker for "big honking API (application programming interface)." Consider what xDBC (replace the x with O for "Open" or J for "Java") and SQL (structured query language) did for databases. They made it possible for just about any software - reporting tools, spreadsheets, even word processors - to extract query results from any database. Any software. Any database.
Now, in the same way that xDBC and SQL provided a standard way for any software to access a discrete package of data (the database), Web services provide a standard way to discretely package anything (a database, a specific query, some business logic) and make it accessible to anything else (another database, a WAP-enabled phone, or better yet, an external partner's business logic).
In other words, you can cut your business logic up into discrete modules (you decide where the boundaries should be), and make those modules accessible, as needed, to the business logic in your partners' systems. In essence, you're now providing that logic as a service - the service part of Web services. This is what Web services proponents like Sun CEO Scott McNealy mean when they say one of every technology manager's top priorities should be to turn all software into services.
It's the protocols
In the past, integrating dissimilar external systems, or even internal ones (where most people think Web services will ramp up first) generally required a proprietary interface that was difficult to develop and prone to breakage every time one of the integrated systems changed. Web services are simply the de facto-standard protocols that make such integration possible without requiring you to re-invent the wheel for each new integration project
Those protocols are XML, SOAP, WSDL, and UDDI. XML and SOAP are probably the two most important ones. The idea behind SOAP (Simple Object Access Protocol) is that you have a standard way of accessing objects on any systems that support the protocol. (Those objects are the discrete packages of data or business logic that I mentioned earlier.) XML is simply a standard way of structuring the text that gets passed between these objects. In the same way that Internet browsers understand HTML, SOAP-based objects are pretty handy with XML. It's the reason that techies call the process an XML RPC (remote procedure call). Think of the logic in the SOAP-based object as a remotely located procedure that needs to be "called" from across the Internet or a local area network. Whatever "calls" that object, be it a WAP-phone or a partner's system, packages its request in XML.
As Knorr points out in his column, there is a lot of work to be done on the XML front. XML may provide a way to structure the text. But within industries, companies must agree on what that structure (also called a schema) will look like. For example, if all airlines are going to integrate easily with all car rental companies, there needs to be some consensus within those two industries as to what the standard XML schemas look like.
Those agreements are taking shape, as working groups within industries are just beginning to coagulate. For example, the human resources industry has already organized an XML schema standardization effort and maintains a Web site to track its progress. In addition to industry-specific efforts, several technology companies such as Intel, Microsoft, Computer Associates, and SAP, and industry leaders such as Ford, Gillette, and Penzoil, have joined forces to form the Business Internet Consortium to more broadly attack the problem of XML schema standardization. No doubt, those and the other technology companies that belong to the BIC would love to see Web services become the next revolution in computing. Somewhere along the line, if companies decide to join the revolution, they'll need new technology and tools. And if their business grows as a result (one promise of Web services), they'll have to buy more gear. In other words, the involvement of Intel, Microsoft, and others in the BIC isn't purely altruistic.
David Berlind is Editorial Director of ZDNet's Tech Update]
|