I wrote up some views on Service Oriented Architecture in 2004. This was a time when XML was a buzzword and people were wondering and writing about SOA. I was implementing a leading edge solution for a policy administration system using an ACORD XML interface and hosting Internet B2B services for independent agencies. A soup to nuts solution that included XML, SOAP, WSDL, Java EE, EJB and RDBMS + COTS.
I also wrote this unpublished paper:
Introduction
This is the most important decade for distributed computing. Reuse and interoperability are back in a big way for distributed applications. Over the years, several types of reuse methodologies have been proposed and implemented with little success: procedure reuse, object reuse, component reuse, design reuse etc. None of the methodologies tackled interoperable reuse. Enter web-services. Web-services are big and everyone in the industry is taking this seriously. Web services are reusable services based on industry-wide standards. This is significant because it could very well be the silver bullet for software reuse. Software can now be reused via web services and applications can be built leveraging Service Oriented Architectures. This paper relates Service Oriented Architectures and highlights its significance and relationship to web-services.
Distributed Software Applications
Software applications deployed across several servers and connected via a network are called distributed applications. Web-services promise to connect such applications even when they may be deployed across disparate platforms in a heterogeneous application landscape. Cross-platform capabilities are one of web-service’s key attractions because interoperability has been a dream of the distributed-computing community for years (Vaughan-Nichols, Steven J.). In the past, distributed computing was complex and clunky. Previous standards like CORBA (Common Object Request Broker Architecture), RMI (Remote Method Invocation), XML-RPC (Extensible Markup Language – Remote Procedure Calls), and IIOP (Internet Inter-ORB Protocol) were used for distributed applications and information interchange; these were not based on strict standards.
Sun Microsystems’s RMI (Remote Method Invocation) over JRMP (Java Remote Method Protocol) was the next revolution of distributed computing. JRMP required both client and server to have a JRE(Java Runtime Environment) installed. It provided DGC (Distributed Garbage Collection) and advanced connection management. With the release of its J2EE specification, Sun introduced EJBs (Enterprise JavaBeans). EJBs promised to support both RMI over JRMP and CORBA IDL (Integrated Development Language) over IIOP (Internet Inter-ORB Protocol). Distribution of these beans (read objects) and transaction management across topologies seemed to be a blue sky dream that never materialized. In addition, the J2EE standard was not envisioned to be a truly enterprise standard – in the sense that integration with other object oriented platforms was not “graceful”. Microsoft introduced .Net and C# that directly compete with J2EE and Java. The continued disengagement between these two major platforms has reached its threshold. It has became imperative that there be a common cross-platform cross-vendor standard for interoperability of business services. Web-services seem to have bridged the gap in the distributed computing space that no other technology has in the past: standardize the interoperability space.
Dublin Core Metadata Glossary defines interoperability as:
The ability of different types of computers, networks, operating systems, and applications to work together effectively, without prior communication, in order to exchange information in a useful and meaningful manner. There are three aspects of interoperability: semantic, structural and syntactical.
Vaughan-Nichols (2002) states that web-services enables interoperability via a set of open standards, which distinguishes it from previous network services such as CORBA’s Internet Inter-ORB Protocol (IIOP).
Web Services
The word “service” conjures up different connotations to different audiences. We need to understand what a service is not. One damaging assumption for service is that it is another term for component(Perrey & Lycett, 2004). Component-orientation, object-orientation and integration based architectures are in the same space and are often a source of confusion.
Service-Architecture defines a service: “A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services.” Perret and Lycett, attempt to define “service” by unifying its usage context by business, technical, provider and consumer. They describe and contrast multiple perspectives on “service” in detail. “The concept of perspective is the key to reconciling the different understandings of service. Business participants view a service (read business service) as a unit of transaction, described in a contract, and fulfilled by the business infrastructure.” They contrast this with the technical participant’s perception of a service as a “unit of functionality with the semantics of service described as s form of interface”. The authors go on to define a service: “Service is functionality encapsulated and abstracted from context”. They argue that the contrasting perceptions of services are really not an issue as long as there is commonality in the underlying perception. The commonality seems to lie in the reuse of services.
“Web services can be characterized as self-contained, modular applications that can be described, published, located and invoked over a common Web-based infrastructure which is defined by open standards.” (Zimmermann, Milinski, Craes, & Oellermann, 2004)
The Web Service Architecture
We are on the cusp of building “plug-compatible” software components that will reduce the cost of software systems at the same time increase their capabilities (Barry, 2003). Applications can be built on architectures which leverage these services. The goal is for service-oriented architectures to be decoupled for the very services it invokes.
Service-oriented architecture leverages the interoperability of web-services to make distributed software reusable.
Web-services makes the process more abstract than object request brokers by delivering an entire external service without users having to worry about moving between internal code blocks(Vaughan-Nichols, 2002). A recent Yankee Group survey results showed that three out of four enterprise buyers plan on investing in SOA (Service-oriented Architecture) technology within one year(Systinet, 2004).
Interoperability is driven by standards, specifications and their adoption. A service operates under a contract or agreement which will set expectations, and a particular ontological standpoint that influences its semantics (Perrey & Lycett, 2003). Applications that expose business processes with web-services are simpler to invoke and reuse by other applications because of pre-defined contracts that the service publishes. Web-services are interoperable and service-oriented architecture enables reuse, as a result SOA and web-service have formed a natural alliance(Systinet, 2004).
The collection of web-service specifications enables a consortium of vendors with their own underlying implementations of these standards to compete viably in the reuse and interoperability market. This is good because the competition is limited to the implementation level as opposed to the standards-level. Vendors will enable a compliant-based marketplace for distributed applications which expose web-services. This would enable SOA-based web-services to consistently search and leverage services in a business domain, via well-known public, private or protected registries, that are compliant with these standards.
Practitioners have used web-services for interoperability successfully in large systems:
“To achieve true interoperability between Microsoft (MS) Office™/.NET™ and Java™, and to implement more than 500 Web service providers in a short time frame were two of the most important issues that had to be solved. The current, second release of this solution complies with the Web Services Interoperability (WS-I) Basic Profile 1.0. Leveraging the Basic Profile reduced the development and testing efforts significantly” (Vaughan-Nichols, 2002).
The Communication Protocol
While web-services are primarily meant to communicate over HTTP (Hyper Text Transfer Protocol) they can communicate over other protocols as well. SOAP (not an acronym) popularly misrepresented as an object-access protocol is the primary message exchange paradigm for web-services. SOAP is fundamentally a stateless, one-way message exchange paradigm(W3C, 2004).
Interoperability is driven by standards, specifications and their adoption. True interoperability between platforms is achieved via SOAP (Zimmermann et al., 2004). Web services are interoperable and service-oriented architecture enables their interoperability. Interoperable protocol binding specifications for exchanging SOAP messages are inherent to web-services(W3C, 2004).
The collection of specifications enables a pool of vendors with their own implementation of these standards. This is good because the competition is limited to the implementation level as opposed to the standards-level. WS standards compliant vendors will enable a compliant based marketplace for distribute applications which would greatly support service oriented architectures. This would enable SOAs to consistently search and leverage services in a domain that are compliant with these standards.
The Description Language and Registry
While WSDL (Web Service Description Language) describes a service, a registry is a place where the location of WSDLs can be searched. There are two primary models for web-services registry (SunMicrosystems, 2003). UDDI and ebXML each target a specific information space. While UDDI focuses more on technical aspects when listing the service, ebXML focuses on business aspects more. In a nutshell, SOAP, WSDL and UDDI fall short in their abilities to automate ad-hoc B2B relationships and associated transactions. None are qualified to address the standardization of business processes, such as procurement process (SunMicrosystems, 2003).
The initial intent of UDDI was to create a set of public service directories that would enable and fuel the growth of B2B electronic commerce. Since the initial release of the UDDI specification, only a few public UDDI registries have been created. These registries are primarily used as test beds for web service developers.
Conclusion
Web-services in combination with service-oriented architecture have bridged the interoperability gap in the distributed computing space unlike any other technology in the past. Service-oriented architecture and web-services are a paradigm shift in the interoperability space because they are based on industry accepted standards and are simpler to implement across disparate software deployments. This technology is certainly here to stay.
