 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > Microsoft .Net Development News > Web Services (Part 1) |
| |
|
|
|
|
| Microsoft .Net Development News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
|||||||||||||||||||||||||||||||||||||
 Web ServicesBy Steve Vinoski, Chief Architect, IONA Technologies
Web services are currently garnering a lot of attention. Some of the attention is good, some of it not so good. In the latter category, Web services are unfortunately being hyped as the next "Silver Bullet," magically ready to solve all your computing problems, just like all the other Silver Bullets that came before, and just like those that will surely follow. Several supposedly technical articles about Web services essentially ask us to suspend our disbelief and buy into a "new world order" in which the rules of distributed systems, pertaining to performance, latency, coupling, and scalability, no longer matter. Will we ever learn? If we look past all the hype surrounding Web services, do we find anything worthwhile? I believe we do. Web services represent an evolution and convergence of three very important areas of technology and business:
By evolving out of each of these three areas simultaneously, Web services are providing a focus for their convergence. It's too early to tell whether Web services will ultimately serve as the vehicle for such convergence, given that similar claims have been made for CORBA-based applets and other technologies. Below, let's explore how the Web services movement relates to each of these three areas. Evolution from the Web Perspective The Web today is essentially a large-scale two-tier distributed system. The "business logic" tier is the Web server, and the "presentation" tier is, of course, the browser. As with all two-tier systems, the Web's capabilities are designed for human interaction. Everything you can see or do on the Web is driven through your browser, so naturally its current content is entirely designed to support such interaction. Given that we've known for years that two-tier systems are somewhat limited, the fact that today's Web is a two-tier system is somewhat surprising. We learned years ago that two-tier systems, such as terminals tied into a mainframe, limit not only usability but also reusability. They limit usability because of their requirements for human-driven screens and GUIs, and they limit reusability because their business logic services are meaningful only in the context of such GUIs. Web services are the next evolutionary step for the Web because they extend the Web to a three-tier (or more) system. They allow enterprises to expose their business services as applications that can be discovered and invoked programmatically by other applications over the Web. This capability in turn allows enterprises to create Web-based business services composed of other Web services. Evolution from the Middleware Perspective Middleware provides two primary approaches for integrating applications:
While many words have been wasted arguing over which of these two middleware approaches is superior, the fact is that both approaches have merit under different circumstances. Most enterprises use a mixture of the two approaches to satisfy their application integration needs. Web services are evolving out of both of these middleware approaches. For example, the Web Services Description Language (WSDL), recently submitted to the W3C for standardization (see http://www.w3.org/TR/wsdl/), allows you to describe both procedure-oriented and data- or document-oriented Web services. Not surprisingly, many of the same technical issues that we've been battling in the middleware space for years - interface definition, transactions, message queue persistence, recovery, and security, to cite a few examples - are still problematic, perhaps even more so, in the Web services space. Evolution from the EDI Perspective With all the hype currently surrounding e-business, you'd think it was brand new. It isn't. It has been around for more than a decade, in the form of EDI. EDI, in fact, provides for fully automated business-to-business transactions. It works, but it's fairly expensive to implement and deploy. The high costs of EDI are due primarily to the need to establish proprietary communication networks called value-added networks, or VANs, between EDI participants. The need to employ consultants with special skills to implement the actual EDI business document interchange also contributes to its cost. A key aspect of EDI, and perhaps the main reason it has survived at all, is that it encompasses detailed business process standards, such as the ANSI X12 standards and the Electronic Data Interchange For Administration, Commerce, and Transportation (EDIFACT) standards established by the United Nations. It seems strange to say that, given that the whole reason EDI exists is to enable computer-automated business transactions. However, these types of standards often start out by addressing low-level details such as wire protocols and programming models, and they never move on toward tackling the higher-level business issues. By taking advantage of XML as the lingua franca for electronic document definition and the existing Web infrastructure, Web services are providing an evolutionary path toward a less expensive, more productive, and more widely available form of EDI. Evolving B2B standards such as RosettaNet (http://www.rosettanet.org/) and ebXML (http://www.ebxml.org/) are supplying us with XML-based business document standards as well as standard processes for manipulating them.
Copyright 2001, IONA Technologies. Reprinted by permission. FOR MORE INFORMATION: Talk back or comment on this articleThe Best Web Links for Web Services Free Tutorials for Web services, SOAP, UDDI and more
|
|
|
|
|||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
