Re: GSoC status
FYI connection multiplexing has been implemented. You can notice in the logs
of SalutesWebSocketBindingTest that there are two requests made for the
server at 127.0.0.1: and only one websocket handshake meaning the
connection is reused.
On Fri, Jul 8, 2011 at 4:32 PM, Florian Moga wrote:
> Hi,
>
> With one week to mid-term, here is a summary of my progress on the
> websocket binding. As you might have noticed, a functional websocket binding
> can already be found in the contrib/ area. Along with the runtime code, you
> can find two tests demonstrating the following:
> 1. services with the same uri specified for binding.websocket will be
> served by the same server so the runtime will start as many servers as many
> _distinct_ uris there are in the domain. Services are exposed as resources
> of a websocket server at the componentName/serviceName/operationName path.
> 2. data conversion is handled automatically by the binding using JSON to
> send data over the wire
>
> In the mean time, I have also looked into the Tuscany async support. Thank
> you Simon Laws for walking me through it. I've exprimented with it on the
> comet binding and came to the conclusion that it doesn't fit my needs for
> now. The main reasons were the impact it has on the service definitions and
> the fact that the AsyncResponseInvoker supports a single response being
> returned while the main benefit of both the comet and websocket bindings
> is the ability to do server push so multiple responses may be received from
> the server. I would consider moving to the async support if something
> similar to the CallbackInvoker described by Mike here [1] would be
> available.
>
> To sum up, based on the proposal it seems like I am ahead of schedule with
> 2 points from the second coding period completed.
>
> Next steps include connection multiplexing, multiple response support and
> support for browser clients.
>
> At the moment, the binding works in the traditional way, when a request
> comes in, a websocket is created, the request is sent, the response is
> received, the websocket is closed. I'd like to experiment with opening a
> persistent websocket for *all* websocket services with the same uri and make
> all the communication through that. This facilitates multiple response
> support but needs to send additional metadata back and forth (like message
> id, operation). This will be achieved using another layer of JSON
> serialization with the following format:
>
> {
> "message_id" : "12342354",
> "operation" : "component/service/operation",
> "payload" : ""
> }
>
> This nested serialization is done in order to be able to determine the
> exact Java types for parameters before doing the actual deserialization from
> JSON to Java objects.
>
> Regarding browser clients, I will look for browsers that are implementing
> the v6 websocket draft to start testing with them and start building a
> javascript toolkit similar to the comet one. If I won't be able to find any
> (although major vendors were planning to support it) I will continue to
> start building compliance tests for Monsoon and do some interoperability
> testing with Jetty (which has up-to-date websocket support).
>
> Feel free to ask questions, make suggestions or to leave comments.
>
> Thanks,
>
> Florian
>
> [1] http://markmail.org/message/ry55k6scs62u346d
>
[jira] [Updated] (TUSCANY-3522) [GSoC 2011] Develop a 'NoSQL' Datastore component for Apache Cassandra, CouchDB, Hadoop/Hbase
[ https://issues.apache.org/jira/browse/TUSCANY-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eranda Sooriyabandara updated TUSCANY-3522: --- Attachment: hbase.fix.patch couchdb.fix.patch cassandra.fix.patch Here are the latest fixes of the 3 database API implementation. I will commit to the svn soon. Please let me know your ideas. > [GSoC 2011] Develop a 'NoSQL' Datastore component for Apache Cassandra, > CouchDB, Hadoop/Hbase > - > > Key: TUSCANY-3522 > URL: https://issues.apache.org/jira/browse/TUSCANY-3522 > Project: Tuscany > Issue Type: New Feature >Reporter: Jean-Sebastien Delfino >Assignee: Eranda Sooriyabandara > Labels: gsoc, gsoc2011, mentor > Attachments: HBase-API.patch, alheaders.patch, cassandra.fix.patch, > cassandra.fix.patch, couchdb-api.path, couchdb.fix.patch, fix.patch, > hbase.fix.patch, rest-api-1.2.patch, rest-api.patch, twitapp.tar.gz > > > NoSQL Datastore component > = > Write a portable data store component over a number of 'NoSQL' databases > (Apache Cassandra, Couchdb, Hadoop/Hbase and AppEngine Datastore databases.) > This could be one component (written in Python or Java) or a set of > components (one per database) all implementing the same REST data store > interface, allowing applications to store data in different NoSQL databases > without having to worry about the details and API differences between the > databases. > The project could start with just one or two databases and add more databases > as we go. This should be a really good opportunity for students to experiment > with these new NoSQL databases. > Resources: > Tuscany > http://tuscany.apache.org/ > Cassandra > http://cassandra.apache.org/ > CouchDB > http://couchdb.apache.org/ > Hadoop/HBase > http://hadoop.apache.org/hbase/ > Appengine Datastore > http://code.google.com/appengine/docs/python/datastore/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
GSoC status
Hi,
With one week to mid-term, here is a summary of my progress on the websocket
binding. As you might have noticed, a functional websocket binding can
already be found in the contrib/ area. Along with the runtime code, you can
find two tests demonstrating the following:
1. services with the same uri specified for binding.websocket will be
served by the same server so the runtime will start as many servers as many
_distinct_ uris there are in the domain. Services are exposed as resources
of a websocket server at the componentName/serviceName/operationName path.
2. data conversion is handled automatically by the binding using JSON to
send data over the wire
In the mean time, I have also looked into the Tuscany async support. Thank
you Simon Laws for walking me through it. I've exprimented with it on the
comet binding and came to the conclusion that it doesn't fit my needs for
now. The main reasons were the impact it has on the service definitions and
the fact that the AsyncResponseInvoker supports a single response being
returned while the main benefit of both the comet and websocket bindings is
the ability to do server push so multiple responses may be received from the
server. I would consider moving to the async support if something similar to
the CallbackInvoker described by Mike here [1] would be available.
To sum up, based on the proposal it seems like I am ahead of schedule with 2
points from the second coding period completed.
Next steps include connection multiplexing, multiple response support and
support for browser clients.
At the moment, the binding works in the traditional way, when a request
comes in, a websocket is created, the request is sent, the response is
received, the websocket is closed. I'd like to experiment with opening a
persistent websocket for *all* websocket services with the same uri and make
all the communication through that. This facilitates multiple response
support but needs to send additional metadata back and forth (like message
id, operation). This will be achieved using another layer of JSON
serialization with the following format:
{
"message_id" : "12342354",
"operation" : "component/service/operation",
"payload" : ""
}
This nested serialization is done in order to be able to determine the exact
Java types for parameters before doing the actual deserialization from JSON
to Java objects.
Regarding browser clients, I will look for browsers that are implementing
the v6 websocket draft to start testing with them and start building a
javascript toolkit similar to the comet one. If I won't be able to find any
(although major vendors were planning to support it) I will continue to
start building compliance tests for Monsoon and do some interoperability
testing with Jetty (which has up-to-date websocket support).
Feel free to ask questions, make suggestions or to leave comments.
Thanks,
Florian
[1] http://markmail.org/message/ry55k6scs62u346d
Refactoring the Shell to have pluggable commands
As an FYI i've started doing some refactoring of the Shell so that each command is in a separate class which encapsulates everything related to the command and made those discoverable so additional commands can be added independently. All the existing commands now need to be refactored out into these new separate classes if anyone is interested in helping do that. ...ant
