IBM SOA Reference Architecture
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.
What is Reference Architecture?
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.
Key elements of IBM SOA Reference Architecture
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.
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.
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.
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.
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.
Role of WPS in SOA
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:
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.
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.
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.
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.
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.
Common BPM adoption scenarios
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 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: