Hi Shreedhar.
Wrote Shreedhar:
>However, I think it would be perfectly okay for you to open up a branch and do this experimentation and come back with results.
I am very pleased at your affirmative reply. If I am able to open up a branch and try to proceed to this experimental issue earlier before Shoal 2.0 release, I think that it would be a good chance to both me and the next Shoal version. Could you tell me how to open the branch?
Wrote Shreedhar:
>I think Jim Marino had expressed interest in abstracting out the transport layer etc. for pluggability and it may be advantageous to learn from this experience through such a collaboration.
I was glad to see Jim Marino's opinions about abstracting out the transport layer from use mailing. If I could do this experimentation in collaboration with Jim Marino, or I could call in Jim Marino's aid at least, it would also be a good opportunity to me.
Thanks.
--
Bongjae Chang
----- Original Message -----
From: Shreedhar Ganapathy
To: dev_at_shoal.dev.java.net
Cc: Mahesh Kannan
Sent: Friday, April 17, 2009 9:25 AM
Subject: Re: [Shoal-Dev] About an improvement of JXTA dependency
Hi Bongjae
Hope you are doing well. Some responses below :
Bongjae Chang wrote:
Hi.
I know that the Group Communication Provider API provides for integration of any group communication technology and current Shoal's SPI Impl is JXTA.
At least that was our intention :)
I am interested in alternating JXTA group communication module recently, so I am trying to review SPI Impl for JXTA.
That is very interesting as it would also test the adequacy of the Shoal Provider SPI.
Actually, I would like to be trying to apply a SPI impl for our network layer which is our company's network module in Web Application Server(JEUS) to Shoal without JXTA experimentally.
Shoal has two following packages which are dependent on JXTA as you know.
- com.sun.enterprise.ee.cms.impl.jxta.*
- com.sun.enterprise.jxtamgmt.*
When I reviewed packages and classes which were concerned with JXTA, I thought most of above classes and algorithms could be reused.
I think that ClusterManager, ClusterViewManager, MasterNode, HealthMonitor, ViewWindows, MessageWindows, DistributedStateCacheImpl and other classes(etc...) which are dependent on JXTA in above packages already play an important part in Shoal.
If I remember correctly, the SPI impl, DistributedStateCacheImpl, ViewWindow, MessageWindow, etc. (i.e most of the classes in com.sun.enterprise.ee.cms.impl.jxta ) should be independent of Jxta.
The com.sun.enterprise.jxtamgmt.* classes are what we call Provider library classes that should technically be compile time independent of the other classes (but is currently not so due to direct instantiation of some classes).
So I would like to make the best use of above packages' classes if possible.
For example,
- If SystemAdvertisement is not a class but a interface and integer ID replaces net.jxta.id.ID as unique ID, all com.sun.enterprise.ee.cms.impl.jxta.* classes can be reused without JXTA.
Conceivably, yes.
- If Shoal has own additional APIs and interfaces like net.jxta.endpoint.Message, sender API and net.jxta.pipe.PipeMsgListener for receiver API, com.sun.enterprise.jxtamgmt.* can be resued as well. Then, most of algorithms can be recycled such as master's discovery and selection algorithm.
That is also true to a large extent.
So, I am curious to know that you are making more plans for integration of any group communication module like abstracting and reusing above modules and eliminating JXTA's dependency.
And I would like to know an outline such as a future schedule for more abstractions of the communication layer if you are planning.
We do not have plans for this area for the medium term future until say, mid 2010 due to Sailfin v2 and GlassFish v3.1 Roadmap commitments which require us to be far more stable and reliable earlier than later. In fact, we will mostly be focused on fine tuning what is currently there for correctness, scalability, reliability and robustness.
However, I think it would be perfectly okay for you to open up a branch and do this experimentation and come back with results.
I think Jim Marino had expressed interest in abstracting out the transport layer etc. for pluggability and it may be advantageous to learn from this experience through such a collaboration.
ex) whether glassfish V3 will be able to include new Shoal version which can support any group communication module like JGroup or not.
We do have plans for a Shoal 2.0 release in the mid 2010 timeframe that is more focused on the lines of providing features like a robust highly scalable distributed cache, cluster wide singleton services etc. We are working on that roadmap which we will put out for community comments and suggestions in the coming weeks.
Cheers
Shreedhar
Thanks.
--
Bongjae Chang