THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
SCA provides a declarative way to describe how the services in an assembly interact with one another and what quality of services (security, transaction, etc) is applied to the interaction. Since service interaction and quality of service is declarative, solution developers remain focus on business logic and therefore development cycle is simplified and shortened. This also promotes the development of reusable services that can be used in different contexts. Services can interact with one another synchronously or asynchronously and can be implemented in any technology.
!!
Currently, Apache Tuscany has support for various technologies enabling asynchronous communication between components (like JMS or Comet). However, a websocket binding will complement these and further more, will avoid pitfalls specific to these technologies.
...
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 during Tuscany runtime bootstrap. The WebSocketInvoker 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 be discussed which of the two approaches is better suited in Tuscany's use case.
Websockets are designed to work 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 inside the Tuscany internals which was recently improved in the 2.0-Beta2 release.
!!
The above communication flow happens when a SCA reference is being called by the client. Websocket clients are also destined to be supported by browsers so Tuscany will support browser clients as well for the websocket binding. In this case, the server side presented above remains the same but the client side runs in a completely different environment. For browser clients, javascript proxies will be generated for all services supporting the websocket binding from an SCA domain and will be available to access via HTTP, thus simulating SCA references in javascript. These will be imported by including the js script in the HTML document which is enough for the browser to download and load it. This will be a significant decrease in the complexity the user needs to handle as all the websocket related communication and wiring is done automatically under the hood. He will just have to call something like websocketComponentContext.serviceName.operationName(params) in javascript, making the SCA integration seeming-less in the browser. Parameters will be passed in a JSON format from one peer to another so a databinding layer will be interlaced right before delegating I/O responsibility to Monsoon. JSON is a good choice for both browser clients and SCA references due to it's lightweight format and native support in browsers.
...
Working in open source projects is very appealing to me due to the interaction with the community where ideas can be exchanged in a constructive way and having the opportunity to work with a number of experienced developers. Looking forward for an exciting to a successful Summer of Code!