My 2 cents on some of the questions below.
Mohamed Abdelaziz wrote:
> Rob_Mathews_at_Dell.com wrote:
>>
>> Hi:
>>
>> I’ve read the posts and noticed a lack of Jgroups support. The
>> closest it seems to come is a mention of reimplementing the SPI
>> layer. I grabbed the latest source from CVS and there is no JGroups
>> implementation yet. The JXTA implementation of that looks complex –
>> runs to some 7000 lines, and probably represents a 6 month effort to
>> reimplement in JGroups. This looks bleak.
>>
>> Is there some other way that I’m missing?
JGroups has most of the group communication features already in place
and a SPI implementation for it should not take that long (but yes,
making it as robust as the one we have with Jxta will take a long while,
given that the current impl has been put through some very intensive
system tests for over two years). We benefitted a lot from critical
needs of enterprise deployment platforms such as GlassFish and Sailfin.
The Jxta SPI implementation incorporated group communication semantics
on top of Jxta platform. Hence it appears long and complex. Jxta by
itself provides us tremendous value in terms of location transparency
and mobility of group members. In addition it also provides Shoal a good
abstraction over transport protocols without having to specify protocol
i.e. a combination of UDP, TCP and http (although we dont yet use the
http protocol), seamlessly. It provides secure communication
capabilities which we are yet to take advantage of.
>>
>> I should mention that I’m be pushed this way by these posts, which
>> talk about be unable to do test driven development:
>>
>> The testing problem:
>> http://forums.java.net/jive/thread.jspa?messageID=330040&tstart=0
>> <http://forums.java.net/jive/thread.jspa?messageID=330040&tstart=0>
>>
>
> JXTA ships with a utility (NetworkManager) allowing developers to
> easily start and stop JXTA. This utility has evolved under Shoal to
> support multi infrastructure group participation, at some it will be
> back ported, as demand for it in the JXTA platform grows.
Yep the NetworkManager implementation in the SPI impl in Shoal does not
have the limitation discussed in the forum thread.
>
>> a very good blog entry: JXTA: Not The Solution To Java Peer Discovery
>> <http://www.prestonlee.com/2007/04/14/jxta-not-the-solution-to-java-peer-discovery/101/>
>>
>>
>
> This Blog is mainly about the misuse of the PeerDiscovery protocol to
> discover all participants in a given group, the discovery protocol is
> meant to bootstrap, not an exhaustive search, that's like saying
> enumerate all computers on the internet. Shoal uses other JXTA
> protocols to achieve it's discovery of cluster members.
>
>> At a minimum, my project has two requirements that are driving me
>> towards JGroups:
>>
>> - A design that requires for multiple members of a group within the
>> same JVM (same Tomcat instance, actually)
>>
>
> You should be able to do so today.
I am not so sure about a single JVM posing as multiple members with the
same group unless the member names are different. Also, I dont think we
have ever tested this aspect in Shoal to be honest.
But if you want the same JVM to be a member of multiple groups, that is
possible to do and has been tested.
>
>> - A testing requirement that requires multiple members of a group
>> within different processes on the same machine (ie, different Tomcat
>> instances on the same machine listening on different ports)
>>
>
> Ditto.
+1 on this. This is something that is demanded by our appservers so
support for this exists both within Jxta and Shoal.
>
>> I’m under the impression that JXTA prevents me from doing either of
>> those things.
>>
>> Is that right?
Hope we answered your questions :) Let us know if you have any feedback
for us to improve further.
Thanks
Shreedhar
>>
>> Thanks,
>>
>> Rob.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_shoal.dev.java.net
> For additional commands, e-mail: users-help_at_shoal.dev.java.net
>