Page History

...

Organization: Apache Software Foundation

Assigned Mentor: Ant Elder

Abstract

Apache Tuscany provides a comprehensive infrastructure for SOA development using a service oriented approach. Apache Tuscany implements Service Component Architecture (SCA) which defines a flexible, service-based model for construction, assembly and deployment of network of services. It reduces the effort needed to develop this type of applications by pushing out of the business logic things like protocol handling or interactions between components, which make the components reusable and help the developer to concentrate on their business logic implementation.

...

This project will require the use of a websocket protocol implementation. For this task, I am planning to use the Monsoon project which is an open source Java implementation of the websocket protocol based on the latest IETF draft (v06). It is built on Java NIO, thus giving the ability to build scalable non-blocking websocket endpoints. I am already actively involved in working on this project as I am one of the co-founders. The goal of the project is to provide a comprehensive websocket library in order to facilitate the websocket adoption for a variety of frameworks and toolkits. As new drafts will be released by the IETF, these frameworks and toolkits won't have to take care of all the internal protocol changes and just upgrade to a new version on the project. With that in mind, once a fully functional version is implemented, we're planning to propose Monsoon to the Apache Incubator where we hope it will mature and be useful to various projects in their attempt to support the websocket technology.

Tuscany has a pluggable architecture easily allowing the addition of new bindings. Usually, the bindings in Tuscany are split into 2 modules as follows:

• The first module defines the way the binding should be used in the service component definition language (scdl) when defining composites. It contains an implementation of org.apache.tuscany.sca.assembly.Binding and a factory class for it's creation.
• The second module contains the runtime code for the binding and uses an implementation of org.apache.tuscany.sca.provider.BindingProviderFactory to setup the infrastructure needed by the specific technology in order for the communication to take place properly. It uses implementations of org.apache.tuscany.sca.provider.ReferenceBindingProvider and org.apache.tuscany.sca.provider.ServiceBindingProvider to initialize the binding on the reference, respectively on the service side of the communication. An implementation of org.apache.tuscany.sca.invocation.Invoker will be used to make the actual calls between the reference and the service. This module also contains a file in the META-INF/services folder containing the factory class names mentioned above, loading the module when the Tuscany runtime is started.

The following diagram summarizes the relation between the runtime binding classes:

!!

Monsoon comes into play in the WebSocketServiceBindingProvider where it will start a websocket server, ready to accept connections for each operation defined in the service interface. The WebSocketCometInvoker will use a Monsoon client to connect to the websocket server at the endpoint dedicated to the service and operation it is willing to invoke. In an initial version, each operation will have it's own websocket endpoint, thus a websocket connection to this endpoint will only transport requests and responses for this operation from one client. The connection will be closed when response is received by the client. An alternative to this approach is to use a single websocket endpoint for all the operations defined in all the services marked with the websocket binding in the composite. This will multiplex all the requests and responses from a single client to all the websocket services defined in the composite in a single persistent websocket connection. This will require internal dispatching on the server side to the corresponding operation and the development of a mini protocol that passes the service and operation names. It remains to see which of the two approaches is better suited in Tuscany's use case.

Websockets are designed to work very well on a pub/sub pattern. However, in Tuscany they will be used more on a request-response pattern benefiting from the ability to receive responses asynchronously. Aside from the communication over the wire between the Monsoon client and Monsoon server being done asynchronously due to the nature of the websocket protocol, communication between the reference and the Monsoon client as well as communication between the Monsoon server and the service implementation will be done asynchronously using the support for async invocation in the Tuscany internals which was recently improved in the 2.0-Beta2 release.

!!

Deliverables

Additional Information

...