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.
Facebook
Google +
Twitter
YouTube
LinkedIn