Whenever the average, albeit technically savvy, man on the street is asked about Service Oriented Architectures (SOA), the first thing that will pop into his head is Web Services. This is not surprising since, despite being around for some time, the term SOA has had its visibility increased dramatically on the coat-tails of the Web Services rise to fame.

So that we are all on the same page we will define SOA for the purposes of this article, as:

"A way of designing and implementing enterprise applications that deals with the intercommunication of loosely coupled, coarse grained (business level), reusable artifacts (services) that are accessed through well-defined, platform independent, interface contracts."

It should be clear that this definition does not include the communication protocol or wire format used to invoke services. Unlike other service based approaches, a true SOA encourages service access through a variety of means - not just SOAP over HTTP.

The goal of this article is to expand upon this. To provide alternative service invocation schemes and to explain why there is much more to SOA than Web Services.

Background

Service-based concepts have a long and successful history before Web Services. The Common Object Request Broker Architecture (CORBA) has been around for many years and provides many of the SOA benefits being touted today.

Using our definition, it is clear that CORBA is not a true SOA implementation. Although CORBA has a platform independent service contract defined through IDL (Interface Definition Language) and implementations that support a variety of languages and platforms, it requires a particular communication protocol called IIOP (Internet Inter-ORB Protocol) and standardized wire format. Moreover, the requirement to compile the IDL to generate stubs and skeletons means that resultant applications are tightly coupled.

If we narrowed the scope of SOA to just Web Services, we would have a similar story. WSDL replaces IDL, and services are invoked over a particular, albeit lower cost and more prevalent, protocol (HTTP) with a standardized wire format (SOAP). Using current development environments, stubs and skeletons can be generated from WSDL, again resulting in more tightly coupled services than we would like.

The real power of a true SOA comes into play when we relax these restrictions and enable services to be invoked through a variety of protocols.

A Question of Protocol

Ask yourself the question - "How many different protocols are used for process intercommunication within my organization?" Depending on the size of your company you probably came up with HTTP, HTTPS, a message broker (JMS, MQ, MSMQ, etc), CORBA and SMTP. You maybe also have realized that remote invocation of an EJB or the simple execution of a method on remote object would leverage a protocol such as JRMP.

The other thing you will realize is that, in many cases, the choice of protocol for a particular situation was not based on any real use-case analysis. It is more likely that the selection was founded upon a current implementation, existing infrastructure or choosing the quickest and easiest route to integration. Another aspect of this is that the integration mechanism probably utilized existing code through an adaptor, wrapper or delegation mechanism and no attempt was made to determine the correct level of communication granularity.

In a true SOA all of the protocols mentioned could provide an access point to a service. In principle, a service can be defined once, through a service interface, and have many implementations with differing access protocols. This is most evident on closer inspection of the language commonly used to describe services today, WSDL.

WSDL - Drop the W

Despite the name Web Services Description Language, WSDL, in its purest form, does not describe web services. It has a core service definition framework that is independent of communications protocol or data format. This core framework describes the operations that comprise a service and the data passed in each request and response. Layered on top of this are binding extensions that attach a specific protocol or format to a message, operation or access point.

In some ways, the general perception that WSDL describes Web Services and that SOA is all about Web Services comes from the confusing way in which extensions to the core framework for SOAP, HTTP and MIME bindings are included in the initial WSDL specification.

These bindings are included as examples within the specification to make it clear how they should be used, but as the specification states:

" Nothing precludes the use of other binding extensions with WSDL."

With that clarification we can see that the authors of the WSDL specification intended it to be used to describe services in general. The included bindings enabled the specification to be relevant, by coupling it to existing technologies that solved a particular use-case. In its full form WSDL encourages the binding of services to multiple protocols; the trick is deciding on which ones are best applied to a specific circumstance.

Best Practice Makes Perfect

Given any single service, there are a number of ways in which that service can be invoked. Assuming the service has bindings for many protocols, how does an IT architect decide which approach to use in a particular use-case?

The following table summarizes the properties of popular protocols and data formats:

Transport Protocol	Synchronicity	Data Format	Description
HTTP	Synchronous or Asynchronous	Form (Get / Post) XML SOAP	Remote, unsecured, platform independent, service access within or external to org.
HTTPS	Synchronous or Asynchronous	Form (Get / Post) XML SOAP	Remote, secure, platform independent, service access within or external to org.
JMS	Asynchronous	XML SOAP Java Objects	Peer to peer or published messages in communicating Java environment
SMTP	Asynchronous	Context Based XML SOAP	Remote delivery of messages within or external to org.
Proprietary Message Broker	Asynchronous	XML SOAP Proprietary	Peer to peer or published messages in proprietary environment
CORBA	Synchronous	CORBA Object	Direct remote object invocation in potentially heterogeneous environment
Native Distributed Objects	Synchronous	COM+, EJB / RMI .NET Remoting	Direct remote object invocation in native environment
Native Object	Synchronous	Native data types	Local object access in native environment

It should be made clear that for distributed and native object technologies, application of a service oriented approach does not mean execution of many highly granular method calls. If we are to apply best practices, it is assumed that these objects contain business level methods that can receive complex data structures.

By way of example, imagine a native object that manages purchase orders and utilizes enterprise resources for their persistence. This object may have methods to create the order, add line items, set the customer information, etc. Invoking these methods at the local level does not cause any problems, but if we are to use remote or asynchronous protocols performance problems introduced by many remote calls become evident. The solution is to provide a single method to add an order that receives an object containing the full data structure for the entire order.

