SCA describes all integration artifacts as service components with well defined interfaces. SCA also introduces the concept of a module, which groups together service components and provides further specification and encapsulation of services. Integration developers can use the Assembly Editor in WebSphere Integration Developer to group service components into modules, and to specify which service interfaces you want exposed by the module to outside consumers.
You can use Services that include imported components, such as Java Beans or Web Services, along with service components that WebSphere Process Server provides. You can then connect the modules together to form complete integration solutions. SCA concepts let you encapsulate integration logic within modules. This means that you can make a change to a service component within a module without affecting any of the other modules in the overall solution as long as the interface of the module you changed stays the same. This concept applies throughout WebSphere Process Server. All integration artifacts in WebSphere Process Server -- processes, business rules, human tasks, and so forth -- are represented as SCA service components.
This creates a very flexible environment that you can use, for example, to replace an approval module that contains a human task with a module containing a business rule. As long as the interface to the module is identical, you can deploy the updated module, and it will be picked up automatically by all consuming modules without changes.
You can use SCA to invoke service components through both synchronous and asynchronous programming styles. This set of options lets you assemble the modules into overall solutions so that asynchronous channels between service components and modules can increase the overall throughput and flexibility of the system.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.