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 Implis JXTA.
At least that was our intention :)
> Iam interested in alternatingJXTA 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 tobe trying to apply a SPI impl forour network
> layer which is our company's network module in Web Application
> Server(JEUS) to Shoal without JXTA experimentally.
> Shoal has twofollowing packageswhich are dependent on JXTA as you know.
> - com.sun.enterprise.ee.cms.impl.jxta.*
> - com.sun.enterprise.jxtamgmt.*
> When I reviewedpackages and classes which were concerned with JXTA, I
> thoughtmost ofabove classes and algorithms could be reused.
> I think that ClusterManager, ClusterViewManager, MasterNode,
> HealthMonitor, ViewWindows, MessageWindows,
> DistributedStateCacheImpland other classes(etc...)whichare 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).
> SoI would like tomake the best use of above packages' classes if possible.
> For example,
> - If SystemAdvertisementis not a class but a interface andinteger 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 interfaceslike
> net.jxta.endpoint.Message, sender API and
> net.jxta.pipe.PipeMsgListener forreceiver API,
> com.sun.enterprise.jxtamgmt.* canbe 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 toinclude 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