Previous Program-to-Program Communications Architectures Have Met with Limited Success

If you've been involved in the computer industry for a while, you'll probably be asking yourself why this talk of Web services sounds vaguely familiar. Consider this: for over two decades Information System (IS) managers have sought a means to enable applications to work transparently and cooperatively with other applications, irrespective of vendor platform, programming language, and operating system. These executives have heard and seen multiple schemes by many vendors that were designed to provide cross-platform program-to-program communications.

Against this background, Web services looks and sounds awfully familiar. It promises to be a cross-platform program-to-program architecture that will enable various programs on disparate information systems using completely different programming languages to work together seamlessly. It offers to use the ubiquitous Internet for network connection; and it is based on Internet standards for programmatic interfaces and directory look-ups.

So the big question for IS managers and business systems executives is, "Why will this set of Internet Web services standards actually succeed when other similar approaches in the past have failed (or at least not garnered tremendous market acceptance)?"

Examples: Previous Approaches

Information Systems executives have been discussing program-to-program communications since the early 1980s, when IBM introduced its Systems Application Architecture (SAA). This distributed computing architecture had elements similar to the current Web services directories and protocols:

  • IBM's Document Content Architecture (DCA) was used to create a common content/format (just as XML does).

  • Logical Unit 6.2 (LU6.2 an application program interface also known as APPC for Advanced Program-to-Program communications) was designed to let applications talk to each other (just as WSDL does); IBM's peer-to-peer Physical Unit 2.1 (PU 2.1 a peer systems communications protocol) was used to bind sessions (similar to what SOAP does).

  • All of this was done over a network called Systems Network Architecture (SNA) using SNA protocols for data transport as opposed to a network called the Internet using the HTTP protocol for data transport.

Over the years, tens of thousands of transaction-oriented applications have been written using these protocols and programmatic interfaces. But for small- and mid-sized businesses, writing LU 6.2-based programs and driving them over an SNA network proved too complex. Consequently, these protocols and APIs were related to uses in large enterprises and between high-end transaction-oriented midrange minicomputers and mainframe computers.

Over the years, new variations on the same theme have come to market in the form of "object-oriented programming" or "distributed computing," or the "Common Object Request Broker Architecture" (CORBA), IIOP (Internet Inter ORB Protocol), DCOM (Distributed Component Object Model), and any of a number of other architectural approaches. Many of these approaches have met with some success, but mostly in intranet/extranet situations (not over the public, far-reaching Internet).

Over time, most of these approaches have run into issues that have kept them from being more broadly adopted for cross-platform program-to-program communications. Some of these issues are related to architectural design and complexity, to binary compatibility, to requirements for homogeneous operating-environment, and to concerns about vendor proprietary lock-in (buyers worried that committing to some of these architectures would limit their choices of equipment and operating systems).

One of the best explanations of past failures can be found in this somewhat technical description of market behavior by IBM's Web Services Architecture Team:

Previous attempts at distributed computing (CORBA, Distributed Smalltalk, Java RMI) have yielded systems where the coupling between various components in a system is too tight to be effective for low-overhead, ubiquitous B2B e-business over the Internet. These approaches require too much agreement and shared context among business systems from different organizations to be reliable for open, low-overhead B2B e-business.

Meanwhile, the current trend in the application space is moving away from tightly coupled monolithic systems and towards systems of loosely coupled, dynamically bound components. Systems built with these principles are more likely to dominate the next generation of e-business systems, with flexibility being the overriding characteristic of their success.

Further, the IBM Web Services Architecture Team indicate that they believe that the concept of Web services will succeed:

We [IBM] believe that applications will be based on compositions of services discovered and marshaled dynamically at runtime (just-in-time integration of services). Service (application) integration becomes the innovation of the next generation of e-business, as businesses move more of their existing IT applications to the Web, taking advantage of e-portals and e-marketplaces and leveraging new technologies, such as XML.

Source: http://www-106.ibm.com/developerworks/library/w-ovr/.Used by Permission.

In other words, previous attempts to build cross-platform program-to-program applications were too cumbersome to build and deploy. The team further states that the new trend is toward more fluid "dynamically bound components" that is, toward applications that can establish contact, share information, and then break contact after they have provided a transactional or computational service.

Web services will succeed, then, because they are based on agreed-to program-to-program communications standards that are easier to implement than previous architectures (because they consist of loosely coupled transactions rather than code-intensive hard-wired transactions). This ease of use combined with an ability to provide services "as needed" in a just-in-time fashion for other applications will ultimately lead to the success of this newly evolving Web services approach to programming.



Web Services Explained. Solutions and Applications for the Real World
Web Services Explained, Solutions and Applications for the Real World
ISBN: 0130479632
EAN: 2147483647
Year: 2002
Pages: 115
Authors: Joe Clabby

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net