Gaggle Boss with SOAP support
Edwin Tellman
In my spare time, I've been experimenting with an alternate version
of the gaggle boss based on Mule (http://mule.mulesource.org/display/
MULE/Home). Mostly I wanted to learn a bit about Mule and Gaggle.
But if the result would be useful to anyone, I'd be happy to
contribute what I've done.
The main new feature this Boss implementation provides is SOAP
connectivity for geese. With a little more effort, it would also
support any of the other transports listed here: http://
mule.mulesource.org/display/MULE/Transports+Guide.
Any time a goose registers with the Boss, the boss creates a SOAP
proxy for it. Non-geese can call SOAP methods on the SOAP proxy and
the proxy calls the appropriate method on the goose.
Non-goose SOAP components can register with the Boss. For these
components, the boss creates a goose proxy. Geese can call methods
on the goose proxy using RMI and the proxy calls the appropriate SOAP
method.
So geese using this Boss can communicate with non-geese or components
written in Perl, Ruby, etc. without the use of JNI.
My efforts are mostly in a proof-of-concept state now. But if anyone
is interested, please let me know and I can polish them up a bit and
contribute them.
Thanks,
--Ed Tellman
etel...@pobox.com
Christopher Bare
You have a working Mule based Boss? How cool! We've given some thought to
doing exactly that so we'd love to see what you've done. It sounds like it
could be very useful.
-chris
Edwin Tellman
I do have a working Mule-based Boss, although it isn't quite
complete. Here are more details...
Unfortunately, it uses the old API, as I started this project
before the new one was released.
It doesn't have SOAP support for "tuple list" or "cluster". It
does have SOAP support for "data matrix," "network," and "name list."
I didn't implement some of the miscellaneous methods like
clearSelections() and setGeometry(). I just glanced at the new Boss
API, and it looks like many of the methods I thought weren't critical
someone else also thought weren't critical, as the new API seems
slimmer than the old one.
I've tested it with the original SampleGoose and a copy of the
SampleGoose in which I replaced the RMI connection with a SOAP one.
The geese find out about each other and send each other messages,
each unaware that the other is using a different protocol.
Since there is interest, I'd be happy to update what I've done to the
new API, polish it up a bit, and contribute the source.
--Ed
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "gaggle-development" group.
> To post to this group, send email to gaggle-
> devel...@googlegroups.com
> To unsubscribe from this group, send email to gaggle-development-
> unsub...@googlegroups.com
> For more options, visit this group at http://groups.google.com/
> group/gaggle-development?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
Dan Tenenbaum
On Nov 21, 6:07 am, Edwin Tellman <etell...@pobox.com> wrote:
> I do have a working Mule-based Boss, although it isn't quite
> complete. Here are more details...
I would love to see this, no matter what stage it is at. New API or
old is fine
If you want to polish it a little bit longer, that's fine too.
Thanks for doing this!
Dan
Edwin Tellman
Sorry, I've been a little busy lately, so I haven't made much headway.
I've been storing the source on a free Subversion server. I'm the
only user now, but I'll figure out how to allow access to other
people and post a link this weekend.
--Ed
Edwin Tellman
I've been storing the source on http://projxpert.com/. There doesn't
seem to be a way to allow anonymous access, but I created an account
with the username "gaggle" and the very deceptive password "gaggle".
You should be able to log in and look at the source on line or
download it using Subversion. The subversion link to use is
displayed after you log in. The name of the project is
"ssb" (Science Service Bus, as it uses the Mule Enterprise Service
Bus). Let me know if you have any trouble logging on.
I did get it to compile and mostly work with the new API. There
appear to be some lingering data conversion issues, but I can send
messages back and forth between new geese and mule endpoints.
There is a Maven pom.xml. But you need to add a few Sun jars and
gaggle.jar to your local Maven repository, and perhaps sacrifice a
goat ;^) to get it to work. I'll provide better instructions later.
There isn't any documentation other than the JavaDoc at the moment,
so here's a quick tour of the source.
There are two parallel registries running in Mule.
org.ssb.gaggle.boss.GooseRegistry keeps track of the geese. The
actual Boss implementation is org.ssb.gaggle.boss.ServiceBusBossImpl,
but it mostly delegates to the GooseRegistry.
The other registry is a registry of destinations that want to receive
Goose messages but aren't geese. They register by providing a map
from message type ("data matrix", "network", etc.) to Mule endpoint
URI to which to send that type of message
(org.ssb.server.registry.ConnectionInformation). This registry may
be found in org.ssb.server.registry.RegistryImpl.
Each time a component registers with one registry, a proxy is created
for it in the other registry. When a goose registers, an instance of
org.ssb.gaggle.goose.soap.SOAPGooseImpl is created and when a Mule
destination registers an instance of
org.ssb.gaggle.goose.GooseToServiceBusBridge is created.
SOAPGooseImpl forwards messages to internal "vm" endpoints which then
call methods on the remote goose.
Since not all of the Gaggle types are SOAP friendly, there are some
Data Transfer Objects, which are simple Java Beans that hold the same
data but may be easily transferred over SOAP. These are incomplete,
as I mostly just wanted to test the idea but wasn't too concerned
about getting all the data transferred. These may be found in
org.ssb.gaggle.goose.dto.
I wanted clients to be independent of the transport and service bus.
Clients rely on an org.ssb.client.endpoint.EndpointContext for their
connection with the outside world. It's sort of a combination of a
remote Boss reference and a connector in the new Gaggle API. The
EndpointContext takes care of registering clients and provides and
sends messages on the client's behalf. The endpoint context
implementation is found here: org.ssb.client.impl.ServiceBusConnector.
The terminology is unfortunately a little confusing, and I should
have thought of a different word to use other than "endpoint." In
the Mule world, "endpoint" means a single destination which may
receive messages. I also used it to refer to a client object. A
client contains several Mule endpoints (one for each type of data it
can receive).
And, finally, org.ssb.client.sample.SampleSSBGoose is a copy of
SampleGoose with minimal changes to use the Mule registry instead of
the usual gaggle communication mechanisms.
Please take a look and let me know if you have any comments or
questions.
Thanks,
--Ed
On Nov 29, 2007, at 10:07 AM, Dan Tenenbaum wrote:
>
>
Edwin Tellman
still work to be done. I also wrote up a short document which
briefly describes how it works and includes instructions for
compilation and execution along with a "to do" list. If you try to
compile it and have trouble, please let me know. I may have
inadvertently omitted some files from Subversion, etc.
I work in Seattle, so if it would be helpful for me to describe it in
person, and anyone is interested, I'd be happy to drop by some time.
Let me know if there is any interest.
Thanks,
--Ed