On 30 Sep 2005, at 01:35, Chris wrote:
The issue isn't the provider side, it's the consumer side. I
thought the whole point of ESB was that I can provide a myriad of
provider BCs eventually getting to a service implementation. For
example, I could configure my JBI XyzConsumerVMBC to route to an
XyxProviderHessianBC. The point being I don't want to have to go
through another transformation; I want to be able to have my client
retrieve (or have an implementation injected) a POJO implementation
of an interface and not care where the true implementation is. I
want my client to invoke a method on a Java interface and not care
what the implementation is. If I have to use JMS, I'm locked into
JMS.
Using Spring's remoting solutions, I can, through configuration
only, have my client code to an interface, the implementation I
retrieve via the ApplicationContext, and choose a variety of (java-
oriented) protocols. If I want a concrete implementation, my
ApplicationContext refers to a local implementation. If I need a
remote implementation, I use the appropriate remoting solution. I
want the same freedom in ServiceMix. Is what I diagrammed in the
original post adequate, or is there a better way?
So you're looking at this from an application developer's perspective
right - you want a type-safe POJO to some service and to invoke it
through a POJO interface like Spring Remoting right?
Then you might invoke the service locally; or you could use spring
remoting and some transport protocol to get to the actual service.
FWIW Lingo already does Spring remoting using JMS. I've pondered
about adding JBI support in Lingo; so you could keep your Spring
remoting layer and use it to invoke operations inside of JBI and so
forth. Is that the kind of thing you mean?
Other options are to use something like JAX-WS where you take your
interfaces and POJOs and it auto-generates a WSDL (or the other way
around) then your client can use HTTP/JMS under the covers while you
stick to your POJO interface. Similarly you can deploy your
implementation inside JAX-WS (or currently, inside ServiceMix using a
JAX-WS binding) and expose the service to POJOs or JBI endpoints alike.
So going back to your original question; if you want an in-JVM
interface which takes a POJO client stub and converts it into JBI
operations; - we'd just need to wire in JBI as a transport into
either the JAX-WS RI or Celtix.
James
Philip Dodds wrote:
This looks more akin to using JAX-WS to generate a SOAP
interface, once you have a WSDL for you SOAP interface you can
use JAXB 2.0 to generate a set of POJO's so that you can call the
SOAP interface through a POJO. You might find this approach
better than developing a specific BC for it. You might want to
have a look at the stuff James has done on WS-Notification where
he is using JAX-WS and JAXB 2:
See http://www.servicemix.org/WS+Notification, and also http://
servicemix.org/maven/ws/jaxws/wspojo/apidocs/org/servicemix/wspojo/
notification/package-summary.html <http://servicemix.org/maven/ws/
jaxws/wspojo/apidocs/org/servicemix/wspojo/notification/package-
summary.html> and http://servicemix.codehaus.org/maven/ws/jaxws/
wspojo/apidocs/index.html.
Cheers
P
On 9/29/05, *Chris* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
Is it reasonable to create a BC that is basically a specific VM
interface? The way I see it, is why go through another
transformation (e.g. JMS) rather than just create a specific BC
for the interface in question.
Am I missing something? Or is this an appropriate use of
ServiceMix?
James
-------
http://radio.weblogs.com/0112098/
