JungleSea Inc. is a fictitious online retailer who sells a wide range of products including books, digital media, and electronics. They have a wide network of suppliers and partners, who participate in their ecosystem. JungleSea is under constant pressure to respond quickly to tactical changes happening in the market place, while adopting new business and operating models for rapid strategic change. Architects within JungleSea have been a big proponents of a Business Process Management (BPM) enabled by a Service Oriented Architecture (SOA) approach to help business and IT decisions to be aligned better. By adopting a BPM-SOA approach, they have, over time, demonstrated how they were able to reach the flexibility, reuse, and adaptability that made them better prepared to compete and win against their competitors. The SOA approach also gave them the potential to lower costs (from reuse), and increase revenue (from adaptability and flexibility). JungleSea Inc. had already selected and decided that it would use IBM WebSphere Process Server (WPS) and IBM WebSphere Enterprise Services Bus (WESB) as its core platform for its BPM enabled by SOA.
JungleSea's IT, like any other organization, has multi-faceted, multi-skilled, and multi-leveled employees. From time to time, they hire new people to infuse new blood and thinking into the system. Quite naturally, a BPM-enabled SOA approach can get overwhelming for new hires. This book is about taking the reader through a mentorship journey. The style of the book will be such that the reader will be introduced to the fundamental concepts, then walk them through numerous examples, and finally the journey of building an application using the principles of BPM and SOA and using WPS and WESB.
Alongside the journey, we will be using WPS and WESB as the vehicle to build the SOA application; the various detailed aspects, features, and capabilities of the product will be conveyed though examples. It will also provide practical and pragmatic guidance on various aspects in relation to building the SOA application. Every section will have solutions to common problems and pitfalls. The purpose of this book is to enable the reader to assume the role of the mentee (one who is being mentored; source: Merriam-Webster) and how he/she is introduced to various concepts in SOA, BPM Integration, and so on, and how we apply all these concepts while building a solution. The style of the book is:
A reference book that's organized into chapters, so you can flip right to what you need
A text that addresses the core concepts and practical ideas in BPM, enabled by SOA approach
A primer for getting started with BPM using WPS and WESB
A step-by-step guide for implementing BPM using WPS and WESB successfully
A compilation of WPS and WESB related resources that you can go to for additional help or continued education
In the first part, we will focus on the basics and overview of the key and essential concepts that a reader will require to go forward with the book. We will give a crash course on Business Integration, SOA Fundamentals, and SOA Programming Model. Then we will have the environment set up. Then, to give the reader a feel for the product, build the first Hello Process (with WPS) and Hello Mediation (with WESB) applications.
In the second part, we will build an SOA-based Order Management Application (named Sales Fulfillment Application) for JungleSea Inc. We will guide the reader through the various aspects and functions of WPS and WESB, which are absolutely necessary, through numerous practical examples. Then we will analyze the business requirements and rationalize our thoughts to see if an SOA approach is the right way. Then we will build SOA-based architecture, do a top-down decomposition, and identify use cases (and scenarios), business processes, and services/components.
In the third and final part, having built the SOA Application for JungleSea Inc., we will take the reader through various non-functional topics including Administration, Governance, Management, Monitoring, and Security. We will also discuss deployment topologies for WPS and WESB, performance tuning, and recommended practices. Finally, we will address a series of 'How Do I' questions that a reader typically ask.
In this chapter, we will:
Discuss how a BPM enabled by the SOA approach is the key to achieving success.
Discuss the key building blocks for a business process-driven integration enabled by SOA.
Briefly discuss the value of reference architectures and IBM SOA reference architecture.
Map the key building blocks of BPM enabled by SOA approach with the IBM SOA reference architecture.
Demonstrate what an instantiated solution architecture that has adopted IBM SOA reference architecture would look like.
Start introducing WebSphere Process Server and where it fits in the larger context of SOA. Also discuss its platform architecture and some of the common usage scenarios it will be used in.
Discuss Enterprise Service Bus (ESB) and some of the key capabilities to look for in an ESB. We then introduce WebSphere Enterprise Service Bus Server and where it fits in the larger context of SOA. We also discuss its platform architecture and some of the common usage scenarios it will be used in.
There is no single unique and easy way to define or explain SOA. Given a room full of C-level executives, IT Managers, IT-Architects, and developers with each asked to give a one sentence explanation of what SOA is, for sure, each answer will be different. What is the fundamental message behind SOA? What is it trying to achieve and what does it provides the adopter with? This will help the reader to be able to define or explain it correctly. Let's list some of most common facts he/she may have heard about SOA:
It's a style for building loosely coupled and distributed applications
It's all about service providers providing services to service consumers that conform to contracts
It provides a programming model based on standards defined by various standard bodies including OASIS, WS-*, and so on
Service Oriented Architecture (SOA) is a set of architectural styles, patterns, principles, procedures, and criteria for building solutions and applications.
Such applications exhibit the following characteristics:
Loosely coupled from operating systems, programming languages, and protocols
Expose coarse grained Business Services that can be mapped to business capabilities
Business Services are Modular, Encapsulated, and Reusable
Can be Composed, Orchestrated, or Choreographed
Services expose standardized interfaces
Services are described though contracts and hence discoverable
Leverages a standards-compliant middleware
The process of adopting an SOA is a journey and possibly an ever-evolving, ever-learning, never ending one. With SOA, you progress and mature over time to reach a state where you can truly achieve the benefits, as promised.
Business Processes represent the flow of activities required to complete a business process, which, in turn, help achieve a business objective. They are orchestrations, choreography, or compositions of Business Services targeted to achieve business goals.
Business Service, to be more precise, represents a discrete business function that makes meaningful sense to an organization. A Business Service can be composed of one of the many fine-grained functions or atomic services, and by the true definition of SOA, encapsulation, it can dynamically behave depending on how it is invoked. Services form the building blocks of SOA and should be reusable, decoupled, exposed in a standardized fashion, and derived from disparate IT resources.
Components realize and provide services from one or more applications and these components are wrapped into the Business Services. Components help realize not only the functionality of the services they expose, but also ensure that their Quality of Service (QoS) is good, as guaranteed by the service provider. The following figure depicts how all of the above are interrelated and interconnected at a very high level.
A fact of reality in many organizations today is that they have many applications which are disparate in terms of technology, programming languages based on which they were written, capabilities exposed through interfaces, services, or APIs, and so on. To create a purchase order in an order entry system, we will need information about the customer from customer information management systems, product information from product catalog, and so on and so forth. Hence there is a constant struggle to make all the applications integrated.
IT is under constant pressure to address these requirements for managing layer upon layer of legacy systems that may or may not interoperate with any degree of simplicity. This is where integration comes in and helps connect applications together with the right communications , data semantics and server infrastructure as well as the right business process capabilities to give IT and enterprise leaders the ability to create composite applications that meet new flexible and dynamic business needs.
Getting the integration right is one of the key aspects of getting SOA right, and it enables the integration of the disparate applications. Integration is only one half of the struggle; there are several techniques and modes in which you can integrate applications. They include but are not limited to:
Presentation-based integration that provides interaction and collaboration capabilities
Process-driven integration that helps streamline business processes
Information-centric integration for unified access to information from heterogeneous data sources
Bare bones connectivity-based integration
A Business Process Management (BPM) approach enabled by SOA is key to achieving operating efficiencies and gaining a competitive advantage for any organization. Organizations need a BPM enabled by SOA framework, which will allow them to constantly evolve their collaborative process automation and process improvement approaches. So what is this BPM enabled by SOA framework and what will it comprise?
You may have been reading a lot about Business Process Management. What is it? BPM is a discipline that focuses on process modeling, design, automation, management, and continuous improvement. It is not a technology or a product. It covers the full range of application-to-application, inter-application, workflow, and person-to-person process management, including process modeling, design, automation, monitoring, management, and continuous improvement. The core and basic components of BPM include (but are not limited to):
Modeling and simulation
Policies and Rules
Collaboration through human task processing
Process execution including choreography and orchestration
Business Activity Monitoring (BAM)
Support for common Business Objects (BOs)
Intuitive process definition tool
Customizable work portal
Historical process analysis
Wide range of integration capabilities and adapters
Process Tracking and Notification
Process Performance Analysis
System Scalability and Process Performance
Provision for parallel human task approvals
Businesses very well understand that their core (and differentiating) business processes will have to be automated (post integration) and be able to externalize these from end applications. Process-driven integration is about bringing people, processes, information, and systems together using the Business Process management (BPM) approach enabled by an SOA approach. This approach requires a solid technology platform and of course an over-arching methodology that will offer you prescriptive guidance on how to deliver solutions. So what are these core building blocks? They include:
Now let's look briefly at each of these core building blocks/capabilities that are needed for achieving success in a business process-driven integration provided, as shown in the following figure:
This is the starting point where you discover and document the various other business process(s) (using a modeling notation such as Business Process Modeling Notation BPMN) that might exist on paper or even in the minds of some subject matter experts and document it with business modeling. Also, once the processes are modeled, you will have the ability to run model simulations and try out various 'what-if' scenarios to forecast what would happen if you altered the process. Based on these simulations, you arrive at an optimal process design. The process modeling exercise also helps to identify the SOA services that will have to be specified, realized, and also in many cases, reused.
Once the business processes have been modeled, they will have defined in an executable format (such as Business Process Execution Language (BPEL)) and deployed on a standard-based process execution platform that supports both the business process execution environment and the packaging of business tasks as services. The assembly, sequencing, orchestration, and choreography of existing services and new services results in the realization of a deployable process model. This assembly should be based on industry standards such as Service Component Architecture (SCA). The execution platform must also support human interaction for both participants in the business process and administrators of the business process. The runtime should also provide a variety of administrative capabilities required to configure the environment for the applications that are installed.
Enterprise Service Bus (ESB) provides the underlying connectivity and backbone infrastructure for SOA to connect applications. An ESB is essentially an architecture pattern that provides capabilities including connectivity, communications, message queuing, message routing, message transformation, reliable messaging, protocol transformation and binding, event handling, fault handling, message level security, and so on. It enables loose coupling between service consumers and service providers, and thus enhances the ability to rapidly change and introduce new Business Services into the environment. An ESB typically would leverage a service registry and repository to provide information about service endpoints.
Policies and rules can make the business processes highly flexible and responsive. A business policy represents a key piece of domain knowledge, externalized from a business process and is applied when a particular request context is met. An example could be, all purchase orders that include order items such as Oxygen Canisters are deemed critical orders, order amount worth over $1000 has to be shipped overnight, and so on. Metadata elements such as "order item" and "order amount" are deemed as the business domain vocabulary and values of which can change (you can add "Defibrillator" along to the critical items list), which will have to be externalized from the business process.
A business rule is a statement that defines or constrains some aspect of the business. They are typically atomic and cannot be broken down further. An example would be, say, in a loan origination business process, at each step of the process, business analysts identify rules that must be met by the loan staff and underlying systems. In traditional banking systems, these rules reside within the loan origination system itself, so changing the rules means modifying the application. When the rules are abstracted from the loan origination systems, they reside in a business rules engine. As a result, bank management can identify those activities that change rapidly, such as decisions relating to FICO® scores, and then, instead of changing the process and its underlying application, they change only the decision point within the business process, which in turn resides in a business rules engine (external to the process itself). This capability adds agility to the process by reducing the time, costs, and resources necessary to respond to changing conditions.
While the business processes are deployed and are executing, data must be captured that provides information about the processes. This data can be analyzed to determine if the business processes are performing as expected. Both business-related information and IT-related information can be captured for monitoring. You should also be able to visually define dashboards based on Key Performance Indicators (KPI), which are based on the monitor model deployed for the business process, providing a visual display of the business process status.
For a process-driven integration approach coupled with SOA to succeed, a common and enterprise level information model is required, which becomes the basis for the messages exchanged between processes and services, and also serves as the glossary for the business policies and rules. When dealing with applications that have disparate data and information models, use of this common information model shields the business processes away from the gory details of each and every individual system. The ESB provides capabilities to transform from this Canonical Data Model to the target system's format. The Canonical data model minimizes dependencies between integrated applications that use different data formats. Typically, one could leverage industry standards such as Tele Management Forum's Shared Information/Data Model (SID) and so on to define the information models.
A mind map is a diagram used to represent words, ideas, tasks, or other items linked to and arranged around a central keyword or idea. Mind maps are used to generate, visualize, structure, and classify ideas, and as an aid in study, organization, problem solving, decision making, and writing.
A mind map, as shown in the following figure, sums up all the previous concepts.
IBM's SOA Reference Architecture defines a vendor and technology agnostic set of comprehensive IT capabilities that are required to support your SOA at each stage in a typical SOA life cycle. When an organization defines a solution architecture based on this reference architecture, they would not need all of the capabilities needed initially. But over time, to be successful in SOA, all the capabilities need to be evolved and added.
A Reference Architecture captures the essence of the architecture of a collection of systems. It models the abstract architectural elements in the domain or a solution area, independent of the technologies, products, and protocols that are used to implement the domain. It differs from a reference model in that a reference model describes the important concepts and relationships in the domain focusing on what distinguishes the elements of the domain. Thus reference architecture is useful for:
Reference architecture is typically abstract and is abstract for a purpose. You typically instantiate or create solution/system architectures based on the reference architecture. Example reference architecture includes Unisys 3D Blueprints, IBM Insurance Application Architecture, and NGOSS reference architecture from the TM Forum, and so on.
The IBM Software Reference Architecture is a reference model that lets you leverage information, applications, and tools as services in an interoperable, system-independent way. The subsequent diagram shows the IBM SOA Reference Architecture organized around the key capabilities required for building any SOA-based solution.
Information Services provide the capabilities required to federate, unionize, and transform data from one or multiple applications or data sources and expose them as services.
Access Services allow access to the end applications, legacy applications, pre-packaged applications, enterprise data stores (including relational, hierarchical, and nontraditional, unstructured sources such as XML and Text), and so on using a consistent approach. These typically leverage the business application services.
Infrastructure Services provide security, directory, IT system management, and virtualization capabilities to the SOA solution.
So what is the relationship between the process integration, key capabilities needed for successful process integration, SOA, IBM SOA reference architecture, IBM WebSphere Process Server, and IBM WebSphere Enterprise Service Bus? The answer is pretty obvious. The book is about how you build SOA solutions with these two products and these two products indeed provide a majority of the capabilities, if not all, which are essential to a successful SOA. Now let's delve into what these two products are all about.
Having defined the essential elements for a BPM enabled by SOA approach, having explained the need for a reference architecture, and in particular, what IBM's SOA reference architecture is all about how does it all come together? How would a (reference) solution architecture, based on the IBM SOA Reference Architecture, look? The following figure shows one such instantiation of the "BPM enabled by SOA" solution architecture. It incorporates all of the building explained above, as categorized and organized into the appropriate IBM SOA reference architecture buckets/layers. Also, what each layer and each building block should have as capabilities within itself is explained.
In this book we will cover WebSphere Integration Developer v7.0, WebSphere Process Server v7.0, and WebSphere Enterprise Service Bus v7.0 built on top of IBM WebSphere Application Server-ND v22.214.171.124.
WebSphere Process Server (WPS) is one of the key and core products in the IBM WebSphere BPM suite. Referring back to the key capabilities needed for a successfully process-driven integration approach enabled by SOA, WPS addresses capabilities including Business Process Execution, Business Rules, Enterprise Service Bus, and a key enabler for Business Process Monitoring. WPS platform provides a standards-based uniform programming model for representation of data, invocation of services, and structure of composite applications. It provides a unified tooling, namely, WebSphere Integration Developer (WID) for the visual development of composite applications.
As explained in the previous sections, process integration is fundamentally built on the concept of an SOA. In recent times, most of the applications expose web services. These services, which may be very fine-grained or atomic in nature, will have to be assembled into coarse-grained services that make meaningful sense to the business. A process-driven integration leverages these Business Services as business tasks in the larger choreography or orchestration of a business process. Because of the fact that fine-grained atomic services are assembled into coarse-grained business services, the use of the service is independent of the IT infrastructure needed to accomplish the task. Each Business Service then becomes a building block that, when combined with other Business Services, can become the fundamental building block to realize an end to end business process. The structuring of business processes, in this way, provides a flexible solution to real business problems, allowing the creation of new and modified processes easily. You can use WPS to develop and execute standard-based, component-based Business Integration applications using an SOA approach. The use of standards-based technology, including Web Services, helps to make the SOA vision a reality.
WPS leverages a programming model, which is very fundamental to understanding how applications are developed in WPS and WID (as explained earlier, WID is the integrated development environment for WPS). The programming model has three parts:
Invocation is the way in which a request is made from one piece of code to another. Programmatically, there are several methods of invocation including REST, HTTP, EJB stateless session beans, JAX-WS, JAX-RPC, JDBC for communicating with databases, JMS for messaging, and so on. WPS has adopted the Service Component Architecture (SCA) specifications as the basis for its invocation model. SCA is a set of specifications that describe a model for building applications and systems using an SOA approach. SCA divides the steps in building a service-oriented application into two major parts:
The implementation of components which expose (export) services and consume (import) other services
The assembly of sets of components to build business applications, through the wiring of references to services
SCA uses Service Data Objects (SDO) to represent the business data that forms the request and response values of service and/or components. SCA supports bindings to a wide range of access mechanisms used to invoke services and also through both synchronous and asynchronous programming styles.
Data Model—defines how data can be represented
Programmatically, there are several ways to represent data—EDI message, JDBC row set, JMS message, Java Persistence API (JPA), and so on. WPS has standardized the way in which data is represented and will be using Business Object (BO). BOs are extensions of Service Data Objects (SDO) to provide an abstraction layer for data access. Business Objects include some extensions that are very important for integration solutions and further describe the data that is being exchanged between Service Component Architecture-based services. This includes metadata-like change history or information on the context of the data such as update, create, delete, and so on.
Composition Model—how you put together a series of invocations
WPS has adopted Business Process Execution Language (BPEL) as the way to define the overall business process. When the business process accesses data, it does so by making calls to SCA services passing Business Objects.
We will venture into more details about SCA, SDO and BO, and BPEL in the coming chapters.
WPS at its core is built on WebSphere Application Server, providing a robust application server runtime with capabilities that the process server implementation can exploit such as Java Message Service (JMS) messaging and enterprise beans. It can also make use of the application server qualities of services such as transactions, security, and clustering. The following image shows the platform architecture of WPS and the different components it is made up of.
The foundation of SOA includes the main components, namely, the Service Component Architecture (SCA), Business Objects (BOs), and the Common Event Infrastructure (CEI). The CEI provides the foundation architecture for the management and handling of events produced by business processes. This is essential for enabling the monitoring of business processes with products such as the WebSphere Business Monitor.
On top of the SOA Core are a set of Supporting Services, which provide the transformation primitives required when building SOA solutions using SCA and BO. These include:
Interface maps which enable mapping to semantically similar but syntactically different interfaces.
Business object maps, which enable the transformation of business data between fields of Business Objects.
Relationships enable the correlation and synchronization of data representing the same business entity stored in multiple backend systems.
Selectors provide for a dynamic invocation of a target.
Service Components provide different component types that can all be assembled together when building an SOA solution.
Business Processes, which are defined using BPEL, realize an executable version of a business process in which the different activities of the process are carried out by making calls to the individual SCA services that implement the specific activities.
Human Tasks provide the human task capabilities for people to participate and collaborate with the business processes. Human tasks can be integrated directly into the BPEL.
Business State Machines are another way of modeling a business process that are highly event-driven and are well suited to being thought of in terms of a state transition diagram. The Business State Machine component allows you to model the business process using similar constructs as UML 2.0 state machine support and then generates BPEL for the implementation.
Business rules enable the implementation and enforcement of business policy business rules and also for them to be managed independently from other aspects of an application. There are two styles of business rules, if-then rule sets and decision tables. A Web client is provided where the parameters of business rules can be changed by a business user using a natural language.
Adapters are used for integration with various applications and backend systems that are external to the WPS. Adapters are categorized into technology and application adapters. These adapters are compliant with the Java Connector Architecture (JCA) 1.5 specification.
In the collection of patterns for e-business, IBM has leveraged its vast experience from its architects and solutions and developed various classes and categories of patterns that can be applied to create solutions rapidly, whether for a small local business or a large multinational enterprise. The site http://www.ibm.com/developerworks/patterns/ breaks down these pattern assets into the following elements:
All of the above integration patterns give interesting insight into how to integrate applications and data within an individual business pattern. At its highest level, application integration by itself is divided into Process Integration and Data Integration patterns.
Now let's look at some of the most common BPM adoption patterns, and more specifically, how WPS can be adopted in real-life client scenarios. IBM's BPM adoption patterns are classified into the following broad categories:
Automation of insurance rate-quote-issue process across multiple product lines
Customer billing and invoice inquiry or dispute process automation in the telecommunications industry
Order handling business process automation applicable to several vertical industries
Member/Patient claims handling processes automation in healthcare
Automation of student registration/on-boarding in education
Capture Insights for Effective Actions—Achieve visibility through monitoring and capturing new insights to seize opportunities and mitigate risks. Business Activity Monitoring (BAM), in combination with role-based dashboards, augments and helps deliver this capability. Examples include:
Define time-bound KPIs on loan origination and approval business processes in the banking industry and act on them.
Detecting the root cause of service activation failures in the Telecommunication industry and acting on them.
Based on strategically defined business goals to improve customer satisfaction (defined as KPI) and improve customer problem handling business processes.
Define fraud detection rules (too many withdrawals on an account from ATM, high rate of claims requests, and so on) and act on them appropriate by automating the detection and acting upon processes.
Leveraging existing SOA service models and industry content to rapidly enable process modeling and automation efforts. IBM's Industry Content Packs is a good example here.
Define library of KPI models based on the particular industry’s information model, business terms and concepts and use it as a means to measure and monitor strategic business goals.
Based on changing customer and market opportunities, make changes on-the-fly to business processes. Example would be adding new channels from which an order handling process can invoke dynamic behavior for certain types of customers.
An Enterprise Service Bus (ESB) is fundamentally an architectural pattern. As explained through the IBM SOA reference architecture, from an SOA point of view, an ESB provides the connectivity layer between services and serves as the core backbone for the SOA—it's the nervous system. The service consumers in a service interaction are connected to the ESB, rather than directly to one another including the service provider. When the service request connects to the ESB, the ESB takes responsibility for delivering its requests, using messages, to a service provider offering the required function and quality of service. The ESB facilitates requester provider addresses despite mismatched protocols, interaction patterns, or service capabilities. An ESB can also enable or enhance monitoring and management. The ESB provides virtualization and management features that implement and extend the core capabilities of SOA. So what are the core capabilities that an ESB should support? The fundamental capabilities of an ESB include:
Mediations and Communications
Quality of services
Management and autonomic services
SOA mandates that the service providers and the service consumers be loosely coupled and support the use of explicit interfaces. This flexibility enables IT change with very limited impact such as the update or replacement of a given Business Service or the development of a new composite solution which leverages existing services. That is, the power of the ESB enables you to realize the full value of SOA. As shown in the following figure, interposing the ESB between the participants in an SOA ecosystem enables you to modulate their interactions through a logical construct called mediation. Mediations operate on messages in transit between service consumers and service providers. For complex interactions, mediations can be chained sequentially. The following figure lists the core capabilities that are provided by WESB and how they interact with the various backend applications and how they expose them to the service consuming layers north of it (Process Services and Business Services). In some cases, Interaction Services can also become consumers of these WESB mediations. But it is always preferable to have the mediation wrapped into Business Services because more than likely, you would want to expose core business functions to the service consumers. In doing so, you can account for service variability within the Business Service through the use of business policies and rules. An example would be that WESB can expose mediations that manipulate customer data from one or many customer information management systems. Which customer information system is chosen will depend on the business context of the request (examples include customer location – North America or Europe, type of customer—residential or commercial, service level agreements with the customer, or request priority and so on). All these account for service variability behavior and how the service should behave based on a combination of such cases. Having such a kind of processing logic within the WESB mediation flows is not preferable for the simple reason being it can change as business conditions change. Hence WESB, in an SOA architecture, should be positioned to deal with the hardcore integration and connectivity needs and should not be overloaded with capabilities it is not meant to do architecturally.
As depicted in the core platform architecture for WPS (as mentioned earlier WPS includes WESB), WESB is also built on top of WebSphere Application Server. WESB mediation flows provide routing, transformation, and logging operations on the messages. The information that governs their behavior is often held in headers flowing with the business messages. WESB also adopts the same programming model as WPS (explained in the previous sections), but also introduces the Service Message Object (SMO) pattern for SDOs to support this pattern of operating on the messages, including its headers. We will discuss in detail about SMO in the coming chapters.
As shown in the WPS platform architecture, mediation flows belong to the support services. The mediation flows provide capabilities that include:
Centralizing the routing logic so that service providers can be exchanged transparently
Performing tasks such as protocol translation and transport mapping
Acting as a facade to provide different interfaces between service consumers and providers
Adding logic to provide tasks such as logging
The following figure is an example of a mediation flow that provides routing, transformation, and logging operations on the messages through the use of Mediation primitives. Mediation primitives are the smallest building blocks in WESB and are contained within a mediation flow. With Mediation primitives, you can change the format, content, or target of service requests, as well as log messages, perform database lookups, and so on and so forth. WESB can interconnect a variety of different service consumers and providers using standard protocols including JMS, SOAP/HTTP, SOAP/JMS, HTTP, and so on. It supports web services standards including WS-Security and WS-Atomic Transactions. It also includes Universal Description Discovery and Integration (UDDI), Version 3.0 that can be used to publish and manage service end point metadata, which enables service definitions to be made available to client applications. WESB also supports IBM WebSphere Service Registry and Repository and is used for cases where you may have to do dynamic endpoint lookup.
There are three categories of usage patterns when building WESB-based solutions:
Now let's look in more detail at some of the most common usage scenarios that belong to the preceding categories that WESB can be used in.
These are the very basic set of patterns that allow service interactions to occur via the WESB. Types of interactions include:
These are the next level of message exchange and manipulation patterns. This category of patterns typically deals with message mediations and having to "work on" the messages before allowing service interactions to occur. Some example message exchanges include:
Data Transformation —transforms and translates the incoming message from one schema format to the target schema format. You may have to perform and apply data validation, integrity, and transformation rules.
Message Observer—monitors and observes messages (non-invasively) as they pass through the mediation by applying filters. Examples could be watching out for too many ATM transactions on the same account, observing response time from a particular backend application, and monitoring for SLA breaches, logging, and auditing messages.
This category of patterns deals with how WESB can be deployed in a variety of ways including, federated, brokered, and so on.
Global ESB: All services share one namespace, and each service provider is visible to every service requester across a heterogeneous, centrally administered, geographically distributed environment. Used by departments or small enterprises where all the services are likely to be applicable throughout the organization.
Directly connected ESB: A common service registry makes all of the services in several independent ESB installations visible. It is used where services are provided and managed by a line of businesses but made available enterprise-wide.
Brokered ESB: Bridge services that selectively expose requesters or providers to partners in other domains regulate sharing among multiple ESB installations that each manages its own namespace. Service interactions between ESBs are facilitated through a common broker that implements the bridge services. Used by departments that develop and manage their own services, but share a few of them or selectively Access Services provided across the enterprise.
Federated ESB : One master ESB to which several dependent ESBs are federated. Service consumers and providers connect to the master or to a dependent ESB to Access Services throughout the network. Used by organizations that want to federate a set of moderately autonomous departments under the umbrella of a supervising department.
It's quite possible for an organization to have multiple ESB configurations/topologies. It's all driven by business needs and the ESB topologies may change as business requirements change. The flexibility and "service virtualization" provided by the ESB is achieved through what architects call "separation of concerns", the clear separation between the applications which run the business (including Business Services and business processes) and the ESB (the infrastructure for connecting applications and services together).
IBM has three ESB products in its offering portfolio:
WebSphere Enterprise Service Bus
WebSphere Message Broker is used in scenarios where the infrastructure has heterogeneous applications with standard and non standard interfaces, protocols, and data formats
WebSphere DataPower Integration Appliance XI50 is Appliance-based ESB for simplified deployment and hardened security
When selecting WESB, here are some of the most typical considerations or topics to consider include:
Focus on standards-based interactions using XML, SOAP, and WS*
Mediate and integrate to existing systems using JMS, MQ, Web Services, and so on
Support for protocols including HTTP, MQ, JMS, RMI, and so on
Need for message transformation using XSLT
Use WPS for process choreography and orchestration (common tooling, runtime infrastructure)
Your team has skills with WebSphere Application Server Administration and Java coding
Reliability and extensive transactional support are key requirements
The IBM SOA Foundation is an integrated open standards-based set of IBM software, best practices, and patterns. The key elements of the IBM SOA Foundation are the SOA life cycle (model, assemble, deploy, manage), reference architecture, and SOA scenarios. IBM's SOA Foundation lifecycle consists of the following iterative phases and some of the key activities performed:
Service Components Assembly based on business design
Service specification, realization, and implementation
Business process assembly and implementation leveraging new and existing services and components
End application connectivity including routing, message transformation, protocol transformation, and so on
Creating the monitoring model based on KPIs
Govern (that spans all phases)
When developing SOA-based solutions, you can adopt the SOA lifecycle by mapping what activities are performed in which phase and also identify which tools and products can be used to fulfill activities in that phase. The lifecycle, as shown in the following figure, outlines the key IBM products that could be used to fulfill some of the key activities in each phase to deliver the solution. Products marked in bold are the ones we will be covering in this book.
As mentioned earlier, SOA is not a technology but glue that cements the holistic relationship between IT and business. BPM again is a practice of focusing on the improvement of operations efficiencies within an organization by modeling, automating, and monitoring their core business processes. Both BPM and SOA are an art into themselves. Some of the key concerns, questions, and topics that arise when venturing into the adoption of BPM and SOA may include:
How to identify process metrics and KPIs which are not only aligned with my core business performance objectives, but also help me constantly improve?
How can I set up and implement a process governance and management framework?
How to identify an implementation of a continuous and iterative BPM process optimization cycle that improves business and process agility?
How to realize the value of applying BPM to deliver business processes?
What are the set of phases, associated activities, and deliverables that I should adopt for the BPM solution development and management?
So when I'm building solutions with a BPM enabled by SOA approach, what are the lifecycle phases and what do I typically do in each of the lifecycle phases? Also, how and where do WPS, WESB, and potentially other products from IBM apply to each of the lifecycle phases? Let's look at IBM's BPM enabled by SOA methodology.
IBM's BPM enabled by SOA methodology provides a structured set of activities that you can manipulate and use in the build out of SOA and BPM based solutions. By using the method correctly, you can be assured that the solution including the business processes and Business Services will be aligned with business goals and that it creates a framework for continuous improvement. As shown in the following figure, the BPM enabled by the SOA method has five primary phases, which are as follows:
For detailed information on IBM's BPM enabled by SOA methodology, refer to the IBM Redpaper, Business Process Management Enabled by SOA by Anthony Catts and Joseph St. Clair:
In this chapter, we discussed why when building IT solutions a process-driven integration combined with an SOA approach is critical for achieving dynamism. We also discussed the core capabilities needed for a process integration approach, IBM's SOA reference architecture, and IBM's Business Process Management platform including WebSphere Process Server (WPS) and WebSphere Enterprise Service Bus. We saw how WPS fits in an SOA approach, how it helps deliver an SOA infrastructure to orchestrate, mediate, connect, map, and execute the underlying IT functions and systems. We also discussed the ESB as a pattern and essential considerations to make when choosing an ESB. Then we discussed how WESB complements an SOA approach, how it enables connectivity and messaging capabilities, and hence provides a smart approach to SOA. We then discussed the IBM SOA lifecycle, various activities performed in the appropriate phases, and products from IBM that help accomplish activities within phases. Finally, we discussed IBM's BPM enabled by SOA lifecycle methodology, which can be used as a practical method when building SOA-based solutions.