Wait for SMX4 to use RMI?

[Erhard Siegl <Er...@at.unisys.com>]

Hi,

Now we use a home-grown service router (service bus, protocol translator) to
keep control of our services. The architecture is like this:
[Facades]-->[Adapters, Converters]-->[DAOs]

A Facade can be a EJB, a JSP or a Webservice. Adapters or Converters are
POJOs that mix or transform services (messages). DAOs (Data Access Objects)
are Objects that access other systems like a JDBC call, a RMI-call or a call
to a webservice. All components are glued together with Spring and deployed
as EAR-file on a J2EE server. (Until now all calls are synchronous.)

Now we want to replace and expand this thing with a standard-tool. As far as
I understand, in ServiceMix this would read like
[Consuming BC]-->[NMR + SEs]-->[Providing BC]

Now the question is, whether ServiceMix could do the job. 
As I understand the problem is the EJB as consuming BC. It is not easy
(possible?) to do this in ServiceMix 3. Is this right?

As I understand ServiceMix 4.0 would satisfy our requirements (true?), but
we would have to "wait for a few months" as I read in another posting. Is
there a rough estimate how many these "few" month are such that we could use
SMX4 as service router between stateless EJBs, JSPs, webservices (ie. use
RMI, HTTP, SOAP in a consuming BC)?

Greetings

Erhard
-- 
View this message in context: http://www.nabble.com/Wait-for-SMX4-to-use-RMI--tp14777867s12049p14777867.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.

Classloading issue using spring remoting. Was: Wait for SMX4 to use RMI?

[Erhard Siegl <Er...@at.unisys.com>]

bsnyder wrote:
> 
> 
> We can build a binding component for making RMI calls in ServiceMix 3
> pretty easily because Spring already provides proxy objects to handle
> this:
> 
> http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/remoting/rmi/package-summary.html
> 
> Other APIs from the Spring Framework have already been reused in
> ServiceMIx 3 for other components. Reusing more APIs and building on
> them where needed is the easiest way to achieve this and shouldn't be
> too difficult to do. And I'm happy to help so that we can continue to
> add new components to expand ServiceMix's ability to interoperate with
> more and more technologies.
> 
> Bruce
> -- 
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
> 
> 
> 

I try to write a BC using
org.springframework.remoting.rmi.RmiServiceExporter in order to use RMI to
access ServiceMix. The SU should implement the service and forwards the
message to the NMR. The ConsumerEndpoint should start the RMI-Listener using
Spring. Implementing this, I experienced some classloading-problems. After
some time of sarching and reading, the cause seems to be the following:

The Service Unit is started by the SU-classloader (xbean configuration). It
uses Spring classes (RmiServiceExporter), that are loaded by the container
class loader. The RmiServiceExporter starts a listener with the container
classloader. For this it needs aopalliance-1.0.jar, which is not in the
classpath of the container classloader and a ClassNotFoundException occurs.
This can be fixed by putting the jar to lib/optional. This starts the
RMI-listener.

But when an object comes in the listener has to unmarshal it and needs the
class. Again it uses the container classloader and a ClassNotFoundException
occurs. Putting these specific classes into lib/optional works, but it isn't
something, I'd like to do.

To fix this, the Spring-classes have to be loaded from the SU-classloader,
but I couldn't figure out how to do this. According to the postings here,
this seems to be a common problem, that occurs when someone is using Spring
in a SU or BC.

I tried to put the spring.jar into the SU. This doesn't help, since the
parent-classloader is asked first to load the class. I put <classpath
inverse="true" /> into the configuration, but ran into other problems and
the component didn't start. 

Since the goal is to prevent the parent classloader to load the
spring-classes, the <hidden> xxx </hidden> in the classpath-configuration
might help, but I still have to try that. Any other ideas?
(See also http://docs.huihoo.com/apache/servicemix/classloaders.html )

Erhard

-- 
View this message in context: http://www.nabble.com/Wait-for-SMX4-to-use-RMI--tp14777867p16788888.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.

Re: Wait for SMX4 to use RMI?

[Bruce Snyder <br...@gmail.com>]

On Jan 12, 2008 12:31 PM, Erhard Siegl <Er...@at.unisys.com> wrote:
>
> Hi,
>
> Now we use a home-grown service router (service bus, protocol translator) to
> keep control of our services. The architecture is like this:
> [Facades]-->[Adapters, Converters]-->[DAOs]
>
> A Facade can be a EJB, a JSP or a Webservice. Adapters or Converters are
> POJOs that mix or transform services (messages). DAOs (Data Access Objects)
> are Objects that access other systems like a JDBC call, a RMI-call or a call
> to a webservice. All components are glued together with Spring and deployed
> as EAR-file on a J2EE server. (Until now all calls are synchronous.)
>
> Now we want to replace and expand this thing with a standard-tool. As far as
> I understand, in ServiceMix this would read like
> [Consuming BC]-->[NMR + SEs]-->[Providing BC]
>
> Now the question is, whether ServiceMix could do the job.
> As I understand the problem is the EJB as consuming BC. It is not easy
> (possible?) to do this in ServiceMix 3. Is this right?
>
> As I understand ServiceMix 4.0 would satisfy our requirements (true?), but
> we would have to "wait for a few months" as I read in another posting. Is
> there a rough estimate how many these "few" month are such that we could use
> SMX4 as service router between stateless EJBs, JSPs, webservices (ie. use
> RMI, HTTP, SOAP in a consuming BC)?

Yes, the ServiceMix 4 work is on-going but there's no reason why you
can't use ServiceMix 3. The first thing that is being delivered for
ServiceMix 4 is JBI interoperability so that anything built to run on
ServiceMix 3 can be dropped into ServiceMix 4 and just work (as long
everything is JBI compliant).

We can build a binding component for making RMI calls in ServiceMix 3
pretty easily because Spring already provides proxy objects to handle
this:

http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/remoting/rmi/package-summary.html

Other APIs from the Spring Framework have already been reused in
ServiceMIx 3 for other components. Reusing more APIs and building on
them where needed is the easiest way to achieve this and shouldn't be
too difficult to do. And I'm happy to help so that we can continue to
add new components to expand ServiceMix's ability to interoperate with
more and more technologies.

Bruce
-- 
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

Apache ActiveMQ - http://activemq.org/
Apache Camel - http://activemq.org/camel/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/

Blog: http://bruceblog.org/