The Fundamental SOA Programming Model

Introduction

IBM's SOA programming model provides a set of rules and languages that lets you focus on creating an implementation of a business design. The programming model addresses the aspects of service components and the data that is exchanged between services as service data, over a service bus. Now, let us look at the key aspects of this programming model.

Overview

Service Component Architecture

We design and build applications (for example, customer billing, order management, customer care, account opening, loan underwriting and so on) so that an organization can run their business effectively and efficiently. Applications can be looked at as a collection of software components that are assembled or integrated together for a particular purpose. Ideally, you should have the freedom to implement the different components in the technology of your choice. However, at times you may have to inherit or work with existing systems, technologies, or work with third parties who have a different set of technologies. When you adopt an SOA approach to building applications, these components can be viewed as services. When we look at the constructs that make up a service, two things immediately come to mind:

§  The What part: Data that should be passed to the service and data received back from the service

§  The How part: The mechanism required to realize the service and how it can be invoked or can be made available to a service consumer

For each of the previous two questions, there are many standards and programming models and, at times, it may get too overwhelming. This is where an SCA model comes in and mitigates these complexities. SCA is not another programming language or replacement, but rather gives a model to assemble and build SOA applications by choosing any technology specific to the implementation approach. The fundamental goal and premise of SCA is to separate business logic from infrastructure logic. IBM's BPM development tool WID provides the design time environment to build SCA-based applications using a bottom-up or top-down approach.

Therefore, WID enables architects and developers to spend more time working on solving a particular business problem rather than focusing on the details of which implementation technology to use. BPEL is one of those components that are available in WID to build applications.

Defining SCA

SCA is a set of specifications that describes a model for building applications and systems using an SOA approach. SCA extends and complements prior approaches to implementing services and SCA builds on open standards, such as web services.

SCA divides the steps in building a service-oriented application into two major parts:

§  The implementation of components (including BPEL) that 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 services, providing uniform access to business data to complement the uniform and consistent access to business services offered by SCA itself. SCA supports bindings to a wide range of access mechanisms used to invoke services.

SCA emphasizes the decoupling of service implementation and of service assembly from the infrastructure capabilities, from technology or programming language specifics, and from the details of the access methods used to invoke services. SCA components operate at a business level and use a minimum of middleware-specific APIs. The basic elements of SCA include:

v  Service components

v  Service assembly

v  Service data objects

The basic building block in SCA is the service component and represents a business service that publishes or operates on business data. The SCA Component Fundamental Structure figure depicts the essential pieces of a service component definition. A service component can have one or more interfaces with which it is associated. The interfaces associated with a service component advertise the business operations associated with this service. These interfaces can be specified as either Java interfaces or WSDL port type interfaces.

The arguments and return types for these interfaces are specified as simple Java types, Java classes, SDOs, or XML Schema (for WSDL port type interfaces). Also, implementation is associated with a service component definition. As the figure indicates, there are multiple language and component types available for implementing a service component.

When specifying a component interface, you cannot mix Java and WSDL port type interfaces on the same service component definition.

A service assembly deals with the aggregation of components and the linking of components through wiring or wires. Think of the assembly model as how, when building a kitchen, you would assemble various components including kitchen cabinets, sink, appliances, counter top, and so on. The assembly model is independent of implementation language. An analogy would be, you don't care how and where the dishwasher is engineered, manufactured, and built, but rather focus on the features, functions, and durability.

As depicted in the following figure, an SCA-based application Order Handling System can be made up of one or many modules and hence one or many components. Components can be combined into composites, a logical construct. In the following figure, we can see that the Order Handling System is made up from two composites, an Order Processing Composite and a Third-Party Shipping Composite.

In WID, a composite can be compared to a Service Module, which in essence becomes the basic unit of deployment and administration in WPS or WESB (SCA runtime). A service module typically contains the following artifacts:

Ø  Module Definition

