5-minute SOA / SCA in WebSphere ESB

soaandesb websphere
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:

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

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) [...]
[...] 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: [...]