Service-Oriented Architecture (SOA) is an approach to defining integration architectures based on the concept of a service.
The key components of a SOA include services, dynamic discovery, and messages.
- A service is a callable routine that is made available over a network. A service exposes an interface contract, which defines the behavior of the service and the messages it accepts and returns. The term service is often used interchangeably with the term provider, which specifically denotes the entity that provides the service.
- Interfaces are often published in public registries or directories where they are categorized based on different services offered, just as businesses and their phone numbers are listed in a phone book's Yellow Pages. Clients (service consumers) can look up a particular service by dynamically querying for services based on various categorization features. This process is referred to as the dynamic discovery of services.
- Service consumers or clients consume services through messages. Because interface contracts are platform- and language-independent, messages are typically constructed using XML documents that conform to an XML schema.
Figure 1 illustrates the various roles in a SOA.
Figure 1. The roles in a SOA
Web services are built on top of open standards and platform-independent protocols. A Web service uses the XML-based Simple Object Access Protocol (SOAP) over HTTP for communication between service providers and consumers. Services are exposed as interfaces defined by Web Service Definition Language (WSDL), whose semantics are defined in XML. Universal Description, Discovery and Integration (UDDI), a language-independent protocol, is used to interact with registries and look for services. All of these features make Web services an excellent choice for developing SOA applications.
When you enable or add Web service interactions that use existing Internet and intranet infrastructure between systems in an architecture, you can create many individual point-to-point integrations, which are difficult to maintain. As organizations move towards service-oriented architectures, which host various deployed services, they require infrastructure service that provides robust communication, intelligent routing, and sophisticated translation and transformation of services.
Application servers provide features like life connection pooling, transaction management, and life cycle management that free the programmer from writing new code for each application. Similarly, an ESB provides common communication and integration services. Because ESBs also use industry standards for most of the services they provide, they facilitate cross-platform interoperability and become the logical choice for companies looking to implement SOA.
The ESB is not a new software product, but a new way to integrate applications, coordinate resources, and manipulate information. Unlike many previous approaches for connecting distributed applications (such as RPC or distributed objects), the ESB pattern enables the connection of software that runs parallel on different platforms, is written in different programming languages, and uses different programming models.
Capabilities of the Enterprise Service Bus
An Enterprise Service Bus exhibits these minimum, or mandatory, capabilities:
- Communication
Supports routing and addressing for at least one messaging style (such as request/response, or publish/subscribe), and at least one transport protocol that is or can be made widely available. This enables location transparency and service substitution, which enables the decoupling of the consumer view of services from their implementation. - Integration
Supports several integration styles or adapters. It enables the provision of services based on these integration capabilities, and decouples technical aspects of service interactions and the integration of services in the enterprise. - Service interaction
Supports an interface definition format and associated messaging model (such as WSDL and SOAP) to allow the decoupling of technical aspects of service interactions. - Management and autonomic
Provides a consistent administration model across a potentially distributed infrastructure, including control over naming, routing, addressing, and transformation capabilities. This enables the management of services in the enterprise.
More advanced ESBs typically offer a number of additional value-added features, including:
- Adapters, to enable connectivity to packaged and custom enterprise applications, as well as to leading technologies.
- Service orchestration engines, to support both long-running (stateful) and short-running (stateless) processes.
- Quality of service and service-level capabilities.
- Presentation services, to enable the creation of personalized portals that aggregate services from multiple sources.
Typical architecture of an Enterprise Service Bus
The architecture of an ESB is centered on a bus. The bus provides message delivery services based on standards such as SOAP, HTTP, and Java™ Messaging Service (JMS). It is typically designed for high-throughput, guaranteed message delivery to a variety of service producers and consumers. The ESB enables the use of multiple protocols (such as synchronous and asynchronous) and performs transformation and routing of service requests. The ESB enables services to interact with each other based on the quality of service requirements of the individual transactions. It also supports different standards such as SOAP, XML, WSDL, JMS, J2EE, JAX-RPC, and so on.
Figure 2 illustrates component types that can connect to an ESB:
- Custom applications, based on standards like J2EE and Struts, which plug into the ESB to provide a user interface to enterprise services.
- Service orchestration engine, which hosts long running business processes, based on standards like Business Process Execution Language (BPEL).
- Adapters, typically built to the Java Connector Architecture (JCA) specification, enable integration with a wide variety of enterprise applications.
- Presentation and portals enable the creation of personalized portals that aggregate services from multiple sources.
- Data services which provides real time view of data from heterogeneous data sources.
- Web services provides a standard means of connectivity to legacy and proprietary integration technologies.
Figure 2. ESB architecture
In this section, I go through a use case scenario for a loan processing system and show how, by adapting an ESB approach using a series of IBM® products as an example, you can deliver loosely coupled independent systems, which interact through consuming messages independently.
Look at an example of a loan processing system with these requirements:
- The user can submit a request for the loan from a Web-based application.
- The loan processing information is submitted through a Web service.
- Based on some predefined rules, such as the type of customer, a workflow system is required to take further actions for approving the loan.
- During the approval process, the loan approver interacts with various server providers to check the credit history of the loan requestor and act accordingly. I assume that server providers provide Web services to access credit history information.
- Once the loan information is approved, the loan information is updated to the legacy system.
With this information, you can provide a high-level framework design of an Enterprise System Bus using various products. Figure 3 breaks down the architecture of your ESB.
Figure 3. Build ESB architecture with IBM products
As shown in Figure 3, you will use WebSphere® Business Integration Message Broker with Rules and Formatter Extension and WebSphere MQ to deliver enterprise bus messaging facilities. The flow of your loan processing application and the corresponding product implementations are:
- Use WebSphere Portal to build the Web-based application with various presentation rules.
- The portal submits Web service requests containing loan and customer information to the Enterprise Services Bus layer.
- Configure appropriate rules and formatter extensions using the Rules and Formatter Extension options provided with WebSphere Business Integration Message Broker to route soap requests to appropriate WebSphere MQ Queues. With rules such as type of customer (high risk/low risk), your application can extract information from the headers and routed appropriately.
- Model business processes for loan processing, which require human intervention, using MQSeries workflow and then expose them as Web services. Set up the users required for human intervention in LDAP or any user directory. In this scenario, the arrival of a message (based on appropriate WebSphere queues using JMS protocol) triggers the appropriate business workflow.
- The loan approver interacts with various service providers to check the loan requestor credit history. To implement this, route SOAP requests to multiple service providers using WebSphere Business Integration Message Broker. Then consolidate multiple SOAP responses and provide the results to loan approver.
- Once the loan is approved, route the loan information to the appropriate WebSphere queue. The WebSphere Business Integration Adapter listening on the queues picks up the message from the queue, maps a message to the business object, which in turn is used to create the loan record in the legacy system.
Today's fast-paced business world demands the ability to change and adapt rapidly. With an Enterprise Service Bus, you can integrate your business applications and processes quickly and easily as you respond to business challenges and opportunities when they arise.
The ESB pattern can improve operational performance and reduce costs while it simplifies the task of connecting dissimilar applications across a network of different operating systems using open standards such as SOAP, XML, WSDL, JMS, J2EE, JAX-RPC, and others.
- Get a product overview of WebSphere Business Integration Message Broker V5.0, formerly WebSphere MQ Integrator Broker.
- Read the Redbook Patterns: Implementing a SOA using an Enterprise Service Bus for more information on the capabilities of the ESB (IBM, July 2004).
- Explore the WebSphere Business Integration Adapters page, and learn how to quickly and easily create integrated processes that exchange information.
- Read the author's article on how to design the SOA frameworks at Design service-oriented architecture frameworks with J2EE technology (developerWorks, January 2004).
- Read the author's article on how to use JMS as a medium for SOAP communications at Programming JMS applications using AXIS (developerWorks, February 2003).
- Learn how Webify's on demand, service-oriented application frameworks can integrate people, processes, and information across business and application boundaries at Webify Solutions.
- Browse for books on these and other technical topics.
- Delve into the developerWorks Web Architecture zone -- it specializes in articles covering various Web-based solutions.
- Get involved in the developerWorks community by participating in
developerWorks
blogs.
Naveen Balani spends most of his time designing and developing J2EE-based frameworks and products. He has written various articles for IBM developerWorks in the past, covering such topics as SOA, JMS, Web services architectures, CICS, AXIS, J2ME, DB2, XML Extender, WebSphere Studio, MQSeries, Java Wireless Devices and DB2 Everyplace for Palm, J2ME, Java-Nokia, Visual Studio .Net, and wireless data synchronization.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