ü  An SCA-specification-defined deployment model for packaging components into a service module. In WID, the sca.module file contains the definition of the module.

ü  In the following figure, the Order Processing Composite and Third-Party Shipping Composite are the modules.

Ø  Service Components

ü  Each service component can be implemented in various ways (BPEL, Mediation Flow Component, State Machine, Java, and so on), specified by the implementation definition.

ü  Service components can invoke other service components or imports, defined in the current service module as defined by an appropriate reference.

ü  A component can have 1..N interfaces.

ü  Each service component definition can have zero or more references to other services.

ü  In the following figure, the Order Validation Component and Order Handling Component are the service components whose implementations are BPEL and state machine respectively.

ü  In WID, the service component definition is included in the <SERVICE_NAME>.component file.

Ø  Imports and Exports

ü  Allows SCA components in one module to invoke SCA components in other modules.

ü  A service module can have zero or more imports included with it.

ü  Imports have a name and a set of 1 . .N interfaces.

ü  A Binding attribute describes how the external service is bound to the current module.

ü  Once an import has been defined, other services within the module can reference the imported service as if it was a regular service component defined in the module.

ü  In the following figure, the Order Handling Component imports a component from the Third-Party Shipping Composite via a reference.

ü  In WID, import definition is included in an <IMPORT_NAME>.import file.

ü  Imports can use the following bindings, which can be remote or local:

·        SCA

·        Web service

·        HTTP

·        Messaging (JMS, MQ JMS, generic JMS, MQ)

·        Stateless session bean

·        EIS

ü  Allows SCA components in a module to expose their capabilities to components in other modules.

ü  In order to invoke any of the services in the order handling application by any client (SCA or non-SCA), the service must be exposed with an export.

ü  A service module can have zero or more exports included with it.

ü  Export components include a name and a target attribute.

ü  A Binding attribute describes how the service is bound externally.

ü  In the following figure, the Order Validation Component has an export named Order Validate Export.

ü  In WID, import definition is included in an <EXPORT_NAME>.export file.

ü  Exports binding can be:

·        SCA

·        Web service

·        HTTP

·        Messaging (JMS, MQ JMS, generic JMS, MQ)

·        Stateless session bean

·        EIS

Ø  References

ü  Inline

ü  Stand-alone

Ø  Interfaces, Business Objects, Java classes, and other components

In order to invoke any of the services in the Order Handling System by any client (SCA or non-SCA), the service must be exposed with an export. A service module can have zero or more imports included with it. An import is used to access services that are outside the current SCA module. Once an import has been defined, other within the module can reference the imported service as if it was a regular service component defined in the module.

As depicted in the following figure, the service module Order Processing Composite can have zero or more exports included with it. An export is used to expose a particular service to clients, outside the current SCA module. A service may also include a stand-alone references file that includes references to services in the module that can be used by SCA and non-SCA services.

An SCA service module is packaged and deployed to the native SCA container strategy provided by WPS. This capability allows a developer not to use any to generate runtime-specific artifacts prior to installing a module. Unlike the previous releases of WPS and WESB, with version 7.0 the native container provides greater performance improvements due to the elimination of ejbDeploy for standard SCA applications.

Service data objects

SCA gives us a universal model to define business services. The SDO provides the technology to represent a universal model for data that flows between components in an SCA. Each SCA component pass and exchange data with each other in a neutral fashion by passing SDOs. Data objects are the preferred form for data and metadata in SCA. The fundamental concept in the SDO architecture is the data object, a data structure that holds primitive typed data and/or other data objects. The data object also holds references to metadata that provide information about the data included in the data object.

SDOs allow the integration developer to focus on working with business artifacts. In fact, service data objects are transparent to the integration developer. They are defined by a service data object's Java Specification Request (JSR).

