5-minute SOA / SCA in WebSphere ESB

2006-06-28

SOA (Services-Oriented Architecture) is a very general idea; the notion of defining business and computing logic as interconnecting services, typically in a distributed computing environment, where some services depend on (call upon) others. SCA (Service Component Architecture) defines some terminology and standards for this, using the concept of SCA modules - you can think of each module as being a black-box service. SCA modules can import services from other SCA modules (which have corresponding exports, defining the services they provide). They can also expose (export), and call upon (import) services via other protocols.

Inside an SCA module is a similar set of constructs to that of the interconnected modules; in the ‘middle’ there are SCA components, which reference other SCA components (which have interfaces). On the ’left-hand-side’ of the module (it is indeed drawn on the left-hand-side in WebSphere Integration Developer) are the exports, and on the ‘right-hand-side’ are the imports. The exports typically connect to some components’ interfaces, and imports connect to some components’ references.

In WebSphere Process Server and ESB, imports and exports are one of four types:

SCA ‘default’ binding (it is perhaps helpful to think of this as the SCA ’native’ binding). This binding is used to link two SCA modules together. It supports all valid SCA behaviours, and its implementation is system-dependent. SCA bindings can also only link modules within the same address space (in WebSphere Process Server and ESB this means on the same server) [correction: this is not true, please see this update], are easy to set up (just specify the other module’s name on the import), and are typically high-performing.
SOAP over HTTP binding - A web service is invoked (import) or exposed (export). These are synchronous only, by the nature of the transport.
SOAP over JMS binding - A web service is invoked over JMS (import) or exposed (export). These are asynchronous only, by the nature of the transport.
JMS binding - Data is sent to a JMS destination - i.e. a queue or topic (import) or recieved from a destination (export). These are asynchronous only, by the nature of the transport.

In WebSphere Process Server, SCA modules typically contain some of these types of components:

BPEL
State Machine
Business Rules
Human Task
Selector
Interface Maps
Java

WebSphere ESB adds an additional type of SCA component, a Mediation Flow. This can only be embedded in a special type of SCA module, called a Mediation Module (which can only contain one Mediation Flow). Mediation Modules can be run on WebSphere ESB and Process Server, but ESB is only designed for mediation, and does not support Modules containing the Process Server components above (such as BPEL).

You can find out more about SCA in Process Server by reading this excellent article on IBM Developerworks.

Comments

[...] (see this posting for more information on SCA modules and components) [...]

— Andrew Ferrier’s Blog » Blog Archive » What is WebSphere Integration Developer? 2006-07-25 16:46

[...] In a previous post describing SCA in WebSphere ESB / Process Server, I wrote that SCA modules have to be running in the same address space. I’d like to correct this: the restriction actually imposed on these bindings is that they need to be between SCA modules running in the same WebSphere cell (see this post for more information on cells, nodes, and servers). This is because the SCA resources that are automatically created when an SCA module is deployed are cell-scoped. Different types of SCA resources are created depending on whether asynchronous or synchronous behaviour is required, which is normally decided automatically, but in both cases the scope is the same. For more information, see this Developerworks article. It’s worth adding that there also two other types of bindings that I didn’t cover before: [...]

— Andrew Ferrier’s Blog » Blog Archive » Correction: SCA Default Binding 2006-07-24 12:37