.. Service lifetime
Service MUST be instantiated only at session start by session manager and all channel messages MUST be performed against this instance.This is the differ-ence to a todays per-call mode. A session identifier is used to correlate messages to the correct weda channel. Session service instance has some advantages that old call-living instances didn’t have. For example downstream business and data tier could be cached per session (for example ORM model which is expensive to create and forget) and application client can interact with the ser-vice from multithreaded environment. Clients reference remote, state-aware objects and have some control over its lifetime.
This principal is a great opportunity for changing the web-based client user experience. It can react without reloads and additional connections and to-gether with pipelined processing it really moves the experience into next level.
This is how the desktop applications are written and it allows creation of new RAD tools to develop apps. However there are some additional disadvantages of the architecture design which should be clear when deciding of use of Weda-style for the system. Some of them are described in the chapter about the scal-ability of architecture.
.. Asynchronicity
In general, any application participating in a Web service interaction is playing a role in a distributed application. As such, it will benefit if it’s designed to run asynchronously from other components in the distributed system. The client will tend to gain performance, the server will be more easily scalable, and the overall application will obtain improved reliability. Unfortunately while ap-plication can be written asynchronously at the moment, the underlying mech-anism which could bring asynchronicity to the web services isn’t widely used now. The question is whether it’s the web service that’s asynchronous, or our access to it. Most likely the services are synchronous, but we are accessing them asynchronously in modern application (and most of clients access them synchronously). The problem exists on the WWW due to HTTP 1.1 transport and request-reply message exchange pattern which doesn’t allow us to make real asynchronicity, because callback cannot be invoked. Solutions as polling and keep-alive are weak for task. And due to that, service implementers don’t develop their web services contracts as pairs of starting (invoked) and ending (callback calling) operations.
Some specifications provide an asynchronous client API that enables devel-oper to call synchronous methods in an asynchronous way (JAX-WS [37]), but requires non-HTTP transport binding, such as JMS and proprietary calling mechanism so it cannot be used publicly. AJAX (asynchronous javascript and xml) isn’t truly asynchronous at all. AJAX XMLHttpRequest [85] just does
HTTP request in background (no UI blockage) with UI callback handling response (browser communicates synchronously).
We want to make the process truly asynchronous and multiplatformly inter-operable to achieve goals for building SaaS ESB for public cloud or dedicated WWW servers.
.. Client notifications and services
For such an asynchronous SOA (SOA 2.0) we will have to use duplex service contract to enable message exchange patterns in which both endpoints can send messages to the other independently. A duplex service, therefore, can send messages back to the client endpoint, providing event-like behavior. Du-plex communication occurs when a client connects to a service and provides the service with a channel on which the service can send messages back to the client. All bindings don’t support principle of duplex services. Weda Binding does support duplex contracts and callback. We can benefit from client’s Weda endpoint which is accessible from the server. To implement push mechanism, client MUST implement client-specific contract called callback contract, which will allow the server to invoke a reply by fire & forget operation after it finishes time-consuming calculation. This contract must couple with service’s contract and define only one-way operations for concurrency reasons. Doing it one-way enables the service to call back even when concurrency is single-threaded, be-cause there will not be any reply message to contend for the lock. IDE may has mechanism to create a callback proxy from WSDL2.0 [17] by selecting one-way output operations and programming language should allow service to invoke its methods. Simple example of coupled WSDL2.0 definition of duplex service containing service and callback contract and one-way operations follows:
Listing 3.5: Concrete WSDL 2.0 definitions of Webservice over Weda
<wsdl:binding name="WedaBinding_IWedaManagerServiceContract"
type="tns:IWedaManagerServiceContract">
<wsp:PolicyReference
URI="#WedaBinding_IWedaManagerServiceContract_policy"/>
<soap12:binding transport="http://nti.tul.cz/binding/weda" />
<wsdl:operation name="SubscribeToStatement">
<soap12:operation soapAction="SubscribeToStatement"
style="document"/>
<wsdl:input>
<soap12:body use="literal"/>
</wsdl:input>
</wsdl:operation>
<wsdl:operation name="PushingToClient">
<soap12:operation soapAction="PushingToClient" style="document"/>
<wsdl:output>
<soap12:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
Server can implement a callback contract proxy object and call client by clientCallbackProxy.PushingToClient(Message);
.. Pipelining
One of the bottlenecks of HTTP implementations is that HTTP relies on mul-tiple connections for concurrency. Pipelining in Weda architecture style can have bigger bandwidth usage compared with the traditional content delivery technique. Because WebSockets can send and receive at any time, are directly controlled by the programmer, and are not subject to proxy interference, the pipelining ability is safe and should not be disabled as with HTTP [31]. There is a practical reason why pipelining is disabled in HTTP in most browsers, but there is no reason to give yourself the same limitation when you control the pro-tocol using WebSockets (out-of-order pipelining). So Weda MAY be capable to construct a high performance Channel Pipeline which describes the steps that network traffic goes through on its way to and from the application. For example, we can define a pipeline that is built on Weda and includes a Serializ-er/Deserializer for translating objects into weda subprotocol (and back), and also the router itself for doing something with those Weda messages. When sending a Message, we can send the Message through the pipeline we’ve es-tablished (Fig.3.8).
In Weda architecture style we have offered a set of components which can be plugged into the system. There also is a component or rather set of components that are providing event-based behaviour for services (SOA 2.0).We are calling it Weda event processor or Weda event processing layer cumulatively. This component is OPTIONAL and client and server don’t need to implement it when implementing Weda API. But it MUST be implemented if ESB is the use case for the Weda API.
consumer provider consumer provider
open
close
open
close time
without pipelining with pipelining
Figure 3.8: Pipelining