Correction: SCA Default Binding

Soaandesb Websphere
2006-07-24

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:

I plan to cover these more in later posts.

Comments

[...] Andrew Ferrier’s Blog » Blog Archive » Correction: SCA Default Binding (tags: wesb sibus work ibm sca) [...]
— marten.gustafson » links for 2006-07-25 2006-07-25 22:19
[...] 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. [...]
— Andrew Ferrier’s Blog » Blog Archive » 5-minute SOA / SCA in WebSphere ESB 2006-07-24 12:40