3 Replies Latest reply on Feb 17, 2006 5:17 AM by marklittle

    Contexts

    marklittle

      The context service, an example of which was devised within OASIS WS-CAF and documented widely outside that technical committee, makes sense within an ESB/SOA framework: it is a critical component in ensuring that SOA applications can be developed that are loosely coupled, particularly where sessions are concerned.

        • 1. Re: Contexts
          marklittle

          One of the common features of all middleware systems is support for the session concept. A session is a mechanism for correlating multiple messages in order to achieve some application-visible semantic. This is typically done on behalf of a client within a service endpoint. In general, middleware systems decouple session association from specific communication channels to improve robustness. To achieve this, the session model is layered on top of a communication channel that links the client to network-visible application services. Many middleware systems advertise the session model explicitly as a mechanism for client applications to manage stateful conversations or communicate with stateful ?resources?. In other cases, the session concept is maintained less explicitly to support system services that are provided to applications.

          At present there is no standard way of obtaining sessions in Web services and this is also a significant gap in SOA. However, there are two specifications that make proposals in this area, WS-Addressing and WS-Context. Although WS-Addressing is primarily concerned with identifying/addressing Web services (and hence in many ways is complimentary to WS-Context) , it provides a session-like concept as a by-product of the model, whereas WS-Context is primarily concerned with sessions. The WS-Addressing session model is based on experiences from previous closely-coupled middleware platforms such as CORBA and J2EE and does not work well in the loosely-coupled environment of SOA. The WS-Context approach is similar in many ways to the Cookie approach in the traditional Web and as such offers an approach that integrates well with the architecture.

          It may appear as though message-oriented middleware (MOM) systems only use channels to relay messages to queues or consumers ? that any correlation semantic to backend state must be encoded in the message itself by applications. However, MOM systems offering message-grouping facilities can be applied to ordering and delivery assurance semantics. For example, in many MOM systems, a session is created to demarcate and manage the start of an ordered group. To end delivery of ordered messages within a group, the session is closed. As an example, the Web services standard WS-Reliability provides explicit protocol instructions to support this paradigm. Sessions are demarcated during application-level message exchange by implicit headers. Message acknowledgements may be communicated on independent communication channels, but messages are correlated with a group identifier that correlates messages with the session. While sessions in MOM systems are not necessarily explicitly accessed by message producers or consumers, the session concept is still very powerful and useful ? including in systems that emphasize nominally decoupled message producers and consumers.

          Supporting sessions in the SOA deployment environment is important. It has been shown that the WS-Context approach is superior to WS-Addressing's notion of session. As such, we shall be employing contexts such as those developed within WS-Context.

          • 2. Re: Contexts
            gavin.king

            Support for SOA conversations should be done as part of our efforts with Seam, and integrated with the contextual component model.

            • 3. Re: Contexts
              marklittle

              Fine. You should take a look at the WS-Context stuff then.

              Mark.