Session Component - The Collaboration Context
The CSF Session component acts as a router or communications agent between all the Web service participants, as shown in the preceding illustration. It routes messages between all the participants based on the routing criteria specified in the manifest file or a custom route provided at run time. Each Web service sends messages to the Session (the runtime collaboration context), which then forwards the messages to the appropriate participant Web services. The presence of the Session component governs the flow of messages to and from Web services, which makes the architecture very simple and straightforward.
The next illustration shows a different scenario. Because the other core CSF components are themselves WSE 2.0 Web services, the external Web services can call them, as well as the Session component, directly.
Why Should All Web Service Calls Go Through the CSF Session Component?
The CSF Session component provides the following benefits:
- It seamlessly handles the different identities used by Web services
- It seamlessly handles different security schemes (UsernameToken, Kerberos certificates) used by Web services
- It provides interception capability so that message structures can be transformed at run time
- It provides logical routing capability, which allows the same message to one (or more than one or no) Web service conditionally
The Session component should greatly reduce the cost of adding, integrating, deploying, and upgrading the Web services used in an application.
Key Driver Concept In order to achieve service isolation, and therefore reinforce modularity of application components, all calls between applications and services should be routed through the CSF Session component. However, the other CSF components-Service Catalog, Identity Manager, and Profile Manager-can be called directly by an application if necessary.