If you look at ServiceMix and Mule from a client programming perspective
you'll see that they both want you to interact with a gateway object
that doesn't implement a POJO-style facade for your interface. The
programming model looks like this:
MuleClient.send("http://myservicehost:8080/service";, "<myxml>...</myxml>");
This same approach applies when you want ServiceX to talk to ServiceY.
The ESB becomes tightly integrated into the service implementation if
you follow this approach.
That might work for some people, but I'd like to have people use the
pojo interface and have a proxy that implements the interface call to
MuleClient, etc.
So, I'd like to use xfire as a means to access and expose my services,
not to coordinate them. And I'd like my ESB to fit into the framework as
seamlessly as possible (for one thing, this allows me to start building
my services now and integrate them into an ESB "fabric" later on).
I agree, an ESB is potentially an important addition to the stack, but
it shouldn't be required by either the service implementation or the
service client. It should be transparent to both.
sw
Andres Bernasconi wrote:
mmm..What about an ESB?
On 12/6/06, [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
I am taking a look at xfire and like it quite a bit. Good work all
around.
I'm curious if anyone has implemented a remote or centralized
ServiceRegistry or done anything to expose the ServiceRegistry via
JMX.
Basically, I'm interested in setting up a ServiceRegistryService and
then using that to bootstrap the rest of the service configuration on
the client and server sides so that I can do centralized management of
my services in a production environment where it's not always
viable or
expedient to modify settings stored in a WAR file across an array of
machines.
Thanks for the feedback.
Sam Wilson
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
