SOA Essentials

By Robert Glass, Principal Solution Architect at Oracle’s National Security Group

Today, you can’t walk around the corner without hearing some mention of Service Oriented Architecture (SOA). Every week, I encounter SOA being misunderstood, misinterpreted, and misrepresented. The Intelligence Community (IC), amongst others, has caught SOA fever. In the last several years the IC has been moving towards SOA with Net-Centric initiatives (i.e. NCES, Horizontal Fusion, and various SOA references), but the problem is that people in the IC have differing definitions of what this means and how this impacts them.

In reality, the DoD and IC today are characterized by stove piped, data dispersed, heterogeneous systems with hard coded, inflexible processes, long lead times to change those processes and uninformed business stakeholders where rip and replace is not an option. Integration technology, which has been around for several years, is attempting to address this problem by shifting towards a standards based, Service-Oriented Architecture.

Based on my experience within the IC and now as a SOA Solution Architect for Oracle, I have put together a list of essential components for building a SOA. These components are as follows:

• Web Services - A service that is called in a standard way, so anyone can use it without knowing its internals
• Enterprise Service Bus - A way for services to communicate with each other
• Orchestration - A means for plugging services together
• Services Management - Manage and Secure SOA, via WS-Security & Identity Management (IdM)

Figure 1: Essential Components of SOA

This article will define and describe the benefits of SOA and provide the essentials necessary to identify, recommend and implement your own SOA solutions. I hope to dispel what SOA is and isn’t and provide you the essential components of a SOA.

First, before we get into these essential components, we need to stop and define some key concepts of SOA. There are several formal definitions for a SOA; the OASIS¹ group has a SOA Reference Model which defines SOA as "a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations"². The Open Group has defined SOA slightly different to be “an architectural style that supports service orientation” which “is a way of thinking in terms of services and service-based development and the outcomes of services.³ They continue by defining a Service as follows:

• Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports)
• Is self-contained
• May be composed of other services
• Is a "black box" to consumers of the service

In other words, a Service-Oriented Architecture (SOA) is an architectural style with well-defined loosely coupled services that can be published and discovered in a uniform standards-based way using distributed capabilities. These services expose business functionality over the network usually as a Web Service in a standards-based language neutral manner via a Web Services Description Language (WSDL) which is an XML based contract for the Web Service. Since the services are black boxes and are self-contained they can be coupled and de-coupled like legos to create new processes dynamically. These key elements of the SOA paradigm are illustrated in figure 2.

Figure 2: SOA Paradigm

Some of the benefits of SOA include:⁴

• Interoperability - Leveraging industry standards enables legacy and stove piped applications to seamlessly interoperate
• Reuse - Since these applications are service-enabled, these services can be reused to create higher level business processes
• Agility - The flexibility of standards allow implementers to rapidly adapt to changes as their business needs change
• Visibility - These processes also improve business visibility by enabling rapid integration into service-enabled enterprise portals and providing in-flight monitoring capability aiding in business decision-making
• Reduced Costs - Redundant services can now be eliminated and systems can be consolidated reducing the costs of operation and maintenance (O&M). As systems are upgraded using SOA and legacy systems are phased out, lower integration and O&M costs will provide more funds to enable new services to be built
• Standardization - As you standardize operational procedures you begin to gain better insight and control allowing you to have better visibility and governance of security and services management

Now that we have a definition for SOA, you can see why the first core component of a SOA is Web Services. Web Services expose your service via a self-described interface (WSDL) that can be invoked by sending a SOAP message to the service endpoint (the location of the service). SOAP, which was previously an acronym for Simple Object Access Protocol, is now the name of a protocol for exchanging XML based messages over a network usually over HTTP.⁵ See Figure 3.

Figure 3: Elements of a Web Service

Web Services provide core capabilities such as integration of heterogeneous applications and data, interoperability across disparate platforms, and reuse of business functionality. Existing technology assets which can’t easily be exposed as a Web Service can now be exposed using adapters which talk natively to the asset exposing it as a Web Service.⁶

In the early days of Web Services these specifications were just that and no one knew exactly how they played with each other. Web Service leaders from across the service community came together and formed the Web Services Interoperability Organization (WS-I) to address this problem. WS-I is chartered to develop best practices (profiles) and tools for Web Services and interoperability. Today, there are several profiles,one of which is the Basic Profile that provides interoperability guidance and specifies a set of standards and versions, such as HTTP, SOAP, WSDL, and XML, as well as usage for a basic Web Service.⁷

If you stop with Web Services then you have just created a point-to-point Web Services architecture. To complete the definition of SOA, "...where loosely coupled services are published and discovered", you need a Service Registry. A Service Registry is a catalog of services and related metadata organized by taxonomies.⁸ Taxonomies are basically a way to classify and organize services hierarchically (i.e. such as file directory). The Registry facilitates SOA adoption by enabling users to search for and publish services that meet specific criteria as well as browse offerings available from other providers using the Universal Description, Discovery and Integration (UDDI) standard.⁹ UDDI is an open standard that enables users to publish their services and discover others and define how those services interact over the network.

Next, you need a way to connect, transform, and route these services from place to place; thus, our next component (see figure 4) is an Enterprise Service Bus (ESB). An ESB’s main function is to connect to these previously mentioned Web Services whether thru WSDL or an Adapter, then transform the payload to and from data types and route these request across the network.