In the SDO programming model, data objects are represented by the commonj.sdo.DataObject Java interface definition. This interface includes method definitions that enable clients to get and set the properties associated with the DataObject. Another important concept in the SDO architecture is the data graph, a structure that encapsulates a set of data objects. From the top-level data object contained in the graph, all child data objects are reachable by traversing the references from the root data object. Another important feature included in the data graph is a change summary, which is used to log information about what data objects and properties in the graph have changed during processing. The WebSphere Process Server implements the SDO specification by way of business objects.

SCA components can exchange data by passing around business objects as shown. The following figure is a mindmap that summarizes the various concepts behind an SCA application.

Please take time to go through it and recollect some of the concepts explained in the previous sections.

Common business process implementation types

Some of the common implementation types of business process that can be implemented using WPS include:

Ø  GUI Intensive Process

ü  Navigational flow and data aggregation is controlled from a user interface layer rather than in a BPEL process in WPS.

ü  WPS is not involved in process navigation, but may be used to provide swiftly responding synchronous services.

ü  Use for cases where a GUI application performs the process orchestration or control.

Ø  Synchronous Transactional Process

ü  A slight extension to the GUI Intensive Process type. A collection of short-running BPEL processes provide real-time responses to graphical user interfaces or for transactional sub processes.

ü  Transactional and therefore, it must complete within the global timeout. No state is persisted by the process.

ü  Errors are typically translated for clarity and then passed back to the caller.

ü  Use for cases when you need high performance and the caller needs a response immediately.

Ø  Asynchronously Initiated Transactional Process

ü  The caller transaction is minimal and just makes a request, but does not wait for a response. The process is assured to occur at a later time in a separate transaction.

ü  The caller seeks feedback via notifications or e-mail.

ü  Error handling is more complex than a simple Synchronous Transactional Process, since the caller is no longer present to take action.

ü  Use for cases when you need high performance and the caller does not need a response immediately, but only an acknowledgement.

Ø  Briefly Persisted Process

ü  A special use of a long-running process, where the process completes relatively swiftly. The process lifespan is deliberately short (seconds, maybe minutes), such that process versioning issues can be avoided.

ü  The process must be designed to complete in a timely fashion, so no human tasks are allowed and error handling actions should be pushed out of the process. It may not receive in process events.

ü  Allows parallel processing, so it is good for aggregation. This is one of the most common motivations for this usage type.

ü  When choosing this pattern of business process place extra care and emphasis on exception handling to handle multi transaction scenarios

ü  A Synchronous Transactional Process is always preferable, if at all possible. For Briefly Persisted Processes, persistence adds a significant overhead and the error handling is much more complex.

ü  Use for cases where the process will take a long time (more than the runtime transaction timeout) and the process instance can be flushed through to enable simple maintenance.

Ø  Versioned Long-lived Process

ü  A true long-running process that will last a relatively long time (days, weeks, and so on). Process instances will always be present in the systems, so the complex issues of process versioning will be taken into account.

ü  Can contain human tasks and complex error handling, such as compensation.

ü  May receive in-process events, which need to contain sufficient information to be correlated with the existing process instance.

ü  Invocation typically does not provide a response and late binding techniques need to be well understood.

ü  Activities can be set to wait for manual intervention on error.

ü  Use for cases where the process will take a long time (more than the runtime transaction timeout) and the process contains external system interactions.

Ø  Task-Based Process

ü  Used to balance multiple tasks between a numbers of different users, possibly in different teams/departments.

ü  Necessitates long-lived processes and hence must consider process versioning issues.

ü  Allows progressive automation of tasks.

ü  This is a very broad category still and can be broken into four sub-types:

·        Structured Workflow

·        Case Handling

·        User Modeled Flows

·        Pageflow

ü  Used for cases where the process will take a long time (more than the runtime transaction timeout) and the process contains human interactions.

Conclusion

In this article we took a look at the fundamental SOA programming model concepts and understood how these concepts apply in the context of WID/ WPS/WESB.

Download

File Name	Size	Download
The Fundamental SOA Programming Model.pdf	420KB	Download