This method could be described through a service interface and made accessible through many protocols through layering of technologies. The service signature does not change, only the communication protocol and data wire format. The following diagram explains how this layering can be achieved.

Since such a service can be accessed through many protocols, it is the job of the service consumer to decide which protocol best matches a particular use-case and technology set. Another complication arises when the data wire format is considered. As shown in the previous table, each protocol supports data in a variety of formats. Implicit in the above diagram is the transformation of data between different formats as required. For the purpose of this discussion it is assumed that the exposed method of the native object accepts XML which is propagated through all the layers.

The following table lists the protocols once again and explains when each should be used for access to the same service provided by the wrapped native object.

Transport Protocol	Recommended Usage
HTTP	The service is present on a remote machine that may be external to the organization. The platform hosting the service is different to the consumer platform. Synchronous access to the service may be required in order that a response may be immediately relayed to the consumer. Asynchronous operations may also be required with callbacks or polling for results. Reliable access to the service is not an issue. Security is not required.
HTTPS	As for HTTP, except a secure authenticated connection is required.
JMS	The service and consumer are both present on Java platforms that can access the JMS provider. No immediate response is required from the service. Guaranteed delivery of the service request may be necessary. Sending or receiving the message may be part of a transaction. Security such as authentication and authorization is an option.
SMTP	The service and consumer can both access SMTP engines, but are not necessarily in direct communication or are present on disparate platforms. No immediate response is required from the service. No transactional support is required. Guaranteed delivery is not essential. Security is not required.
Proprietary Message Broker	The service and consumer can both access the Message Broker, but can be on disparate platforms. No immediate response is required from the service. Guaranteed delivery of the service request may be necessary. Sending or receiving the message may be part of a transaction. Security is an option
CORBA	The service and consumer both have access to an Object Request Broker (ORB) and can communicate via IIOP. Synchronous access to the service may be required in order that a response may be immediately relayed to the consumer. The service request may be part of a transaction. Security is an option.
Native Distributed Objects	The service and consumer both reside on the same native platform and are in direct communication, though not necessary located on the same physical machine. Synchronous access to the service may be required in order that a response may be immediately relayed to the consumer. The service request may be part of a transaction. Security such as authentication and authorization is an option.
Native Object	The service and consumer both reside on the same native platform and are located on the same physical machine. Synchronous access to the service may be required in order that a response may be immediately relayed to the consumer. No transactional support is required. Security is not required.

To choose the appropriate protocol for a particular use case it is then necessary to consider the context in which the service is being used and the required reliability, performance and security of the overall system.

SOA Made Easy

One obvious side effect of providing multiple ways to invoke the same service is the overhead in development to provide the necessary layers of technology. Executing a method on a native object may just take one line of code. Creating a JMS message and placing it on a queue or the lookup and narrowing of a remote distributed object takes much more work. To achieve productivity in such an environment all of these things should be equally easy. In fact, the same mechanisms should be used to invoke the service, independent of its underlying implementation.

Within the WebLogic Platform, Controls play just that role. The creator of the service can build a Java Control that accepts XML and performs all the tasks to create a purchase order, for example. This is the Native Object implementation (the Java Control may, behind the scenes, be utilizing a Java Process, which may in turn be executing other services, but that is another article.)

One additional step can create a Java Web Service (JWS) from this control (now supporting HTTP or HTTPS as necessary). A Java Page Flow can also be created to use the Java Control, allowing direct web access to the service (also a form of HTTP or HTTPS). If remote object access is required, an EJB project can be created with a Session Bean (Native Distributed Objects) that delegates to a Java Process through a process proxy. Additionally, EJB controls provide facades that allow existing EJBs to be exposed over HTTP or JMS. EJB Compilation options allow EJBs to be accessible via CORBA and to generate IDL and Stubs.

JMS support can be added in two ways. Firstly, a JWS can be bound to JMS directly through @jws:protocol annotation or a JAX-RPC based service through JMS binding in the WSDL. Alternatively, a Java Process can be created that listens to a JMS queue and on receipt of a message delegates to the Java Control to process XML contained in the message. A similar process can be used to provide SMTP support by subscribing to an Email channel. Other message brokers can be supported in the same way.

This can be summarized in the following table:

Transport Protocol	WebLogic Platform Artifacts
HTTP	JWS, JAX-RPC Web Service, or Page Flow Action
HTTPS	JWS, JAX-RPC Web Service, or Page Flow Action
JMS	JWS or JAX-RPC Web Service with JMS binding, JPD with JMS subscription
SMTP	JPD with Email subscription
Proprietary Message Broker	JPD with Message Broker subscription
CORBA	EJB Compilation Options allow IDL and CORBA stubs to be generated
Native Distributed Objects	EJB Project with Session Bean
Native Object	Java Control (JCS)

The consumer of the service has an equally easy time. Within Workshop, various built-in Controls are available to easily access Web Services, EJBs, JMS queues, Message Broker channels, Email or CORBA implementations. And, of course, a custom Java Control can also be utilized directly.

Conclusions

Service Oriented Architecture is about much more than Web Services. A single service can be exposed in many ways to allow access via multiple protocols. Consumers of services should choose the most appropriate protocol to fit a particular use-case, performance, security and reliability requirements. The BEA WebLogic Platform provides simplified construction of many different protocol wrappers to a single service and aids dramatically in service consumption. Web Services are only one form of service implementation, in many cases the use of an alternate protocol will provide a more scalable and robust solution.