Welcome back! Last month I introduced the concept of service-oriented architecture (SOA); this month we look into the technology that is required to support SOA.

Figure 1 provides a high-level illustration of SOA deployment. There are three major components:

  1. Providers – Expose functionality as services.
  2. Clients – Invoke the services.
  3. SOA infrastructure – Connects the consumers and providers together in a reliable and managed manner.

Figure 1: SOA Deployment

As we can see, there is a diverse range of clients and providers – applications (whether custom or packaged), mainframes, users and trading partners. Users will be active participants in any SOA – invoking services via a portal (e.g., submit purchase request) or providing services (e.g., managers that can approve the purchase request). We can extend the SOA externally to encompass trading partners, with the only criteria being more restriction on the interaction, e.g., tighter security requirements.

SOA provides the backbone to integrate all these different entities. And in many cases the same entity will perform both roles of client and provider. For example, an application may expose its business functionality as services and invoke external services when its internal business logic requires.

Standards-Based Underpinning for SOA

One of the major architectural features of SOA is the loose coupling between clients and services. A service defines an interface with which clients interact with; the client uses the interface to determine what the service can do and how to invoke it. The client has no dependency on what the underlying implementation is and what type of application provides the service.

Web services and XML provide a standards-based mechanism for defining the service interface and how to interact with the service. This allows clients and services that are implemented using entirely different technologies from different vendors to be easily connected together. The primary steps to accomplish this include:

  • Represent information being passed to and from the service. XML (extensible markup language) provides the ability to represent information in an application-neutral format to facilitate the exchange of that information. In addition, XML schemas (or XSDs) provide meta data about XML documents to describe what the information means.
  • Define the interface of the service. WSDL (Web services definition language) provides a mechanism for describing the interface of a service, the operations the services provides and the input and output data of those operations as XML documents.
  • Invoke the service defined by the interface. SOAP (simple object access protocol) provides a messaging protocol for invoking the service operations specified by WSDL and passing the input and output XML data. Clients invoke service operations by sending the service a SOAP message.

There is a plethora of other standards associated with Web services (WS-Security, WS-Policy, BPEL, etc.) but these are beyond the scope of this article.

Creating Services and Clients from Enterprise Resources

Various approaches are used to create the services from existing enterprise resources. These include Web services toolkits that may be used to wrap application APIs and adapters that may connect with the application and offer a Web service interface. Newer versions of packaged applications are offering native Web services interfaces. A portal may be created to enable users to invoke services. The approaches will be specific to the particular application, but this is a one-time activity with the resulting service available for use by multiple clients.

SOA Infrastructure Features

Now that we have looked at what a service is and how to invoke it, lets turn the discussion toward the infrastructure that supports this interaction. Requisites include:

  • Transport. While HTTP is the default transport for Web services, the ability to support other messaging transports such as JMS or IBM’s MQSeries is important, as many IT environments have these messaging systems deployed and wish to reuse them.
  • Communication Paradigms. Both synchronous and asynchronous (including request/reply and publish/subscribe) messaging paradigms should be supported to provide flexibility in how services are used. Bridging these paradigms should be supported, for example, allowing a synchronous browser client to interact with a legacy application that provides asynchronous request/response services.
  • Routing and Transformation. This enables control over the interaction between clients and services by routing client requests to different services depending on specified criteria, e.g. message content, security context or external rules. This rerouting may require the message content to be transformed to a new format.
  • Security. The ability to secure services by ensuring that clients are authenticated as to be whom they say they are and are authorized to access the service.
  • Administration. Operations staff should be able to monitor and manage the infrastructure, set and monitor SLA conditions, track messages flow between clients and services, generate alerts, and handle exception conditions.
  • Enterprise Caliber Runtime. The SOA solution will become the backbone of the enterprise and needs to provide enterprise caliber quality of service: reliability, availability, serviceability and performance.

Enabling Service Orchestration Processes and Composite Applications

Up to now, we’ve been discussing SOA in the context of integrating existing applications – the services are exposing the application functionality for other applications to execute. This is fine, as simplifying the EAI and B2B problems is a benefit of SOA. However, another benefit of SOA becomes apparent as the total set of these services grows – it’s now possible to create new application functionality very rapidly by leveraging these services.

Using business process management (BPM) technology, new business processes that orchestrate existing services can be created very rapidly, thus enabling the enterprise to quickly react to changing environments. The next step is to create composite applications that consist of new application logic code leveraging these services. This approach enables new business functionality to be deployed more rapidly than traditional approaches. It’s important that the SOA infrastructure supports these capabilities to ensure that the full benefits of SOA can be leveraged.

This has been a quick overview of the technology involved with SOA. In future columns I will drill into specific areas in more detail. Next month, however, I’ll discuss the business benefits from using SOA.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access