Several implementation design questions

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Several implementation design questions

Jean-Baptiste Onofré
Hi all,

I have begin to implement several SU and SA and some questions through in my mind :)
I have made some lookup on the webside and on internet but I haven't really found the complete answer.

Well, that's the questions :

1/ Existing service publication
Currently, I have several existing services implemented with EJBs. I would like to "publish" theses services using ServiceMix.
For exemple, is it a good way to implement like this :
- SU using servicemix-http component (in consumer mode) : this SU listen client requests on HTTP/SOAP
- SU using servicemix-jsr181 component : this SU is a proxy to my existing EJB
- SU using servicemix-http component (in producer mode) : this SU feedback the service result to the client
- SA which package SUs
Is this implementation correct or should I use the lightweight mode (with a servicemix.xml file) ?
In the case that my existing EJBs don't take "simple" method arguments, should I create a bean to encapsulate the EJB call (for exemple, I have EJBs
that take ValueObject (VO) in arguments and not simple scalar types) ?
If I have right understood, a SU can have only one target component, so it's not possible to define usage of servicemix-http and service-jsr181 components
in the same SU xbean.xml. Correct ?

2/ Create service beans
Currently, I have a database stored procedure which performs service. I would like to expose this stored procedure. I need to create a "frontend" bean.
Is this implementation correct :
- SU using servicemix-http component (in consumer mode) : this SU listen client requests on HTTP/SOAP
- SU using servicemix-bean component : Spring implementation bean which call others Spring Beans (like Hibernate DAO) to call my stored procedure
- SU using servicemix-jms component : this SU push the stored procedure result to a JMS queue
Is this implementation correct ?
Is it possible to use a Spring ApplicationContext XML like definition in xbean.xml file ?

3/ Agile services
Currently, I create my SAs which define SUs. For exemple, I have provided consumer SU using servicemix-http component. This is correct this time, but
for exemple, in the future, a new customer wouldn't call my service using HTTP/SOAP but using JMS. I can do it using servicemix-jms component based SU
but I need to rebuild my SA with the new SU consumer.
Is it possible to dynamically change an existing SA (by configuration, by JMX or by smx-arch) to avoid to provide a new SA ?

4/ Simplify the ServiceMix and business services delivery
To simplify ServiceMix/Business Services delivery and installation to my customers, I would like to pre-package the ESB.
I wonder two ways to do it :
- I take a default ServiceMix tar.gz and add my SAs in the hot-deploy directory
- I create a lightweight mode using servicemix.xml which define my services logic
What's the best solution ?

Thanks in advance for your feedback.

Regards
--
Jean-Baptiste Onofré (Nanthrax)
BuildProcess/AutoDeploy Project Leader
http://buildprocess.sourceforge.net
[hidden email]
PGP : 17D4F086
Reply | Threaded
Open this post in threaded view
|

Re: Several implementation design questions

gertv
L.S.,

1/ If you want to expose a service on the ESB (like servicemix-bean,
servicemix-jsr181, ...) with HTTP, you only need a http:consumer
endpoint.  This can operate in InOut mode, so it will also send the
response back to the client.  A SU always targets a single components,
so you can not have a single xbean.xml file with configuration for
multiple components.  Starting with SMX 4, you will be able to use a
single XML file or bundle for the entire config though.  BTW, you might
want to consider using servicemix-cxf-se instead of servicemix-jsr181 --
new features are all going into the CXF components.

2/ The xbean.xml file is a Spring configuration file -- you can do
anything you can do in Spring there.  The implementation looks correct
to me.  You can also do the same thing with Camel by the way -- Camel
does have JPA and hibernate components which might make the task a bit
easier.

3/ If you want to expose an existing service over a new protocol (like
using JMS instead of HTTP/SOAP), you can just configure a new endpoint
to listen on a JMS queue and send the messages to your existing service
endpoint.  This doesn't need to be configured in the same SA though --
that's entirely up to you.  If you want to keep the existing SA running
at all time, you can just create a new SA that adds the endpoint
configuration.  Changing protocols is too much of a change to do through
JMX, but you can use e.g. a PropertyPlaceholderConfigurer (remember that
the xbean.xml file is just a Spring file) and restart the SU through JMX
to reload the configuration from the properties file.  Lars just added a
blog entry about this last week
(http://lhein.blogspot.com/2008/09/servicemix-and-flexible-endpoint.html)

4/ If you package it as SAs in the hotdeploy directory, you'll end up
with a full ServiceMix installation at the client side.  This will allow
you and them to start adding other SA and just use it as a plain
ServiceMix install.  With the lightweight mode, you can deliver a
solution that only contains what they need, but it will be harder for
them (or you) to use it for anything else.  Personally, I would
recommend you to just package your SA in the SMX distro and deliver
that.  For SMX4, we will no longer support the lightweight mode (with a
static configuration file).

Regards,

Gert

Jean-Baptiste Onofré wrote:

> Hi all,
>
> I have begin to implement several SU and SA and some questions through in my mind :)
> I have made some lookup on the webside and on internet but I haven't really found the complete answer.
>
> Well, that's the questions :
>
> 1/ Existing service publication
> Currently, I have several existing services implemented with EJBs. I would like to "publish" theses services using ServiceMix.
> For exemple, is it a good way to implement like this :
> - SU using servicemix-http component (in consumer mode) : this SU listen client requests on HTTP/SOAP
> - SU using servicemix-jsr181 component : this SU is a proxy to my existing EJB
> - SU using servicemix-http component (in producer mode) : this SU feedback the service result to the client
> - SA which package SUs
> Is this implementation correct or should I use the lightweight mode (with a servicemix.xml file) ?
> In the case that my existing EJBs don't take "simple" method arguments, should I create a bean to encapsulate the EJB call (for exemple, I have EJBs
> that take ValueObject (VO) in arguments and not simple scalar types) ?
> If I have right understood, a SU can have only one target component, so it's not possible to define usage of servicemix-http and service-jsr181 components
> in the same SU xbean.xml. Correct ?
>
> 2/ Create service beans
> Currently, I have a database stored procedure which performs service. I would like to expose this stored procedure. I need to create a "frontend" bean.
> Is this implementation correct :
> - SU using servicemix-http component (in consumer mode) : this SU listen client requests on HTTP/SOAP
> - SU using servicemix-bean component : Spring implementation bean which call others Spring Beans (like Hibernate DAO) to call my stored procedure
> - SU using servicemix-jms component : this SU push the stored procedure result to a JMS queue
> Is this implementation correct ?
> Is it possible to use a Spring ApplicationContext XML like definition in xbean.xml file ?
>
> 3/ Agile services
> Currently, I create my SAs which define SUs. For exemple, I have provided consumer SU using servicemix-http component. This is correct this time, but
> for exemple, in the future, a new customer wouldn't call my service using HTTP/SOAP but using JMS. I can do it using servicemix-jms component based SU
> but I need to rebuild my SA with the new SU consumer.
> Is it possible to dynamically change an existing SA (by configuration, by JMX or by smx-arch) to avoid to provide a new SA ?
>
> 4/ Simplify the ServiceMix and business services delivery
> To simplify ServiceMix/Business Services delivery and installation to my customers, I would like to pre-package the ESB.
> I wonder two ways to do it :
> - I take a default ServiceMix tar.gz and add my SAs in the hot-deploy directory
> - I create a lightweight mode using servicemix.xml which define my services logic
> What's the best solution ?
>
> Thanks in advance for your feedback.
>
> Regards
>  

Reply | Threaded
Open this post in threaded view
|

Re: Several implementation design questions

Jean-Baptiste Onofré
Thanls for your feedback Gert.

Just a quick question, the SMX documentation is clear concerning the EJB proxy writing using JSR-181 component.
In your previous response, you have noticed that it's better to use servicemix-cxf-se component in place
of jsr-181 one.
In the servicemix-cxf-se component documentation, I can see how to define bean proxy but not really how to define
an EJB proxy :
- should I use the Spring LocalStatelessSessionProxyFactoryBean to proxy my EJBs (I know that you have give my the answer
  on IRC but I have forgotten the CXF class to use, sorry :/) ?
- how to define JNDI context lookup (provider URL, provider context factory, etc) ?

Thanks,
Regards

Le Tue, Sep 16, 2008 at 11:00:08AM +0200, Gert Vanthienen a écrit :

> L.S.,
>
> 1/ If you want to expose a service on the ESB (like servicemix-bean,  
> servicemix-jsr181, ...) with HTTP, you only need a http:consumer  
> endpoint.  This can operate in InOut mode, so it will also send the  
> response back to the client.  A SU always targets a single components,  
> so you can not have a single xbean.xml file with configuration for  
> multiple components.  Starting with SMX 4, you will be able to use a  
> single XML file or bundle for the entire config though.  BTW, you might  
> want to consider using servicemix-cxf-se instead of servicemix-jsr181 --  
> new features are all going into the CXF components.
>
> 2/ The xbean.xml file is a Spring configuration file -- you can do  
> anything you can do in Spring there.  The implementation looks correct  
> to me.  You can also do the same thing with Camel by the way -- Camel  
> does have JPA and hibernate components which might make the task a bit  
> easier.
>
> 3/ If you want to expose an existing service over a new protocol (like  
> using JMS instead of HTTP/SOAP), you can just configure a new endpoint  
> to listen on a JMS queue and send the messages to your existing service  
> endpoint.  This doesn't need to be configured in the same SA though --  
> that's entirely up to you.  If you want to keep the existing SA running  
> at all time, you can just create a new SA that adds the endpoint  
> configuration.  Changing protocols is too much of a change to do through  
> JMX, but you can use e.g. a PropertyPlaceholderConfigurer (remember that  
> the xbean.xml file is just a Spring file) and restart the SU through JMX  
> to reload the configuration from the properties file.  Lars just added a  
> blog entry about this last week  
> (http://lhein.blogspot.com/2008/09/servicemix-and-flexible-endpoint.html)
>
> 4/ If you package it as SAs in the hotdeploy directory, you'll end up  
> with a full ServiceMix installation at the client side.  This will allow  
> you and them to start adding other SA and just use it as a plain  
> ServiceMix install.  With the lightweight mode, you can deliver a  
> solution that only contains what they need, but it will be harder for  
> them (or you) to use it for anything else.  Personally, I would  
> recommend you to just package your SA in the SMX distro and deliver  
> that.  For SMX4, we will no longer support the lightweight mode (with a  
> static configuration file).
>
> Regards,
>
> Gert
>
> Jean-Baptiste Onofré wrote:
>> Hi all,
>>
>> I have begin to implement several SU and SA and some questions through in my mind :)
>> I have made some lookup on the webside and on internet but I haven't really found the complete answer.
>>
>> Well, that's the questions :
>>
>> 1/ Existing service publication
>> Currently, I have several existing services implemented with EJBs. I would like to "publish" theses services using ServiceMix.
>> For exemple, is it a good way to implement like this :
>> - SU using servicemix-http component (in consumer mode) : this SU listen client requests on HTTP/SOAP
>> - SU using servicemix-jsr181 component : this SU is a proxy to my existing EJB
>> - SU using servicemix-http component (in producer mode) : this SU feedback the service result to the client
>> - SA which package SUs
>> Is this implementation correct or should I use the lightweight mode (with a servicemix.xml file) ?
>> In the case that my existing EJBs don't take "simple" method arguments, should I create a bean to encapsulate the EJB call (for exemple, I have EJBs
>> that take ValueObject (VO) in arguments and not simple scalar types) ?
>> If I have right understood, a SU can have only one target component, so it's not possible to define usage of servicemix-http and service-jsr181 components
>> in the same SU xbean.xml. Correct ?
>>
>> 2/ Create service beans
>> Currently, I have a database stored procedure which performs service. I would like to expose this stored procedure. I need to create a "frontend" bean.
>> Is this implementation correct :
>> - SU using servicemix-http component (in consumer mode) : this SU listen client requests on HTTP/SOAP
>> - SU using servicemix-bean component : Spring implementation bean which call others Spring Beans (like Hibernate DAO) to call my stored procedure
>> - SU using servicemix-jms component : this SU push the stored procedure result to a JMS queue
>> Is this implementation correct ?
>> Is it possible to use a Spring ApplicationContext XML like definition in xbean.xml file ?
>>
>> 3/ Agile services
>> Currently, I create my SAs which define SUs. For exemple, I have provided consumer SU using servicemix-http component. This is correct this time, but
>> for exemple, in the future, a new customer wouldn't call my service using HTTP/SOAP but using JMS. I can do it using servicemix-jms component based SU
>> but I need to rebuild my SA with the new SU consumer.
>> Is it possible to dynamically change an existing SA (by configuration, by JMX or by smx-arch) to avoid to provide a new SA ?
>>
>> 4/ Simplify the ServiceMix and business services delivery
>> To simplify ServiceMix/Business Services delivery and installation to my customers, I would like to pre-package the ESB.
>> I wonder two ways to do it :
>> - I take a default ServiceMix tar.gz and add my SAs in the hot-deploy directory
>> - I create a lightweight mode using servicemix.xml which define my services logic
>> What's the best solution ?
>>
>> Thanks in advance for your feedback.
>>
>> Regards
>>  

--
Jean-Baptiste Onofré (Nanthrax)
BuildProcess/AutoDeploy Project Leader
http://buildprocess.sourceforge.net
[hidden email]
PGP : 17D4F086