Figure 4: Enterprise Service Bus Component

An ESB provides a virtualization layer between clients and the resources they are trying to reach. As an example, take a database that resides on server A, then, using a database adapter, you can expose this resource as a Web Service through the ESB. The ESB can then provide a service endpoint for this service thus virtualizing the fact that the database resource is running on server A. The benefit here is when the database changes servers to B, the clients don’t need to make changes in their code. Instead, the ESB just changes to server B rather than A.

The concept of an ESB has probably been the most confusing entity within the IC. I constantly hear that having an ESB equates to having SOA; that is quite far from the truth. An ESB provides an easy way to get to resources and expose them as Web Services; however it is just a component of SOA. When used properly the ESB can provide a layer of abstraction to provide the connectivity to these legacy systems that cannot easily be "web servicized," to support the necessary transformation and routing across the network.

Another very important capability within a SOA is the ability to mesh services together to create business processes and composite applications, otherwise known as Orchestration, the next component of a SOA. The standard language today for implementing Orchestration is Business Process Execution Language (BPEL). BPEL is a way of weaving together Web Services to form business processes (e.g. an Auto Loan, tasking an asset), which in themselves are Web Services.

With BPEL, we define orchestration logic as the business logic that sequences, coordinates and manages conversations among Web Services. Such orchestration logic can be as simple as a single two-way conversation or as complex as a nonlinear, multi-step business transaction with exception handling and compensation.¹⁰ Taking the Auto Loan example shown in Figure 5, the orchestration logic would include extracting the customer profile from an existing database, requesting the credit rating from an internal service, and then asking the two loan processors in parallel to process the loan application. If an exception occurs it is tasked to a human stakeholder using human workflow.¹¹

Implementing the industry standard for orchestrating business processes and Web services will not only speed the implementation and deployment of new integration projects, but will also reduce the overall cost of management, modification, extension, and redeployment of existing processes.¹² (See Figure 5 on the next page)

As we are all aware security is a big concern and you can’t architect a system without thinking about security. Security is a driving force for the last essential component of SOA, Services Management, a key to SOA Governance. The main goal of SOA security standards is to provide a basis for interoperability among heterogeneous services across your enterprise.¹³

Figure 5: Sample BPEL Process from an Auto Loan

Until recently, the burden of Web Services security rested with the implementer. Developers would code security into their services creating environment "silos" that were difficult to manage and costly to maintain. SOA deployments have become more and more complex, creating additional challenges that developers alone cannot meet anymore, such as cryptographic data protection, identity management, and governance.¹⁴

Figure 6: Sample BPEL Prosess with Policy Enforcement

Declarative security solves this problem and allows a service implementer to worry about the implementation and security personnel to worry about security. Using standards based compliant solutions for security allows for a centrally defined Policy Decision Point (PDP) for multiple Web Services and the ability to enforce these policies at runtime using Policy Enforcement Points (PEP) as illustrated in Figure 6.

In summary, SOA helps bridge the gap between the stove-piped heterogeneous data systems by leveraging standards. There are several essential components of a SOA which (i) allow you to expose your code or legacy system with Web Services (ii) connect, transform, and route these service with an ESB (iii) orchestrate services using BPEL and (iv) be able to secure and manage these services.

Vendors, such as Oracle , provide complete, integrated standards-based SOA Suites that enable building a SOA and deploying web services to your chosen middleware platform.

¹ Organization for the Advancement of Structured Information Standards(OASIS)

² http://www.oasis-open.org/committees/download.php/19697/soa-rm-cs.pdf

³ http://opengroup.org/projects/soa/doc.tpl?gdid=10632

⁴ http://www.oracle.com/technology/tech/soa/pdf/soa-suite-wp.pdf

⁵ http://en.wikipedia.org/wiki/SOAP

⁶ http://www.oracle.com/technology/oramag/oracle/04-jul/o44web_feature_basics.html

⁷ http://www.oracle.com/technology/oramag/oracle/04-jul/o44web_feature_basics.html

⁸ http://www.oracle.com/technology/tech/soa/pdf/soa-suite-wp.pdf

⁹ http://www.oracle.com/technology/tech/soa/pdf/soa-suite-wp.pdf

¹⁰ http://www.oracle.com/technologies/integration/pdf/bpel-case-whitepaper.pdf

¹¹ http://www.oracle.com/technologies/integration/pdf/bpel-case-whitepaper.pdf

¹² http://www.oracle.com/technologies/integration/pdf/bpel-case-whitepaper.pdf

¹³ http://www.oracle.com/technology/products/webservices_manager/pdf/Oracle-SOA-security-whitepaper-Jan08.pdf

¹⁴ http://www.oracle.com/technology/products/webservices_manager/pdf/Oracle-SOA-security-whitepaper-Jan08.pdf

¹⁵ http://www.oracle.com/technology/tech/soa/pdf/soa-suite-wp.pdf

About the Author

Robert Glass is a Principal Solution Architect at Oracle’s National Security Group. His focus is on Service Oriented Architecture within the Intelligence Community and he has worked within the community for over 15 years. He holds a M.S in Software Engineering from George Mason University.

Author Contact Information

Robert Glass
Email: robert.glass@oracle.com