You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Charles Souillard <ch...@ext.bull.net> on 2005/12/22 14:40:23 UTC
Service Engine development
Hi all,
I was able to create and launch some examples using servicemix components.
Now, I want to create a new Service Engine and deploy it in servicemix.
Does anybody knows where I can find a tutorial or some help ?
I have already read the JBI spec. In addition I have downloaded the sun
tutorial but it is an old one (written before the final release of JBI
1.0) and it needs some com.sun... classes.
Thank you very much for your help !
Regards,
Charles
Re: Service Engine development
Posted by Charles Souillard <Ch...@ext.bull.net>.
Guillaume,
I have another problem concerning doing the bridge between NMS and my
specific Message.
I had a look at both servicemix-http and servicemix-jsr81 but I have a
problem understanding what is required/standard from what is specific...
I think I shoulg create a new class implement common ExchangeProcessor...
Can you give me a pattern to do that ?
Thanks a lot,
Regards
Charles
Guillaume Nodet wrote:
> The spring client toolkit has not been ported to SM 2.x / 3.x.
>
> But i do not think it would suit your needs btw.
> Its purpose is to create simple components, and i do not think a BPEL
> process engine is a simple one.
>
> If think you have two ways :
> * use servicemix-commons (which i agree is not well documented ;)
> * start from scratch with only the jbi api
>
> I suggest you start with servicemix-commons and write the the basic
> needed classes :
> bootstrap, component, deployer, service unit, endpoint
> Then you could ask more specific questions that would be easier to
> answer :)
>
> For testing you can take a look at the unit tests in one of the
> component that uses servicemix-commons.
> It's easy to set up a jbi container and activate your component
> without relying on the jbi way.
>
> Guillaume Nodet
>
> Charles Souillard wrote:
>
>> Guillaume,
>>
>> I saw on the web (http://servicemix.org/Spring+Client+Toolkit) an
>> example to create a first simple JBI component.
>> But this doc is written to run with SM 1.0.
>> Does this doc exist for SM 2.0.x... (current svn) ?
>>
>> Regards,
>> Charles
>>
>> Guillaume Nodet wrote:
>>
>>> I do not think that you will be able to reuse directly the wsdl1
>>> deployer.
>>>
>>> You will have to write a few classes :
>>> * a org.apache.servicemix.common.Deployer : it must accept service
>>> units (those with a .bpel file in it ?), and create a service unit
>>> with endpoints in it
>>> * a service unit : you will use one service unit per bpel process
>>> and it will store all information relative to the process in it
>>> * endpoints : each "incoming" partner link will be map to an
>>> endpoint and will create a jbi endpoint on which you will receive
>>> messages
>>> * a component
>>>
>>> Calling the process will be done by sending a message to an
>>> endpoint. You must also write the related ExchangeProcessor which
>>> will be responsible for givingthe message to the process.
>>>
>>> There are two different interactions types : in-out and in-only.
>>> In jbi, a request / response is performed by only one
>>> MessageExchange which contains both the request and the response.
>>> In such a case, if a jms request / response is performed, the jms
>>> binding component will create an in-out exchange that you will
>>> receive in your endpoint.
>>> You have to call your process, retrieve the response, and send it
>>> back. You do not have to directly use jms or http.
>>>
>>> When your process will invoke a partner, you will have to create a
>>> jbi exchange and send it using the DeliveryChannel.
>>> See
>>> https://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/ConsumerProcessor.java
>>> for an example.
>>>
>>> Guillaume Nodet
>>>
>>> Charles Souillard wrote:
>>>
>>>> Guillaume,
>>>>
>>>> I am trying to develop my SE based on the examples you gave me.
>>>> Can you tell me where I can find a description of what these
>>>> component are doing (their business logic) ?
>>>> This could help me understanding how I have to implement common
>>>> classes of SM for my case.
>>>>
>>>> For example, my BPEL processes are using two kinds of xml files :
>>>> 1) some WSDL files for the WS descriptions :
>>>> * at least one to expose the new BPEL process as a WebService
>>>> * optionnaly others to describe others WebServices that the BPEL
>>>> process will call (or receive a message from)
>>>> 2) one BPEL file for the process description
>>>>
>>>> Do you think my case could be closed to wsdl1 common package ?
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> There are many _functionnalities_ in a process life cycle :
>>>>
>>>> 1) *deploy the process* : it means creating a WS exposing the
>>>> process to make it available from anywhere in the world
>>>> By now, this step consist in deploying a WebService which will
>>>> call our BPEL engine. So when a WS call is received in the WS
>>>> engine, the implementation of this WS will call the BPEL engine
>>>> with input datas.
>>>>
>>>> 2) *undeploy the process* : undeploy the WS
>>>>
>>>> 3) *call the process* (some application somewhere in the world
>>>> wants to launch a new instance of the process). That is for this
>>>> functionnality (and the next one) that we are actually interested
>>>> in SM. What should be very nice is that SM receive the call and
>>>> give it through the NMR to the BPEL engine (so I think I have to
>>>> write a Service Engine to make it possible, isn't it ?). In this
>>>> case, the remote app could call the process using BC available in
>>>> SM (JMS or WS for example)
>>>>
>>>> 4) *call a remote WS from the process* : in a BPEL process, we can
>>>> call external WS. Here the needed functionnality is to give the
>>>> call (a Normalized Message I think) to SM which will send datas in
>>>> the specific protocol needed by the target partner. If a remote
>>>> partner activated a HelloWorld process by sending a JMS message, we
>>>> have to send the callback with output datas through a JMS message.
>>>>
>>>> Please let me know if these functionnalities are available ?
>>>> Can you give me some guidelines to develop my own Service Engine to
>>>> plug my BPEL engine ?
>>>>
>>>> Thanks a lot
>>>> Regards,
>>>> Charles
>>>>
>>>> Guillaume Nodet wrote:
>>>>
>>>>> To answer your question, implementing a component that accepts
>>>>> service units deployments
>>>>> involve a bit of coding :) The xbean and wsdl1 packages provides
>>>>> two examples of deployers
>>>>> that you can use if they fit your needs, but you can of course
>>>>> write your own. The first one
>>>>> uses an xbean/spring xml config file as a deployement, and the
>>>>> wsdl1 accepts a wsdl file
>>>>> as a service unit.
>>>>>
>>>>> The components you have seen defines some classes, because each
>>>>> components processes
>>>>> things in a different way. The lwcontainer is quite simple : it
>>>>> has only 4 classes which are fairly
>>>>> simple. I do not really how you could handle service unit
>>>>> deployments in a simplier way ;)
>>>>> Could you please provide more informations of the kind of
>>>>> component you want to develop ?
>>>>> I may be able to provide you with more specific informations.
>>>>>
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>>
>>>>> Charles Souillard wrote:
>>>>>
>>>>>> Guillaume,
>>>>>>
>>>>>> I am trying to follow the instructions you gave me by
>>>>>> implementing Deployer class.
>>>>>>
>>>>>> I can see in service-common that there are two directories under
>>>>>> common : xbean and wsdl1.
>>>>>> What is the goal of these classes ?
>>>>>> servicemix-jsr181 and servicemix-lwcontainer are implementing
>>>>>> AbstractXBeanDeployer.
>>>>>> Which one do I have to implement ?
>>>>>> I can see that the examples you gave me (jsr181,lwcontainer...)
>>>>>> have a lot of other classes.
>>>>>> Why ?
>>>>>> Do I have to do the same ?
>>>>>>
>>>>>> Thanks,
>>>>>> Charles
>>>>>>
>>>>>> Guillaume Nodet wrote:
>>>>>>
>>>>>>> Your component will have to support deployment of service units.
>>>>>>> A service unit is a jar that will be exploded by ServiceMix and
>>>>>>> ServiceMix will give the path to the ServiceUnitManager interface
>>>>>>> implemented by your component.
>>>>>>>
>>>>>>> Most of the documentation on the wiki is currently focused on
>>>>>>> existing lightweight components : these components
>>>>>>> are, as you have noticed, hard wired with the servicemix.xml
>>>>>>> configuration file and, can activate only one endpoint
>>>>>>> and do not accept deployment.
>>>>>>> "Heavyweight components" can accept service unit deployments and
>>>>>>> can activate endpoints at runtime.
>>>>>>>
>>>>>>> If you use the servicemix-common project, you will have to
>>>>>>> implement a org.servicemix.common.Deployer
>>>>>>> interface specifically for your packaging model. This object
>>>>>>> create a org.servicemix.common.ServiceUnit object
>>>>>>> that contains several org.servicemix.common.Endpoint that will
>>>>>>> be responsible for creating according to the bpel process.
>>>>>>> Each endpoint will then be activated by the framework when the
>>>>>>> service unit is started. You will then be able
>>>>>>> to receive exchanges on this endpoint.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Guillaume Nodet
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Charles Souillard wrote:
>>>>>>>
>>>>>>>> Guillaume,
>>>>>>>> Thanks for your help, I will have a look.
>>>>>>>>
>>>>>>>> I have other questions...
>>>>>>>> My goal is to integrate my own BPEL engine (different from PXE).
>>>>>>>> For now, I only support WS calls and through servicemix I want
>>>>>>>> to be able to send/receive messages with different protocols.
>>>>>>>>
>>>>>>>> I want to be able to deploy new processes dynamically (without
>>>>>>>> shutting down servicemix).
>>>>>>>> How my new processes will be known by servicemix ?
>>>>>>>>
>>>>>>>> All examples are based on a specific 'servicemix.xml' file
>>>>>>>> which is couple to the example.
>>>>>>>> How can I start servicemix in a 'standard' way and then be able
>>>>>>>> to receive/send new messages from/to a new process ?
>>>>>>>> Do I have to create a new 'servicemix.xml' specific file for
>>>>>>>> each new process ?
>>>>>>>>
>>>>>>>> I saw in http example that the endpoint was harcoded in the
>>>>>>>> servicemix.xml file. Is there any other way to do that ?
>>>>>>>>
>>>>>>>> I am not sure to understand what is a 'lightweight' component.
>>>>>>>> Can you explain me ?
>>>>>>>>
>>>>>>>> By now my BPEL engine sends WS calls. Is there any way to keep
>>>>>>>> it unmodified and to configure servicemix to catch these calls
>>>>>>>> and then send them through the NMR -> BC ?
>>>>>>>> If it is possible, it means it is not mandatory for me to
>>>>>>>> change my engine code and I will have the possibility to send
>>>>>>>> calls to partner understanding only JMS for example...
>>>>>>>>
>>>>>>>> I know it is a lot of work for you to answer many questions but
>>>>>>>> I am very interested in servicemix and I want to deploy my
>>>>>>>> future Bpel Service Engine on it.
>>>>>>>>
>>>>>>>> Thanks for your answers
>>>>>>>> Charles
>>>>>>>>
>>>>>>>>
>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>
>>>>>>>>> What kind of service engine do you want to implement ?
>>>>>>>>> If you want a full jbi compliant SE, you should look at svn head
>>>>>>>>> which contains a module named servicemix-common (see
>>>>>>>>> http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-common/).
>>>>>>>>>
>>>>>>>>> This one contains abstract classes to ease the development of
>>>>>>>>> SE and BC.
>>>>>>>>> There is also a maven plugin to generate the installer.
>>>>>>>>> Take a look at some of existing service engines
>>>>>>>>> (servicemix-jsr181, servicemix-lwcontainer,
>>>>>>>>> servicemix-wsn2005) or binding components (servicemix-http,
>>>>>>>>> servicemix-jms).
>>>>>>>>>
>>>>>>>>> If you want a lightweight component, you can look at base
>>>>>>>>> classes in servicemix-core, the
>>>>>>>>> org.servicemix.components.util package contains lots of
>>>>>>>>> usefull classes for lightweight components
>>>>>>>>> (one endpoint, without any deployment). See
>>>>>>>>> http://servicemix.org/POJO+support
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Guillaume Nodet
>>>>>>>>>
>>>>>>>>> Charles Souillard wrote:
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I was able to create and launch some examples using
>>>>>>>>>> servicemix components.
>>>>>>>>>>
>>>>>>>>>> Now, I want to create a new Service Engine and deploy it in
>>>>>>>>>> servicemix.
>>>>>>>>>> Does anybody knows where I can find a tutorial or some help ?
>>>>>>>>>>
>>>>>>>>>> I have already read the JBI spec. In addition I have
>>>>>>>>>> downloaded the sun tutorial but it is an old one (written
>>>>>>>>>> before the final release of JBI 1.0) and it needs some
>>>>>>>>>> com.sun... classes.
>>>>>>>>>>
>>>>>>>>>> Thank you very much for your help !
>>>>>>>>>> Regards,
>>>>>>>>>> Charles
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
Re: Service Engine development
Posted by Charles Souillard <Ch...@ext.bull.net>.
Guillaume,
I have started debelopping my SE based on SM commons package which helps
me a lot...
Thanks for this pacakge.
I need a precision on the ServiceUnitManager.
In my case, deploying a process consist in giving to my engine :
* 1 bpel file (the process)
* 1 wsdl file (the process wsdl file)
* 0 or many other wsdl files which are the interfaces of the partners I
want to call
So I started to work with the AbstractWsdl1Deployer and I modified it to
take in charge my bpel file and some external wsdl files.
My question concerns the three abstract methods in this class :
* protected abstract Endpoint createEndpoint(ExtensibilityElement
portElement, ExtensibilityElement bindingElement,JbiEndpoint jbiEndpoint);
* protected abstract boolean filterPortElement(ExtensibilityElement
element);
* protected abstract boolean filterBindingElement(ExtensibilityElement
element);
I don't know why I have to implement them and I don't know how to
implement them (as I don't know thier use/utilities).
I had a look at servicemix-http an servicemix-jms but I don't understand.
In adition these two component (http + jms) are BCs...
So perhaps the three abstract methods are only necessary for BCs ?
Thanks
Charles
Guillaume Nodet wrote:
> The spring client toolkit has not been ported to SM 2.x / 3.x.
>
> But i do not think it would suit your needs btw.
> Its purpose is to create simple components, and i do not think a BPEL
> process engine is a simple one.
>
> If think you have two ways :
> * use servicemix-commons (which i agree is not well documented ;)
> * start from scratch with only the jbi api
>
> I suggest you start with servicemix-commons and write the the basic
> needed classes :
> bootstrap, component, deployer, service unit, endpoint
> Then you could ask more specific questions that would be easier to
> answer :)
>
> For testing you can take a look at the unit tests in one of the
> component that uses servicemix-commons.
> It's easy to set up a jbi container and activate your component
> without relying on the jbi way.
>
> Guillaume Nodet
>
> Charles Souillard wrote:
>
>> Guillaume,
>>
>> I saw on the web (http://servicemix.org/Spring+Client+Toolkit) an
>> example to create a first simple JBI component.
>> But this doc is written to run with SM 1.0.
>> Does this doc exist for SM 2.0.x... (current svn) ?
>>
>> Regards,
>> Charles
>>
>> Guillaume Nodet wrote:
>>
>>> I do not think that you will be able to reuse directly the wsdl1
>>> deployer.
>>>
>>> You will have to write a few classes :
>>> * a org.apache.servicemix.common.Deployer : it must accept service
>>> units (those with a .bpel file in it ?), and create a service unit
>>> with endpoints in it
>>> * a service unit : you will use one service unit per bpel process
>>> and it will store all information relative to the process in it
>>> * endpoints : each "incoming" partner link will be map to an
>>> endpoint and will create a jbi endpoint on which you will receive
>>> messages
>>> * a component
>>>
>>> Calling the process will be done by sending a message to an
>>> endpoint. You must also write the related ExchangeProcessor which
>>> will be responsible for givingthe message to the process.
>>>
>>> There are two different interactions types : in-out and in-only.
>>> In jbi, a request / response is performed by only one
>>> MessageExchange which contains both the request and the response.
>>> In such a case, if a jms request / response is performed, the jms
>>> binding component will create an in-out exchange that you will
>>> receive in your endpoint.
>>> You have to call your process, retrieve the response, and send it
>>> back. You do not have to directly use jms or http.
>>>
>>> When your process will invoke a partner, you will have to create a
>>> jbi exchange and send it using the DeliveryChannel.
>>> See
>>> https://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/ConsumerProcessor.java
>>> for an example.
>>>
>>> Guillaume Nodet
>>>
>>> Charles Souillard wrote:
>>>
>>>> Guillaume,
>>>>
>>>> I am trying to develop my SE based on the examples you gave me.
>>>> Can you tell me where I can find a description of what these
>>>> component are doing (their business logic) ?
>>>> This could help me understanding how I have to implement common
>>>> classes of SM for my case.
>>>>
>>>> For example, my BPEL processes are using two kinds of xml files :
>>>> 1) some WSDL files for the WS descriptions :
>>>> * at least one to expose the new BPEL process as a WebService
>>>> * optionnaly others to describe others WebServices that the BPEL
>>>> process will call (or receive a message from)
>>>> 2) one BPEL file for the process description
>>>>
>>>> Do you think my case could be closed to wsdl1 common package ?
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> There are many _functionnalities_ in a process life cycle :
>>>>
>>>> 1) *deploy the process* : it means creating a WS exposing the
>>>> process to make it available from anywhere in the world
>>>> By now, this step consist in deploying a WebService which will
>>>> call our BPEL engine. So when a WS call is received in the WS
>>>> engine, the implementation of this WS will call the BPEL engine
>>>> with input datas.
>>>>
>>>> 2) *undeploy the process* : undeploy the WS
>>>>
>>>> 3) *call the process* (some application somewhere in the world
>>>> wants to launch a new instance of the process). That is for this
>>>> functionnality (and the next one) that we are actually interested
>>>> in SM. What should be very nice is that SM receive the call and
>>>> give it through the NMR to the BPEL engine (so I think I have to
>>>> write a Service Engine to make it possible, isn't it ?). In this
>>>> case, the remote app could call the process using BC available in
>>>> SM (JMS or WS for example)
>>>>
>>>> 4) *call a remote WS from the process* : in a BPEL process, we can
>>>> call external WS. Here the needed functionnality is to give the
>>>> call (a Normalized Message I think) to SM which will send datas in
>>>> the specific protocol needed by the target partner. If a remote
>>>> partner activated a HelloWorld process by sending a JMS message, we
>>>> have to send the callback with output datas through a JMS message.
>>>>
>>>> Please let me know if these functionnalities are available ?
>>>> Can you give me some guidelines to develop my own Service Engine to
>>>> plug my BPEL engine ?
>>>>
>>>> Thanks a lot
>>>> Regards,
>>>> Charles
>>>>
>>>> Guillaume Nodet wrote:
>>>>
>>>>> To answer your question, implementing a component that accepts
>>>>> service units deployments
>>>>> involve a bit of coding :) The xbean and wsdl1 packages provides
>>>>> two examples of deployers
>>>>> that you can use if they fit your needs, but you can of course
>>>>> write your own. The first one
>>>>> uses an xbean/spring xml config file as a deployement, and the
>>>>> wsdl1 accepts a wsdl file
>>>>> as a service unit.
>>>>>
>>>>> The components you have seen defines some classes, because each
>>>>> components processes
>>>>> things in a different way. The lwcontainer is quite simple : it
>>>>> has only 4 classes which are fairly
>>>>> simple. I do not really how you could handle service unit
>>>>> deployments in a simplier way ;)
>>>>> Could you please provide more informations of the kind of
>>>>> component you want to develop ?
>>>>> I may be able to provide you with more specific informations.
>>>>>
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>>
>>>>> Charles Souillard wrote:
>>>>>
>>>>>> Guillaume,
>>>>>>
>>>>>> I am trying to follow the instructions you gave me by
>>>>>> implementing Deployer class.
>>>>>>
>>>>>> I can see in service-common that there are two directories under
>>>>>> common : xbean and wsdl1.
>>>>>> What is the goal of these classes ?
>>>>>> servicemix-jsr181 and servicemix-lwcontainer are implementing
>>>>>> AbstractXBeanDeployer.
>>>>>> Which one do I have to implement ?
>>>>>> I can see that the examples you gave me (jsr181,lwcontainer...)
>>>>>> have a lot of other classes.
>>>>>> Why ?
>>>>>> Do I have to do the same ?
>>>>>>
>>>>>> Thanks,
>>>>>> Charles
>>>>>>
>>>>>> Guillaume Nodet wrote:
>>>>>>
>>>>>>> Your component will have to support deployment of service units.
>>>>>>> A service unit is a jar that will be exploded by ServiceMix and
>>>>>>> ServiceMix will give the path to the ServiceUnitManager interface
>>>>>>> implemented by your component.
>>>>>>>
>>>>>>> Most of the documentation on the wiki is currently focused on
>>>>>>> existing lightweight components : these components
>>>>>>> are, as you have noticed, hard wired with the servicemix.xml
>>>>>>> configuration file and, can activate only one endpoint
>>>>>>> and do not accept deployment.
>>>>>>> "Heavyweight components" can accept service unit deployments and
>>>>>>> can activate endpoints at runtime.
>>>>>>>
>>>>>>> If you use the servicemix-common project, you will have to
>>>>>>> implement a org.servicemix.common.Deployer
>>>>>>> interface specifically for your packaging model. This object
>>>>>>> create a org.servicemix.common.ServiceUnit object
>>>>>>> that contains several org.servicemix.common.Endpoint that will
>>>>>>> be responsible for creating according to the bpel process.
>>>>>>> Each endpoint will then be activated by the framework when the
>>>>>>> service unit is started. You will then be able
>>>>>>> to receive exchanges on this endpoint.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Guillaume Nodet
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Charles Souillard wrote:
>>>>>>>
>>>>>>>> Guillaume,
>>>>>>>> Thanks for your help, I will have a look.
>>>>>>>>
>>>>>>>> I have other questions...
>>>>>>>> My goal is to integrate my own BPEL engine (different from PXE).
>>>>>>>> For now, I only support WS calls and through servicemix I want
>>>>>>>> to be able to send/receive messages with different protocols.
>>>>>>>>
>>>>>>>> I want to be able to deploy new processes dynamically (without
>>>>>>>> shutting down servicemix).
>>>>>>>> How my new processes will be known by servicemix ?
>>>>>>>>
>>>>>>>> All examples are based on a specific 'servicemix.xml' file
>>>>>>>> which is couple to the example.
>>>>>>>> How can I start servicemix in a 'standard' way and then be able
>>>>>>>> to receive/send new messages from/to a new process ?
>>>>>>>> Do I have to create a new 'servicemix.xml' specific file for
>>>>>>>> each new process ?
>>>>>>>>
>>>>>>>> I saw in http example that the endpoint was harcoded in the
>>>>>>>> servicemix.xml file. Is there any other way to do that ?
>>>>>>>>
>>>>>>>> I am not sure to understand what is a 'lightweight' component.
>>>>>>>> Can you explain me ?
>>>>>>>>
>>>>>>>> By now my BPEL engine sends WS calls. Is there any way to keep
>>>>>>>> it unmodified and to configure servicemix to catch these calls
>>>>>>>> and then send them through the NMR -> BC ?
>>>>>>>> If it is possible, it means it is not mandatory for me to
>>>>>>>> change my engine code and I will have the possibility to send
>>>>>>>> calls to partner understanding only JMS for example...
>>>>>>>>
>>>>>>>> I know it is a lot of work for you to answer many questions but
>>>>>>>> I am very interested in servicemix and I want to deploy my
>>>>>>>> future Bpel Service Engine on it.
>>>>>>>>
>>>>>>>> Thanks for your answers
>>>>>>>> Charles
>>>>>>>>
>>>>>>>>
>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>
>>>>>>>>> What kind of service engine do you want to implement ?
>>>>>>>>> If you want a full jbi compliant SE, you should look at svn head
>>>>>>>>> which contains a module named servicemix-common (see
>>>>>>>>> http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-common/).
>>>>>>>>>
>>>>>>>>> This one contains abstract classes to ease the development of
>>>>>>>>> SE and BC.
>>>>>>>>> There is also a maven plugin to generate the installer.
>>>>>>>>> Take a look at some of existing service engines
>>>>>>>>> (servicemix-jsr181, servicemix-lwcontainer,
>>>>>>>>> servicemix-wsn2005) or binding components (servicemix-http,
>>>>>>>>> servicemix-jms).
>>>>>>>>>
>>>>>>>>> If you want a lightweight component, you can look at base
>>>>>>>>> classes in servicemix-core, the
>>>>>>>>> org.servicemix.components.util package contains lots of
>>>>>>>>> usefull classes for lightweight components
>>>>>>>>> (one endpoint, without any deployment). See
>>>>>>>>> http://servicemix.org/POJO+support
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Guillaume Nodet
>>>>>>>>>
>>>>>>>>> Charles Souillard wrote:
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I was able to create and launch some examples using
>>>>>>>>>> servicemix components.
>>>>>>>>>>
>>>>>>>>>> Now, I want to create a new Service Engine and deploy it in
>>>>>>>>>> servicemix.
>>>>>>>>>> Does anybody knows where I can find a tutorial or some help ?
>>>>>>>>>>
>>>>>>>>>> I have already read the JBI spec. In addition I have
>>>>>>>>>> downloaded the sun tutorial but it is an old one (written
>>>>>>>>>> before the final release of JBI 1.0) and it needs some
>>>>>>>>>> com.sun... classes.
>>>>>>>>>>
>>>>>>>>>> Thank you very much for your help !
>>>>>>>>>> Regards,
>>>>>>>>>> Charles
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
Re: Service Engine development
Posted by Charles Souillard <Ch...@ext.bull.net>.
Guillaume,
what about using the JAXBMarshaller available in wsn ?
Cheers
Charles
Guillaume Nodet wrote:
> I'm not sure you should use the wsdl deployer as your main deployment
> file is the bpel process.
> I think you should write your own deployer which will read the bpel
> process and create the necessary endpoints.
>
> You have to define a few classes:
> * the deployer inheriting from AbstractDeployer class
> * a service unit container inheriting the ServiceUnit class
> * an endpoint inheriting the Endpoint class
> * an ExchangeProcessor : you will certainly need two different
> processors, depending on the role of your endpoint (consumer or provider)
>
> The deployer will create a service unit read and the bpel process. It
> will create an endpoint each time a partner link will be found with
> the necessary role.
>
> Cheers,
> Guillaume Nodet
>
> Charles Souillard wrote:
>
>> Guillaume ?
>>
>> Are you working today ?
>>
>> If not, is it possible for someone else to answer my questions ?
>>
>> ************************
>> I have started debelopping my SE based on SM commons package which
>> helps me a lot...
>> Thanks for this pacakge.
>>
>> I need a precision on the ServiceUnitManager.
>> In my case, deploying a process consist in giving to my engine :
>> * 1 bpel file (the process)
>> * 1 wsdl file (the process wsdl file)
>> * 0 or many other wsdl files which are the interfaces of the partners
>> I want to call
>>
>> So I started to work with the AbstractWsdl1Deployer and I modified it
>> to take in charge my bpel file and some external wsdl files.
>>
>> My question concerns the three abstract methods in this class :
>> * protected abstract Endpoint createEndpoint(ExtensibilityElement
>> portElement, ExtensibilityElement bindingElement,JbiEndpoint
>> jbiEndpoint);
>> * protected abstract boolean filterPortElement(ExtensibilityElement
>> element);
>> * protected abstract boolean
>> filterBindingElement(ExtensibilityElement element);
>>
>> I don't know why I have to implement them and I don't know how to
>> implement them (as I don't know their use/utilities).
>> I had a look at servicemix-http an servicemix-jms but I don't
>> understand.
>> In adition these two components (http + jms) are BCs...
>> So perhaps the three abstract methods are only necessary for BCs ?
>>
>>
>> I have another problem concerning doing the bridge between NMS and my
>> specific Message.
>> I had a look at both servicemix-http and servicemix-jsr81 but I have
>> a problem understanding what is required/standard from what is
>> specific...
>> I think I should create a new class implementing common
>> ExchangeProcessor...
>> Can you give me a pattern to do that ?
>>
>> ***********************
>> Thanks a lot
>> Regards
>> Charles
>>
>>
>> Guillaume Nodet wrote:
>>
>>> The spring client toolkit has not been ported to SM 2.x / 3.x.
>>>
>>> But i do not think it would suit your needs btw.
>>> Its purpose is to create simple components, and i do not think a BPEL
>>> process engine is a simple one.
>>>
>>> If think you have two ways :
>>> * use servicemix-commons (which i agree is not well documented ;)
>>> * start from scratch with only the jbi api
>>>
>>> I suggest you start with servicemix-commons and write the the basic
>>> needed classes :
>>> bootstrap, component, deployer, service unit, endpoint
>>> Then you could ask more specific questions that would be easier to
>>> answer :)
>>>
>>> For testing you can take a look at the unit tests in one of the
>>> component that uses servicemix-commons.
>>> It's easy to set up a jbi container and activate your component
>>> without relying on the jbi way.
>>>
>>> Guillaume Nodet
>>>
>>> Charles Souillard wrote:
>>>
>>>> Guillaume,
>>>>
>>>> I saw on the web (http://servicemix.org/Spring+Client+Toolkit) an
>>>> example to create a first simple JBI component.
>>>> But this doc is written to run with SM 1.0.
>>>> Does this doc exist for SM 2.0.x... (current svn) ?
>>>>
>>>> Regards,
>>>> Charles
>>>>
>>>> Guillaume Nodet wrote:
>>>>
>>>>> I do not think that you will be able to reuse directly the wsdl1
>>>>> deployer.
>>>>>
>>>>> You will have to write a few classes :
>>>>> * a org.apache.servicemix.common.Deployer : it must accept
>>>>> service units (those with a .bpel file in it ?), and create a
>>>>> service unit with endpoints in it
>>>>> * a service unit : you will use one service unit per bpel process
>>>>> and it will store all information relative to the process in it
>>>>> * endpoints : each "incoming" partner link will be map to an
>>>>> endpoint and will create a jbi endpoint on which you will receive
>>>>> messages
>>>>> * a component
>>>>>
>>>>> Calling the process will be done by sending a message to an
>>>>> endpoint. You must also write the related ExchangeProcessor which
>>>>> will be responsible for givingthe message to the process.
>>>>>
>>>>> There are two different interactions types : in-out and in-only.
>>>>> In jbi, a request / response is performed by only one
>>>>> MessageExchange which contains both the request and the response.
>>>>> In such a case, if a jms request / response is performed, the jms
>>>>> binding component will create an in-out exchange that you will
>>>>> receive in your endpoint.
>>>>> You have to call your process, retrieve the response, and send it
>>>>> back. You do not have to directly use jms or http.
>>>>>
>>>>> When your process will invoke a partner, you will have to create a
>>>>> jbi exchange and send it using the DeliveryChannel.
>>>>> See
>>>>> https://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/ConsumerProcessor.java
>>>>> for an example.
>>>>>
>>>>> Guillaume Nodet
>>>>>
>>>>> Charles Souillard wrote:
>>>>>
>>>>>> Guillaume,
>>>>>>
>>>>>> I am trying to develop my SE based on the examples you gave me.
>>>>>> Can you tell me where I can find a description of what these
>>>>>> component are doing (their business logic) ?
>>>>>> This could help me understanding how I have to implement common
>>>>>> classes of SM for my case.
>>>>>>
>>>>>> For example, my BPEL processes are using two kinds of xml files :
>>>>>> 1) some WSDL files for the WS descriptions :
>>>>>> * at least one to expose the new BPEL process as a WebService
>>>>>> * optionnaly others to describe others WebServices that the
>>>>>> BPEL process will call (or receive a message from)
>>>>>> 2) one BPEL file for the process description
>>>>>>
>>>>>> Do you think my case could be closed to wsdl1 common package ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> There are many _functionnalities_ in a process life cycle :
>>>>>>
>>>>>> 1) *deploy the process* : it means creating a WS exposing the
>>>>>> process to make it available from anywhere in the world
>>>>>> By now, this step consist in deploying a WebService which will
>>>>>> call our BPEL engine. So when a WS call is received in the WS
>>>>>> engine, the implementation of this WS will call the BPEL engine
>>>>>> with input datas.
>>>>>>
>>>>>> 2) *undeploy the process* : undeploy the WS
>>>>>>
>>>>>> 3) *call the process* (some application somewhere in the world
>>>>>> wants to launch a new instance of the process). That is for this
>>>>>> functionnality (and the next one) that we are actually interested
>>>>>> in SM. What should be very nice is that SM receive the call and
>>>>>> give it through the NMR to the BPEL engine (so I think I have to
>>>>>> write a Service Engine to make it possible, isn't it ?). In this
>>>>>> case, the remote app could call the process using BC available in
>>>>>> SM (JMS or WS for example)
>>>>>>
>>>>>> 4) *call a remote WS from the process* : in a BPEL process, we
>>>>>> can call external WS. Here the needed functionnality is to give
>>>>>> the call (a Normalized Message I think) to SM which will send
>>>>>> datas in the specific protocol needed by the target partner. If a
>>>>>> remote partner activated a HelloWorld process by sending a JMS
>>>>>> message, we have to send the callback with output datas through a
>>>>>> JMS message.
>>>>>>
>>>>>> Please let me know if these functionnalities are available ?
>>>>>> Can you give me some guidelines to develop my own Service Engine
>>>>>> to plug my BPEL engine ?
>>>>>>
>>>>>> Thanks a lot
>>>>>> Regards,
>>>>>> Charles
>>>>>>
>>>>>> Guillaume Nodet wrote:
>>>>>>
>>>>>>> To answer your question, implementing a component that accepts
>>>>>>> service units deployments
>>>>>>> involve a bit of coding :) The xbean and wsdl1 packages
>>>>>>> provides two examples of deployers
>>>>>>> that you can use if they fit your needs, but you can of course
>>>>>>> write your own. The first one
>>>>>>> uses an xbean/spring xml config file as a deployement, and the
>>>>>>> wsdl1 accepts a wsdl file
>>>>>>> as a service unit.
>>>>>>>
>>>>>>> The components you have seen defines some classes, because each
>>>>>>> components processes
>>>>>>> things in a different way. The lwcontainer is quite simple : it
>>>>>>> has only 4 classes which are fairly
>>>>>>> simple. I do not really how you could handle service unit
>>>>>>> deployments in a simplier way ;)
>>>>>>> Could you please provide more informations of the kind of
>>>>>>> component you want to develop ?
>>>>>>> I may be able to provide you with more specific informations.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Guillaume Nodet
>>>>>>>
>>>>>>> Charles Souillard wrote:
>>>>>>>
>>>>>>>> Guillaume,
>>>>>>>>
>>>>>>>> I am trying to follow the instructions you gave me by
>>>>>>>> implementing Deployer class.
>>>>>>>>
>>>>>>>> I can see in service-common that there are two directories
>>>>>>>> under common : xbean and wsdl1.
>>>>>>>> What is the goal of these classes ?
>>>>>>>> servicemix-jsr181 and servicemix-lwcontainer are implementing
>>>>>>>> AbstractXBeanDeployer.
>>>>>>>> Which one do I have to implement ?
>>>>>>>> I can see that the examples you gave me (jsr181,lwcontainer...)
>>>>>>>> have a lot of other classes.
>>>>>>>> Why ?
>>>>>>>> Do I have to do the same ?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Charles
>>>>>>>>
>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>
>>>>>>>>> Your component will have to support deployment of service units.
>>>>>>>>> A service unit is a jar that will be exploded by ServiceMix
>>>>>>>>> and ServiceMix will give the path to the ServiceUnitManager
>>>>>>>>> interface
>>>>>>>>> implemented by your component.
>>>>>>>>>
>>>>>>>>> Most of the documentation on the wiki is currently focused on
>>>>>>>>> existing lightweight components : these components
>>>>>>>>> are, as you have noticed, hard wired with the servicemix.xml
>>>>>>>>> configuration file and, can activate only one endpoint
>>>>>>>>> and do not accept deployment.
>>>>>>>>> "Heavyweight components" can accept service unit deployments
>>>>>>>>> and can activate endpoints at runtime.
>>>>>>>>>
>>>>>>>>> If you use the servicemix-common project, you will have to
>>>>>>>>> implement a org.servicemix.common.Deployer
>>>>>>>>> interface specifically for your packaging model. This object
>>>>>>>>> create a org.servicemix.common.ServiceUnit object
>>>>>>>>> that contains several org.servicemix.common.Endpoint that will
>>>>>>>>> be responsible for creating according to the bpel process.
>>>>>>>>> Each endpoint will then be activated by the framework when the
>>>>>>>>> service unit is started. You will then be able
>>>>>>>>> to receive exchanges on this endpoint.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Guillaume Nodet
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Charles Souillard wrote:
>>>>>>>>>
>>>>>>>>>> Guillaume,
>>>>>>>>>> Thanks for your help, I will have a look.
>>>>>>>>>>
>>>>>>>>>> I have other questions...
>>>>>>>>>> My goal is to integrate my own BPEL engine (different from PXE).
>>>>>>>>>> For now, I only support WS calls and through servicemix I
>>>>>>>>>> want to be able to send/receive messages with different
>>>>>>>>>> protocols.
>>>>>>>>>>
>>>>>>>>>> I want to be able to deploy new processes dynamically
>>>>>>>>>> (without shutting down servicemix).
>>>>>>>>>> How my new processes will be known by servicemix ?
>>>>>>>>>>
>>>>>>>>>> All examples are based on a specific 'servicemix.xml' file
>>>>>>>>>> which is couple to the example.
>>>>>>>>>> How can I start servicemix in a 'standard' way and then be
>>>>>>>>>> able to receive/send new messages from/to a new process ?
>>>>>>>>>> Do I have to create a new 'servicemix.xml' specific file for
>>>>>>>>>> each new process ?
>>>>>>>>>>
>>>>>>>>>> I saw in http example that the endpoint was harcoded in the
>>>>>>>>>> servicemix.xml file. Is there any other way to do that ?
>>>>>>>>>>
>>>>>>>>>> I am not sure to understand what is a 'lightweight'
>>>>>>>>>> component. Can you explain me ?
>>>>>>>>>>
>>>>>>>>>> By now my BPEL engine sends WS calls. Is there any way to
>>>>>>>>>> keep it unmodified and to configure servicemix to catch these
>>>>>>>>>> calls and then send them through the NMR -> BC ?
>>>>>>>>>> If it is possible, it means it is not mandatory for me to
>>>>>>>>>> change my engine code and I will have the possibility to send
>>>>>>>>>> calls to partner understanding only JMS for example...
>>>>>>>>>>
>>>>>>>>>> I know it is a lot of work for you to answer many questions
>>>>>>>>>> but I am very interested in servicemix and I want to deploy
>>>>>>>>>> my future Bpel Service Engine on it.
>>>>>>>>>>
>>>>>>>>>> Thanks for your answers
>>>>>>>>>> Charles
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>
>>>>>>>>>>> What kind of service engine do you want to implement ?
>>>>>>>>>>> If you want a full jbi compliant SE, you should look at svn
>>>>>>>>>>> head
>>>>>>>>>>> which contains a module named servicemix-common (see
>>>>>>>>>>> http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-common/).
>>>>>>>>>>>
>>>>>>>>>>> This one contains abstract classes to ease the development
>>>>>>>>>>> of SE and BC.
>>>>>>>>>>> There is also a maven plugin to generate the installer.
>>>>>>>>>>> Take a look at some of existing service engines
>>>>>>>>>>> (servicemix-jsr181, servicemix-lwcontainer,
>>>>>>>>>>> servicemix-wsn2005) or binding components (servicemix-http,
>>>>>>>>>>> servicemix-jms).
>>>>>>>>>>>
>>>>>>>>>>> If you want a lightweight component, you can look at base
>>>>>>>>>>> classes in servicemix-core, the
>>>>>>>>>>> org.servicemix.components.util package contains lots of
>>>>>>>>>>> usefull classes for lightweight components
>>>>>>>>>>> (one endpoint, without any deployment). See
>>>>>>>>>>> http://servicemix.org/POJO+support
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>
>>>>>>>>>>> Charles Souillard wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> I was able to create and launch some examples using
>>>>>>>>>>>> servicemix components.
>>>>>>>>>>>>
>>>>>>>>>>>> Now, I want to create a new Service Engine and deploy it in
>>>>>>>>>>>> servicemix.
>>>>>>>>>>>> Does anybody knows where I can find a tutorial or some help ?
>>>>>>>>>>>>
>>>>>>>>>>>> I have already read the JBI spec. In addition I have
>>>>>>>>>>>> downloaded the sun tutorial but it is an old one (written
>>>>>>>>>>>> before the final release of JBI 1.0) and it needs some
>>>>>>>>>>>> com.sun... classes.
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you very much for your help !
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Charles
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
Re: Service Engine development
Posted by Charles Souillard <Ch...@ext.bull.net>.
I well understand what I have to do for my deployer...
The ServiceUnit container must extend the common ServiceUnit ?
Do I have to add some code ? or just extend the existing ServiceUnit
with no modification ?
What is the difference with common BaseServiceUnitManager ?
For the Endpoint class, I made a copy/paste from http example. But I
removed methods concerning HTTPBinding. What about methods concerning
locationURI ? Is is http specific ? Do I have to add other methods for
my specific BPEL case ?
I am having difficulties to understand how does the ExchangeProcessor
runs...
I can see there are a ProviderProcessor and a ConsumerProcessor in
servicemix-http. Do I have to do the same ?
How the jbi container knows which one should be called ?
Can you explain me how this is done in JBI ?
What is the use of BaseServiceUnitManager ?
Thanks
Charles
Guillaume Nodet wrote:
> I'm not sure you should use the wsdl deployer as your main deployment
> file is the bpel process.
> I think you should write your own deployer which will read the bpel
> process and create the necessary endpoints.
>
> You have to define a few classes:
> * the deployer inheriting from AbstractDeployer class
> * a service unit container inheriting the ServiceUnit class
> * an endpoint inheriting the Endpoint class
> * an ExchangeProcessor : you will certainly need two different
> processors, depending on the role of your endpoint (consumer or provider)
>
> The deployer will create a service unit read and the bpel process. It
> will create an endpoint each time a partner link will be found with
> the necessary role.
>
> Cheers,
> Guillaume Nodet
>
> Charles Souillard wrote:
>
>> Guillaume ?
>>
>> Are you working today ?
>>
>> If not, is it possible for someone else to answer my questions ?
>>
>> ************************
>> I have started debelopping my SE based on SM commons package which
>> helps me a lot...
>> Thanks for this pacakge.
>>
>> I need a precision on the ServiceUnitManager.
>> In my case, deploying a process consist in giving to my engine :
>> * 1 bpel file (the process)
>> * 1 wsdl file (the process wsdl file)
>> * 0 or many other wsdl files which are the interfaces of the partners
>> I want to call
>>
>> So I started to work with the AbstractWsdl1Deployer and I modified it
>> to take in charge my bpel file and some external wsdl files.
>>
>> My question concerns the three abstract methods in this class :
>> * protected abstract Endpoint createEndpoint(ExtensibilityElement
>> portElement, ExtensibilityElement bindingElement,JbiEndpoint
>> jbiEndpoint);
>> * protected abstract boolean filterPortElement(ExtensibilityElement
>> element);
>> * protected abstract boolean
>> filterBindingElement(ExtensibilityElement element);
>>
>> I don't know why I have to implement them and I don't know how to
>> implement them (as I don't know their use/utilities).
>> I had a look at servicemix-http an servicemix-jms but I don't
>> understand.
>> In adition these two components (http + jms) are BCs...
>> So perhaps the three abstract methods are only necessary for BCs ?
>>
>>
>> I have another problem concerning doing the bridge between NMS and my
>> specific Message.
>> I had a look at both servicemix-http and servicemix-jsr81 but I have
>> a problem understanding what is required/standard from what is
>> specific...
>> I think I should create a new class implementing common
>> ExchangeProcessor...
>> Can you give me a pattern to do that ?
>>
>> ***********************
>> Thanks a lot
>> Regards
>> Charles
>>
>>
>> Guillaume Nodet wrote:
>>
>>> The spring client toolkit has not been ported to SM 2.x / 3.x.
>>>
>>> But i do not think it would suit your needs btw.
>>> Its purpose is to create simple components, and i do not think a BPEL
>>> process engine is a simple one.
>>>
>>> If think you have two ways :
>>> * use servicemix-commons (which i agree is not well documented ;)
>>> * start from scratch with only the jbi api
>>>
>>> I suggest you start with servicemix-commons and write the the basic
>>> needed classes :
>>> bootstrap, component, deployer, service unit, endpoint
>>> Then you could ask more specific questions that would be easier to
>>> answer :)
>>>
>>> For testing you can take a look at the unit tests in one of the
>>> component that uses servicemix-commons.
>>> It's easy to set up a jbi container and activate your component
>>> without relying on the jbi way.
>>>
>>> Guillaume Nodet
>>>
>>> Charles Souillard wrote:
>>>
>>>> Guillaume,
>>>>
>>>> I saw on the web (http://servicemix.org/Spring+Client+Toolkit) an
>>>> example to create a first simple JBI component.
>>>> But this doc is written to run with SM 1.0.
>>>> Does this doc exist for SM 2.0.x... (current svn) ?
>>>>
>>>> Regards,
>>>> Charles
>>>>
>>>> Guillaume Nodet wrote:
>>>>
>>>>> I do not think that you will be able to reuse directly the wsdl1
>>>>> deployer.
>>>>>
>>>>> You will have to write a few classes :
>>>>> * a org.apache.servicemix.common.Deployer : it must accept
>>>>> service units (those with a .bpel file in it ?), and create a
>>>>> service unit with endpoints in it
>>>>> * a service unit : you will use one service unit per bpel process
>>>>> and it will store all information relative to the process in it
>>>>> * endpoints : each "incoming" partner link will be map to an
>>>>> endpoint and will create a jbi endpoint on which you will receive
>>>>> messages
>>>>> * a component
>>>>>
>>>>> Calling the process will be done by sending a message to an
>>>>> endpoint. You must also write the related ExchangeProcessor which
>>>>> will be responsible for givingthe message to the process.
>>>>>
>>>>> There are two different interactions types : in-out and in-only.
>>>>> In jbi, a request / response is performed by only one
>>>>> MessageExchange which contains both the request and the response.
>>>>> In such a case, if a jms request / response is performed, the jms
>>>>> binding component will create an in-out exchange that you will
>>>>> receive in your endpoint.
>>>>> You have to call your process, retrieve the response, and send it
>>>>> back. You do not have to directly use jms or http.
>>>>>
>>>>> When your process will invoke a partner, you will have to create a
>>>>> jbi exchange and send it using the DeliveryChannel.
>>>>> See
>>>>> https://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/ConsumerProcessor.java
>>>>> for an example.
>>>>>
>>>>> Guillaume Nodet
>>>>>
>>>>> Charles Souillard wrote:
>>>>>
>>>>>> Guillaume,
>>>>>>
>>>>>> I am trying to develop my SE based on the examples you gave me.
>>>>>> Can you tell me where I can find a description of what these
>>>>>> component are doing (their business logic) ?
>>>>>> This could help me understanding how I have to implement common
>>>>>> classes of SM for my case.
>>>>>>
>>>>>> For example, my BPEL processes are using two kinds of xml files :
>>>>>> 1) some WSDL files for the WS descriptions :
>>>>>> * at least one to expose the new BPEL process as a WebService
>>>>>> * optionnaly others to describe others WebServices that the
>>>>>> BPEL process will call (or receive a message from)
>>>>>> 2) one BPEL file for the process description
>>>>>>
>>>>>> Do you think my case could be closed to wsdl1 common package ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> There are many _functionnalities_ in a process life cycle :
>>>>>>
>>>>>> 1) *deploy the process* : it means creating a WS exposing the
>>>>>> process to make it available from anywhere in the world
>>>>>> By now, this step consist in deploying a WebService which will
>>>>>> call our BPEL engine. So when a WS call is received in the WS
>>>>>> engine, the implementation of this WS will call the BPEL engine
>>>>>> with input datas.
>>>>>>
>>>>>> 2) *undeploy the process* : undeploy the WS
>>>>>>
>>>>>> 3) *call the process* (some application somewhere in the world
>>>>>> wants to launch a new instance of the process). That is for this
>>>>>> functionnality (and the next one) that we are actually interested
>>>>>> in SM. What should be very nice is that SM receive the call and
>>>>>> give it through the NMR to the BPEL engine (so I think I have to
>>>>>> write a Service Engine to make it possible, isn't it ?). In this
>>>>>> case, the remote app could call the process using BC available in
>>>>>> SM (JMS or WS for example)
>>>>>>
>>>>>> 4) *call a remote WS from the process* : in a BPEL process, we
>>>>>> can call external WS. Here the needed functionnality is to give
>>>>>> the call (a Normalized Message I think) to SM which will send
>>>>>> datas in the specific protocol needed by the target partner. If a
>>>>>> remote partner activated a HelloWorld process by sending a JMS
>>>>>> message, we have to send the callback with output datas through a
>>>>>> JMS message.
>>>>>>
>>>>>> Please let me know if these functionnalities are available ?
>>>>>> Can you give me some guidelines to develop my own Service Engine
>>>>>> to plug my BPEL engine ?
>>>>>>
>>>>>> Thanks a lot
>>>>>> Regards,
>>>>>> Charles
>>>>>>
>>>>>> Guillaume Nodet wrote:
>>>>>>
>>>>>>> To answer your question, implementing a component that accepts
>>>>>>> service units deployments
>>>>>>> involve a bit of coding :) The xbean and wsdl1 packages
>>>>>>> provides two examples of deployers
>>>>>>> that you can use if they fit your needs, but you can of course
>>>>>>> write your own. The first one
>>>>>>> uses an xbean/spring xml config file as a deployement, and the
>>>>>>> wsdl1 accepts a wsdl file
>>>>>>> as a service unit.
>>>>>>>
>>>>>>> The components you have seen defines some classes, because each
>>>>>>> components processes
>>>>>>> things in a different way. The lwcontainer is quite simple : it
>>>>>>> has only 4 classes which are fairly
>>>>>>> simple. I do not really how you could handle service unit
>>>>>>> deployments in a simplier way ;)
>>>>>>> Could you please provide more informations of the kind of
>>>>>>> component you want to develop ?
>>>>>>> I may be able to provide you with more specific informations.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Guillaume Nodet
>>>>>>>
>>>>>>> Charles Souillard wrote:
>>>>>>>
>>>>>>>> Guillaume,
>>>>>>>>
>>>>>>>> I am trying to follow the instructions you gave me by
>>>>>>>> implementing Deployer class.
>>>>>>>>
>>>>>>>> I can see in service-common that there are two directories
>>>>>>>> under common : xbean and wsdl1.
>>>>>>>> What is the goal of these classes ?
>>>>>>>> servicemix-jsr181 and servicemix-lwcontainer are implementing
>>>>>>>> AbstractXBeanDeployer.
>>>>>>>> Which one do I have to implement ?
>>>>>>>> I can see that the examples you gave me (jsr181,lwcontainer...)
>>>>>>>> have a lot of other classes.
>>>>>>>> Why ?
>>>>>>>> Do I have to do the same ?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Charles
>>>>>>>>
>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>
>>>>>>>>> Your component will have to support deployment of service units.
>>>>>>>>> A service unit is a jar that will be exploded by ServiceMix
>>>>>>>>> and ServiceMix will give the path to the ServiceUnitManager
>>>>>>>>> interface
>>>>>>>>> implemented by your component.
>>>>>>>>>
>>>>>>>>> Most of the documentation on the wiki is currently focused on
>>>>>>>>> existing lightweight components : these components
>>>>>>>>> are, as you have noticed, hard wired with the servicemix.xml
>>>>>>>>> configuration file and, can activate only one endpoint
>>>>>>>>> and do not accept deployment.
>>>>>>>>> "Heavyweight components" can accept service unit deployments
>>>>>>>>> and can activate endpoints at runtime.
>>>>>>>>>
>>>>>>>>> If you use the servicemix-common project, you will have to
>>>>>>>>> implement a org.servicemix.common.Deployer
>>>>>>>>> interface specifically for your packaging model. This object
>>>>>>>>> create a org.servicemix.common.ServiceUnit object
>>>>>>>>> that contains several org.servicemix.common.Endpoint that will
>>>>>>>>> be responsible for creating according to the bpel process.
>>>>>>>>> Each endpoint will then be activated by the framework when the
>>>>>>>>> service unit is started. You will then be able
>>>>>>>>> to receive exchanges on this endpoint.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Guillaume Nodet
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Charles Souillard wrote:
>>>>>>>>>
>>>>>>>>>> Guillaume,
>>>>>>>>>> Thanks for your help, I will have a look.
>>>>>>>>>>
>>>>>>>>>> I have other questions...
>>>>>>>>>> My goal is to integrate my own BPEL engine (different from PXE).
>>>>>>>>>> For now, I only support WS calls and through servicemix I
>>>>>>>>>> want to be able to send/receive messages with different
>>>>>>>>>> protocols.
>>>>>>>>>>
>>>>>>>>>> I want to be able to deploy new processes dynamically
>>>>>>>>>> (without shutting down servicemix).
>>>>>>>>>> How my new processes will be known by servicemix ?
>>>>>>>>>>
>>>>>>>>>> All examples are based on a specific 'servicemix.xml' file
>>>>>>>>>> which is couple to the example.
>>>>>>>>>> How can I start servicemix in a 'standard' way and then be
>>>>>>>>>> able to receive/send new messages from/to a new process ?
>>>>>>>>>> Do I have to create a new 'servicemix.xml' specific file for
>>>>>>>>>> each new process ?
>>>>>>>>>>
>>>>>>>>>> I saw in http example that the endpoint was harcoded in the
>>>>>>>>>> servicemix.xml file. Is there any other way to do that ?
>>>>>>>>>>
>>>>>>>>>> I am not sure to understand what is a 'lightweight'
>>>>>>>>>> component. Can you explain me ?
>>>>>>>>>>
>>>>>>>>>> By now my BPEL engine sends WS calls. Is there any way to
>>>>>>>>>> keep it unmodified and to configure servicemix to catch these
>>>>>>>>>> calls and then send them through the NMR -> BC ?
>>>>>>>>>> If it is possible, it means it is not mandatory for me to
>>>>>>>>>> change my engine code and I will have the possibility to send
>>>>>>>>>> calls to partner understanding only JMS for example...
>>>>>>>>>>
>>>>>>>>>> I know it is a lot of work for you to answer many questions
>>>>>>>>>> but I am very interested in servicemix and I want to deploy
>>>>>>>>>> my future Bpel Service Engine on it.
>>>>>>>>>>
>>>>>>>>>> Thanks for your answers
>>>>>>>>>> Charles
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>
>>>>>>>>>>> What kind of service engine do you want to implement ?
>>>>>>>>>>> If you want a full jbi compliant SE, you should look at svn
>>>>>>>>>>> head
>>>>>>>>>>> which contains a module named servicemix-common (see
>>>>>>>>>>> http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-common/).
>>>>>>>>>>>
>>>>>>>>>>> This one contains abstract classes to ease the development
>>>>>>>>>>> of SE and BC.
>>>>>>>>>>> There is also a maven plugin to generate the installer.
>>>>>>>>>>> Take a look at some of existing service engines
>>>>>>>>>>> (servicemix-jsr181, servicemix-lwcontainer,
>>>>>>>>>>> servicemix-wsn2005) or binding components (servicemix-http,
>>>>>>>>>>> servicemix-jms).
>>>>>>>>>>>
>>>>>>>>>>> If you want a lightweight component, you can look at base
>>>>>>>>>>> classes in servicemix-core, the
>>>>>>>>>>> org.servicemix.components.util package contains lots of
>>>>>>>>>>> usefull classes for lightweight components
>>>>>>>>>>> (one endpoint, without any deployment). See
>>>>>>>>>>> http://servicemix.org/POJO+support
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>
>>>>>>>>>>> Charles Souillard wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> I was able to create and launch some examples using
>>>>>>>>>>>> servicemix components.
>>>>>>>>>>>>
>>>>>>>>>>>> Now, I want to create a new Service Engine and deploy it in
>>>>>>>>>>>> servicemix.
>>>>>>>>>>>> Does anybody knows where I can find a tutorial or some help ?
>>>>>>>>>>>>
>>>>>>>>>>>> I have already read the JBI spec. In addition I have
>>>>>>>>>>>> downloaded the sun tutorial but it is an old one (written
>>>>>>>>>>>> before the final release of JBI 1.0) and it needs some
>>>>>>>>>>>> com.sun... classes.
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you very much for your help !
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Charles
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
Re: Service Engine development
Posted by Guillaume Nodet <gn...@gmail.com>.
In a standard jbi component, the component pulls the messages from the
DeliveryChannel.
This is done in the BaseLifeCycle.pollDeliveryChannel method.
For a given MessageExchange, the component may act as a consumer or a
provider.
If the component is the consumer, it means it has send the message to
another component, and the messages that are pulled from the
DeliveryChannel are answers, errors or acks from the destination
component. Such messages should have been sent by your component using
the BaseLifeCycle.sendConsumerExchange method, unless they are sent in a
synchronous way. This method takes an ExchangeProcessor that will be
called to process the messages.
If the component is the provider, this means that some component sent a
message to your component. In such cases, the BaseLifeCycle will look
for the endpoint you have created, and calls its ExchangeProcessor.
All exchange processors should ensure that the exchange is sent back
according to the jbi rules. It depends on the MEP of the exchange.
As processing a consumer exchange and a provider exchange usually are
very different things, you may need to use two different
implementations, but this is up to you. I do not know which BPEL engine
you are trying to integrate and how it works. You will certainly have
callbacks that will be called when a message should be send to a
partner. In these cases, you will prepare an exchange and send it with
the BaseLifeCycle.sendConsumerExchange or DeliveryChannel.sendSync.
You may begin by using sendSync as you do not have to deal with
asynchronous results.
When you receive an exchange on an activated endpoint (a provider
endpoint), you will have to call you bpel engine, and either send the
response back (if you can have it synchronously) or put the exchange
somewhere until you can have the answer.
I do not know if you need a marshaler or not, this is just a design
question and it is really up to you. But i'm quite sure you won't be
able to reuse the existing ones from the different components. As you
say, they all define different classes and the main reason for that is
that they behave in very different ways.
To come back to the different classes, your ServiceUnit implementation
should inherit the o.a.s.common.ServiceUnit class. You may not need any
additional informations, but if you need, all informations related to a
given bpel process should be put here. You will also need to define an
endpoint class, inheriting from the o.a.s.common.Endpoint class and
implements the abstrat methods: the endpoint will be mapped to a
partner, either as a consumer or a provider, so that it may contains
additional informations related to the given partner. Consumer
endpoints should be linked to your bpel engine so that it can send jbi
exchanges when a request has to be made by your bpel engine to a
partner. Provider endpoints will receive exchanges from the
DeliveryChannel and should give them to your bpel engine.
Hope this helps,
Cheers,
Guillaume Nodet
Charles Souillard wrote:
> Guillaume,
>
> I have other questions...
> servicemix-http is using a HttpMarshaler which uses
> HttpServletRequest. HttpMarshaller is used by Http ConsumerProcessor.
> Do I have to create my own BpelMarshaller ?
> What about the HttpServletRequest ?
>
> There are a lot of different classes in each SM components. I am
> trying to find what is common between all of these but it is not easy...
> I think with all SM components I can take some code in some of them to
> build my SE without creating my own which could contain some errors.
> But I have problems understanding the general mechanism of the jbi
> container : when a class is called ? why ? by which other class (jbi
> container class) ?
> In addition I don't know the exact content form of a MessageExchange
> so it is difficult to build a bridge between the xml form to my one...
>
> Thanks for your help
> Regards,
> Charles
>
> Guillaume Nodet wrote:
>
>> I'm not sure you should use the wsdl deployer as your main deployment
>> file is the bpel process.
>> I think you should write your own deployer which will read the bpel
>> process and create the necessary endpoints.
>>
>> You have to define a few classes:
>> * the deployer inheriting from AbstractDeployer class
>> * a service unit container inheriting the ServiceUnit class
>> * an endpoint inheriting the Endpoint class
>> * an ExchangeProcessor : you will certainly need two different
>> processors, depending on the role of your endpoint (consumer or
>> provider)
>>
>> The deployer will create a service unit read and the bpel process.
>> It will create an endpoint each time a partner link will be found
>> with the necessary role.
>>
>> Cheers,
>> Guillaume Nodet
>>
>> Charles Souillard wrote:
>>
>>> Guillaume ?
>>>
>>> Are you working today ?
>>>
>>> If not, is it possible for someone else to answer my questions ?
>>>
>>> ************************
>>> I have started debelopping my SE based on SM commons package which
>>> helps me a lot...
>>> Thanks for this pacakge.
>>>
>>> I need a precision on the ServiceUnitManager.
>>> In my case, deploying a process consist in giving to my engine :
>>> * 1 bpel file (the process)
>>> * 1 wsdl file (the process wsdl file)
>>> * 0 or many other wsdl files which are the interfaces of the
>>> partners I want to call
>>>
>>> So I started to work with the AbstractWsdl1Deployer and I modified
>>> it to take in charge my bpel file and some external wsdl files.
>>>
>>> My question concerns the three abstract methods in this class :
>>> * protected abstract Endpoint createEndpoint(ExtensibilityElement
>>> portElement, ExtensibilityElement bindingElement,JbiEndpoint
>>> jbiEndpoint);
>>> * protected abstract boolean filterPortElement(ExtensibilityElement
>>> element);
>>> * protected abstract boolean
>>> filterBindingElement(ExtensibilityElement element);
>>>
>>> I don't know why I have to implement them and I don't know how to
>>> implement them (as I don't know their use/utilities).
>>> I had a look at servicemix-http an servicemix-jms but I don't
>>> understand.
>>> In adition these two components (http + jms) are BCs...
>>> So perhaps the three abstract methods are only necessary for BCs ?
>>>
>>>
>>> I have another problem concerning doing the bridge between NMS and
>>> my specific Message.
>>> I had a look at both servicemix-http and servicemix-jsr81 but I have
>>> a problem understanding what is required/standard from what is
>>> specific...
>>> I think I should create a new class implementing common
>>> ExchangeProcessor...
>>> Can you give me a pattern to do that ?
>>>
>>> ***********************
>>> Thanks a lot
>>> Regards
>>> Charles
>>>
>>>
>>> Guillaume Nodet wrote:
>>>
>>>> The spring client toolkit has not been ported to SM 2.x / 3.x.
>>>>
>>>> But i do not think it would suit your needs btw.
>>>> Its purpose is to create simple components, and i do not think a BPEL
>>>> process engine is a simple one.
>>>>
>>>> If think you have two ways :
>>>> * use servicemix-commons (which i agree is not well documented ;)
>>>> * start from scratch with only the jbi api
>>>>
>>>> I suggest you start with servicemix-commons and write the the basic
>>>> needed classes :
>>>> bootstrap, component, deployer, service unit, endpoint
>>>> Then you could ask more specific questions that would be easier to
>>>> answer :)
>>>>
>>>> For testing you can take a look at the unit tests in one of the
>>>> component that uses servicemix-commons.
>>>> It's easy to set up a jbi container and activate your component
>>>> without relying on the jbi way.
>>>>
>>>> Guillaume Nodet
>>>>
>>>> Charles Souillard wrote:
>>>>
>>>>> Guillaume,
>>>>>
>>>>> I saw on the web (http://servicemix.org/Spring+Client+Toolkit) an
>>>>> example to create a first simple JBI component.
>>>>> But this doc is written to run with SM 1.0.
>>>>> Does this doc exist for SM 2.0.x... (current svn) ?
>>>>>
>>>>> Regards,
>>>>> Charles
>>>>>
>>>>> Guillaume Nodet wrote:
>>>>>
>>>>>> I do not think that you will be able to reuse directly the wsdl1
>>>>>> deployer.
>>>>>>
>>>>>> You will have to write a few classes :
>>>>>> * a org.apache.servicemix.common.Deployer : it must accept
>>>>>> service units (those with a .bpel file in it ?), and create a
>>>>>> service unit with endpoints in it
>>>>>> * a service unit : you will use one service unit per bpel
>>>>>> process and it will store all information relative to the process
>>>>>> in it
>>>>>> * endpoints : each "incoming" partner link will be map to an
>>>>>> endpoint and will create a jbi endpoint on which you will receive
>>>>>> messages
>>>>>> * a component
>>>>>>
>>>>>> Calling the process will be done by sending a message to an
>>>>>> endpoint. You must also write the related ExchangeProcessor
>>>>>> which will be responsible for givingthe message to the process.
>>>>>>
>>>>>> There are two different interactions types : in-out and in-only.
>>>>>> In jbi, a request / response is performed by only one
>>>>>> MessageExchange which contains both the request and the response.
>>>>>> In such a case, if a jms request / response is performed, the jms
>>>>>> binding component will create an in-out exchange that you will
>>>>>> receive in your endpoint.
>>>>>> You have to call your process, retrieve the response, and send it
>>>>>> back. You do not have to directly use jms or http.
>>>>>>
>>>>>> When your process will invoke a partner, you will have to create
>>>>>> a jbi exchange and send it using the DeliveryChannel.
>>>>>> See
>>>>>> https://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/ConsumerProcessor.java
>>>>>> for an example.
>>>>>>
>>>>>> Guillaume Nodet
>>>>>>
>>>>>> Charles Souillard wrote:
>>>>>>
>>>>>>> Guillaume,
>>>>>>>
>>>>>>> I am trying to develop my SE based on the examples you gave me.
>>>>>>> Can you tell me where I can find a description of what these
>>>>>>> component are doing (their business logic) ?
>>>>>>> This could help me understanding how I have to implement common
>>>>>>> classes of SM for my case.
>>>>>>>
>>>>>>> For example, my BPEL processes are using two kinds of xml files :
>>>>>>> 1) some WSDL files for the WS descriptions :
>>>>>>> * at least one to expose the new BPEL process as a WebService
>>>>>>> * optionnaly others to describe others WebServices that the
>>>>>>> BPEL process will call (or receive a message from)
>>>>>>> 2) one BPEL file for the process description
>>>>>>>
>>>>>>> Do you think my case could be closed to wsdl1 common package ?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> There are many _functionnalities_ in a process life cycle :
>>>>>>>
>>>>>>> 1) *deploy the process* : it means creating a WS exposing the
>>>>>>> process to make it available from anywhere in the world
>>>>>>> By now, this step consist in deploying a WebService which
>>>>>>> will call our BPEL engine. So when a WS call is received in
>>>>>>> the WS engine, the implementation of this WS will call the
>>>>>>> BPEL engine with input datas.
>>>>>>>
>>>>>>> 2) *undeploy the process* : undeploy the WS
>>>>>>>
>>>>>>> 3) *call the process* (some application somewhere in the world
>>>>>>> wants to launch a new instance of the process). That is for this
>>>>>>> functionnality (and the next one) that we are actually
>>>>>>> interested in SM. What should be very nice is that SM receive
>>>>>>> the call and give it through the NMR to the BPEL engine (so I
>>>>>>> think I have to write a Service Engine to make it possible,
>>>>>>> isn't it ?). In this case, the remote app could call the process
>>>>>>> using BC available in SM (JMS or WS for example)
>>>>>>>
>>>>>>> 4) *call a remote WS from the process* : in a BPEL process, we
>>>>>>> can call external WS. Here the needed functionnality is to give
>>>>>>> the call (a Normalized Message I think) to SM which will send
>>>>>>> datas in the specific protocol needed by the target partner. If
>>>>>>> a remote partner activated a HelloWorld process by sending a JMS
>>>>>>> message, we have to send the callback with output datas through
>>>>>>> a JMS message.
>>>>>>>
>>>>>>> Please let me know if these functionnalities are available ?
>>>>>>> Can you give me some guidelines to develop my own Service Engine
>>>>>>> to plug my BPEL engine ?
>>>>>>>
>>>>>>> Thanks a lot
>>>>>>> Regards,
>>>>>>> Charles
>>>>>>>
>>>>>>> Guillaume Nodet wrote:
>>>>>>>
>>>>>>>> To answer your question, implementing a component that accepts
>>>>>>>> service units deployments
>>>>>>>> involve a bit of coding :) The xbean and wsdl1 packages
>>>>>>>> provides two examples of deployers
>>>>>>>> that you can use if they fit your needs, but you can of course
>>>>>>>> write your own. The first one
>>>>>>>> uses an xbean/spring xml config file as a deployement, and the
>>>>>>>> wsdl1 accepts a wsdl file
>>>>>>>> as a service unit.
>>>>>>>>
>>>>>>>> The components you have seen defines some classes, because each
>>>>>>>> components processes
>>>>>>>> things in a different way. The lwcontainer is quite simple :
>>>>>>>> it has only 4 classes which are fairly
>>>>>>>> simple. I do not really how you could handle service unit
>>>>>>>> deployments in a simplier way ;)
>>>>>>>> Could you please provide more informations of the kind of
>>>>>>>> component you want to develop ?
>>>>>>>> I may be able to provide you with more specific informations.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Guillaume Nodet
>>>>>>>>
>>>>>>>> Charles Souillard wrote:
>>>>>>>>
>>>>>>>>> Guillaume,
>>>>>>>>>
>>>>>>>>> I am trying to follow the instructions you gave me by
>>>>>>>>> implementing Deployer class.
>>>>>>>>>
>>>>>>>>> I can see in service-common that there are two directories
>>>>>>>>> under common : xbean and wsdl1.
>>>>>>>>> What is the goal of these classes ?
>>>>>>>>> servicemix-jsr181 and servicemix-lwcontainer are implementing
>>>>>>>>> AbstractXBeanDeployer.
>>>>>>>>> Which one do I have to implement ?
>>>>>>>>> I can see that the examples you gave me
>>>>>>>>> (jsr181,lwcontainer...) have a lot of other classes.
>>>>>>>>> Why ?
>>>>>>>>> Do I have to do the same ?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Charles
>>>>>>>>>
>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>
>>>>>>>>>> Your component will have to support deployment of service units.
>>>>>>>>>> A service unit is a jar that will be exploded by ServiceMix
>>>>>>>>>> and ServiceMix will give the path to the ServiceUnitManager
>>>>>>>>>> interface
>>>>>>>>>> implemented by your component.
>>>>>>>>>>
>>>>>>>>>> Most of the documentation on the wiki is currently focused on
>>>>>>>>>> existing lightweight components : these components
>>>>>>>>>> are, as you have noticed, hard wired with the servicemix.xml
>>>>>>>>>> configuration file and, can activate only one endpoint
>>>>>>>>>> and do not accept deployment.
>>>>>>>>>> "Heavyweight components" can accept service unit deployments
>>>>>>>>>> and can activate endpoints at runtime.
>>>>>>>>>>
>>>>>>>>>> If you use the servicemix-common project, you will have to
>>>>>>>>>> implement a org.servicemix.common.Deployer
>>>>>>>>>> interface specifically for your packaging model. This object
>>>>>>>>>> create a org.servicemix.common.ServiceUnit object
>>>>>>>>>> that contains several org.servicemix.common.Endpoint that
>>>>>>>>>> will be responsible for creating according to the bpel process.
>>>>>>>>>> Each endpoint will then be activated by the framework when
>>>>>>>>>> the service unit is started. You will then be able
>>>>>>>>>> to receive exchanges on this endpoint.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Charles Souillard wrote:
>>>>>>>>>>
>>>>>>>>>>> Guillaume,
>>>>>>>>>>> Thanks for your help, I will have a look.
>>>>>>>>>>>
>>>>>>>>>>> I have other questions...
>>>>>>>>>>> My goal is to integrate my own BPEL engine (different from
>>>>>>>>>>> PXE).
>>>>>>>>>>> For now, I only support WS calls and through servicemix I
>>>>>>>>>>> want to be able to send/receive messages with different
>>>>>>>>>>> protocols.
>>>>>>>>>>>
>>>>>>>>>>> I want to be able to deploy new processes dynamically
>>>>>>>>>>> (without shutting down servicemix).
>>>>>>>>>>> How my new processes will be known by servicemix ?
>>>>>>>>>>>
>>>>>>>>>>> All examples are based on a specific 'servicemix.xml' file
>>>>>>>>>>> which is couple to the example.
>>>>>>>>>>> How can I start servicemix in a 'standard' way and then be
>>>>>>>>>>> able to receive/send new messages from/to a new process ?
>>>>>>>>>>> Do I have to create a new 'servicemix.xml' specific file for
>>>>>>>>>>> each new process ?
>>>>>>>>>>>
>>>>>>>>>>> I saw in http example that the endpoint was harcoded in the
>>>>>>>>>>> servicemix.xml file. Is there any other way to do that ?
>>>>>>>>>>>
>>>>>>>>>>> I am not sure to understand what is a 'lightweight'
>>>>>>>>>>> component. Can you explain me ?
>>>>>>>>>>>
>>>>>>>>>>> By now my BPEL engine sends WS calls. Is there any way to
>>>>>>>>>>> keep it unmodified and to configure servicemix to catch
>>>>>>>>>>> these calls and then send them through the NMR -> BC ?
>>>>>>>>>>> If it is possible, it means it is not mandatory for me to
>>>>>>>>>>> change my engine code and I will have the possibility to
>>>>>>>>>>> send calls to partner understanding only JMS for example...
>>>>>>>>>>>
>>>>>>>>>>> I know it is a lot of work for you to answer many questions
>>>>>>>>>>> but I am very interested in servicemix and I want to deploy
>>>>>>>>>>> my future Bpel Service Engine on it.
>>>>>>>>>>>
>>>>>>>>>>> Thanks for your answers
>>>>>>>>>>> Charles
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>>
>>>>>>>>>>>> What kind of service engine do you want to implement ?
>>>>>>>>>>>> If you want a full jbi compliant SE, you should look at svn
>>>>>>>>>>>> head
>>>>>>>>>>>> which contains a module named servicemix-common (see
>>>>>>>>>>>> http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-common/).
>>>>>>>>>>>>
>>>>>>>>>>>> This one contains abstract classes to ease the development
>>>>>>>>>>>> of SE and BC.
>>>>>>>>>>>> There is also a maven plugin to generate the installer.
>>>>>>>>>>>> Take a look at some of existing service engines
>>>>>>>>>>>> (servicemix-jsr181, servicemix-lwcontainer,
>>>>>>>>>>>> servicemix-wsn2005) or binding components (servicemix-http,
>>>>>>>>>>>> servicemix-jms).
>>>>>>>>>>>>
>>>>>>>>>>>> If you want a lightweight component, you can look at base
>>>>>>>>>>>> classes in servicemix-core, the
>>>>>>>>>>>> org.servicemix.components.util package contains lots of
>>>>>>>>>>>> usefull classes for lightweight components
>>>>>>>>>>>> (one endpoint, without any deployment). See
>>>>>>>>>>>> http://servicemix.org/POJO+support
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>
>>>>>>>>>>>> Charles Souillard wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I was able to create and launch some examples using
>>>>>>>>>>>>> servicemix components.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now, I want to create a new Service Engine and deploy it
>>>>>>>>>>>>> in servicemix.
>>>>>>>>>>>>> Does anybody knows where I can find a tutorial or some help ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have already read the JBI spec. In addition I have
>>>>>>>>>>>>> downloaded the sun tutorial but it is an old one (written
>>>>>>>>>>>>> before the final release of JBI 1.0) and it needs some
>>>>>>>>>>>>> com.sun... classes.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you very much for your help !
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Charles
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
Re: Service Engine development
Posted by Charles Souillard <Ch...@ext.bull.net>.
Guillaume,
I have other questions...
servicemix-http is using a HttpMarshaler which uses HttpServletRequest.
HttpMarshaller is used by Http ConsumerProcessor.
Do I have to create my own BpelMarshaller ?
What about the HttpServletRequest ?
There are a lot of different classes in each SM components. I am trying
to find what is common between all of these but it is not easy...
I think with all SM components I can take some code in some of them to
build my SE without creating my own which could contain some errors.
But I have problems understanding the general mechanism of the jbi
container : when a class is called ? why ? by which other class (jbi
container class) ?
In addition I don't know the exact content form of a MessageExchange so
it is difficult to build a bridge between the xml form to my one...
Thanks for your help
Regards,
Charles
Guillaume Nodet wrote:
> I'm not sure you should use the wsdl deployer as your main deployment
> file is the bpel process.
> I think you should write your own deployer which will read the bpel
> process and create the necessary endpoints.
>
> You have to define a few classes:
> * the deployer inheriting from AbstractDeployer class
> * a service unit container inheriting the ServiceUnit class
> * an endpoint inheriting the Endpoint class
> * an ExchangeProcessor : you will certainly need two different
> processors, depending on the role of your endpoint (consumer or provider)
>
> The deployer will create a service unit read and the bpel process. It
> will create an endpoint each time a partner link will be found with
> the necessary role.
>
> Cheers,
> Guillaume Nodet
>
> Charles Souillard wrote:
>
>> Guillaume ?
>>
>> Are you working today ?
>>
>> If not, is it possible for someone else to answer my questions ?
>>
>> ************************
>> I have started debelopping my SE based on SM commons package which
>> helps me a lot...
>> Thanks for this pacakge.
>>
>> I need a precision on the ServiceUnitManager.
>> In my case, deploying a process consist in giving to my engine :
>> * 1 bpel file (the process)
>> * 1 wsdl file (the process wsdl file)
>> * 0 or many other wsdl files which are the interfaces of the partners
>> I want to call
>>
>> So I started to work with the AbstractWsdl1Deployer and I modified it
>> to take in charge my bpel file and some external wsdl files.
>>
>> My question concerns the three abstract methods in this class :
>> * protected abstract Endpoint createEndpoint(ExtensibilityElement
>> portElement, ExtensibilityElement bindingElement,JbiEndpoint
>> jbiEndpoint);
>> * protected abstract boolean filterPortElement(ExtensibilityElement
>> element);
>> * protected abstract boolean
>> filterBindingElement(ExtensibilityElement element);
>>
>> I don't know why I have to implement them and I don't know how to
>> implement them (as I don't know their use/utilities).
>> I had a look at servicemix-http an servicemix-jms but I don't
>> understand.
>> In adition these two components (http + jms) are BCs...
>> So perhaps the three abstract methods are only necessary for BCs ?
>>
>>
>> I have another problem concerning doing the bridge between NMS and my
>> specific Message.
>> I had a look at both servicemix-http and servicemix-jsr81 but I have
>> a problem understanding what is required/standard from what is
>> specific...
>> I think I should create a new class implementing common
>> ExchangeProcessor...
>> Can you give me a pattern to do that ?
>>
>> ***********************
>> Thanks a lot
>> Regards
>> Charles
>>
>>
>> Guillaume Nodet wrote:
>>
>>> The spring client toolkit has not been ported to SM 2.x / 3.x.
>>>
>>> But i do not think it would suit your needs btw.
>>> Its purpose is to create simple components, and i do not think a BPEL
>>> process engine is a simple one.
>>>
>>> If think you have two ways :
>>> * use servicemix-commons (which i agree is not well documented ;)
>>> * start from scratch with only the jbi api
>>>
>>> I suggest you start with servicemix-commons and write the the basic
>>> needed classes :
>>> bootstrap, component, deployer, service unit, endpoint
>>> Then you could ask more specific questions that would be easier to
>>> answer :)
>>>
>>> For testing you can take a look at the unit tests in one of the
>>> component that uses servicemix-commons.
>>> It's easy to set up a jbi container and activate your component
>>> without relying on the jbi way.
>>>
>>> Guillaume Nodet
>>>
>>> Charles Souillard wrote:
>>>
>>>> Guillaume,
>>>>
>>>> I saw on the web (http://servicemix.org/Spring+Client+Toolkit) an
>>>> example to create a first simple JBI component.
>>>> But this doc is written to run with SM 1.0.
>>>> Does this doc exist for SM 2.0.x... (current svn) ?
>>>>
>>>> Regards,
>>>> Charles
>>>>
>>>> Guillaume Nodet wrote:
>>>>
>>>>> I do not think that you will be able to reuse directly the wsdl1
>>>>> deployer.
>>>>>
>>>>> You will have to write a few classes :
>>>>> * a org.apache.servicemix.common.Deployer : it must accept
>>>>> service units (those with a .bpel file in it ?), and create a
>>>>> service unit with endpoints in it
>>>>> * a service unit : you will use one service unit per bpel process
>>>>> and it will store all information relative to the process in it
>>>>> * endpoints : each "incoming" partner link will be map to an
>>>>> endpoint and will create a jbi endpoint on which you will receive
>>>>> messages
>>>>> * a component
>>>>>
>>>>> Calling the process will be done by sending a message to an
>>>>> endpoint. You must also write the related ExchangeProcessor which
>>>>> will be responsible for givingthe message to the process.
>>>>>
>>>>> There are two different interactions types : in-out and in-only.
>>>>> In jbi, a request / response is performed by only one
>>>>> MessageExchange which contains both the request and the response.
>>>>> In such a case, if a jms request / response is performed, the jms
>>>>> binding component will create an in-out exchange that you will
>>>>> receive in your endpoint.
>>>>> You have to call your process, retrieve the response, and send it
>>>>> back. You do not have to directly use jms or http.
>>>>>
>>>>> When your process will invoke a partner, you will have to create a
>>>>> jbi exchange and send it using the DeliveryChannel.
>>>>> See
>>>>> https://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/ConsumerProcessor.java
>>>>> for an example.
>>>>>
>>>>> Guillaume Nodet
>>>>>
>>>>> Charles Souillard wrote:
>>>>>
>>>>>> Guillaume,
>>>>>>
>>>>>> I am trying to develop my SE based on the examples you gave me.
>>>>>> Can you tell me where I can find a description of what these
>>>>>> component are doing (their business logic) ?
>>>>>> This could help me understanding how I have to implement common
>>>>>> classes of SM for my case.
>>>>>>
>>>>>> For example, my BPEL processes are using two kinds of xml files :
>>>>>> 1) some WSDL files for the WS descriptions :
>>>>>> * at least one to expose the new BPEL process as a WebService
>>>>>> * optionnaly others to describe others WebServices that the
>>>>>> BPEL process will call (or receive a message from)
>>>>>> 2) one BPEL file for the process description
>>>>>>
>>>>>> Do you think my case could be closed to wsdl1 common package ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> There are many _functionnalities_ in a process life cycle :
>>>>>>
>>>>>> 1) *deploy the process* : it means creating a WS exposing the
>>>>>> process to make it available from anywhere in the world
>>>>>> By now, this step consist in deploying a WebService which will
>>>>>> call our BPEL engine. So when a WS call is received in the WS
>>>>>> engine, the implementation of this WS will call the BPEL engine
>>>>>> with input datas.
>>>>>>
>>>>>> 2) *undeploy the process* : undeploy the WS
>>>>>>
>>>>>> 3) *call the process* (some application somewhere in the world
>>>>>> wants to launch a new instance of the process). That is for this
>>>>>> functionnality (and the next one) that we are actually interested
>>>>>> in SM. What should be very nice is that SM receive the call and
>>>>>> give it through the NMR to the BPEL engine (so I think I have to
>>>>>> write a Service Engine to make it possible, isn't it ?). In this
>>>>>> case, the remote app could call the process using BC available in
>>>>>> SM (JMS or WS for example)
>>>>>>
>>>>>> 4) *call a remote WS from the process* : in a BPEL process, we
>>>>>> can call external WS. Here the needed functionnality is to give
>>>>>> the call (a Normalized Message I think) to SM which will send
>>>>>> datas in the specific protocol needed by the target partner. If a
>>>>>> remote partner activated a HelloWorld process by sending a JMS
>>>>>> message, we have to send the callback with output datas through a
>>>>>> JMS message.
>>>>>>
>>>>>> Please let me know if these functionnalities are available ?
>>>>>> Can you give me some guidelines to develop my own Service Engine
>>>>>> to plug my BPEL engine ?
>>>>>>
>>>>>> Thanks a lot
>>>>>> Regards,
>>>>>> Charles
>>>>>>
>>>>>> Guillaume Nodet wrote:
>>>>>>
>>>>>>> To answer your question, implementing a component that accepts
>>>>>>> service units deployments
>>>>>>> involve a bit of coding :) The xbean and wsdl1 packages
>>>>>>> provides two examples of deployers
>>>>>>> that you can use if they fit your needs, but you can of course
>>>>>>> write your own. The first one
>>>>>>> uses an xbean/spring xml config file as a deployement, and the
>>>>>>> wsdl1 accepts a wsdl file
>>>>>>> as a service unit.
>>>>>>>
>>>>>>> The components you have seen defines some classes, because each
>>>>>>> components processes
>>>>>>> things in a different way. The lwcontainer is quite simple : it
>>>>>>> has only 4 classes which are fairly
>>>>>>> simple. I do not really how you could handle service unit
>>>>>>> deployments in a simplier way ;)
>>>>>>> Could you please provide more informations of the kind of
>>>>>>> component you want to develop ?
>>>>>>> I may be able to provide you with more specific informations.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Guillaume Nodet
>>>>>>>
>>>>>>> Charles Souillard wrote:
>>>>>>>
>>>>>>>> Guillaume,
>>>>>>>>
>>>>>>>> I am trying to follow the instructions you gave me by
>>>>>>>> implementing Deployer class.
>>>>>>>>
>>>>>>>> I can see in service-common that there are two directories
>>>>>>>> under common : xbean and wsdl1.
>>>>>>>> What is the goal of these classes ?
>>>>>>>> servicemix-jsr181 and servicemix-lwcontainer are implementing
>>>>>>>> AbstractXBeanDeployer.
>>>>>>>> Which one do I have to implement ?
>>>>>>>> I can see that the examples you gave me (jsr181,lwcontainer...)
>>>>>>>> have a lot of other classes.
>>>>>>>> Why ?
>>>>>>>> Do I have to do the same ?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Charles
>>>>>>>>
>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>
>>>>>>>>> Your component will have to support deployment of service units.
>>>>>>>>> A service unit is a jar that will be exploded by ServiceMix
>>>>>>>>> and ServiceMix will give the path to the ServiceUnitManager
>>>>>>>>> interface
>>>>>>>>> implemented by your component.
>>>>>>>>>
>>>>>>>>> Most of the documentation on the wiki is currently focused on
>>>>>>>>> existing lightweight components : these components
>>>>>>>>> are, as you have noticed, hard wired with the servicemix.xml
>>>>>>>>> configuration file and, can activate only one endpoint
>>>>>>>>> and do not accept deployment.
>>>>>>>>> "Heavyweight components" can accept service unit deployments
>>>>>>>>> and can activate endpoints at runtime.
>>>>>>>>>
>>>>>>>>> If you use the servicemix-common project, you will have to
>>>>>>>>> implement a org.servicemix.common.Deployer
>>>>>>>>> interface specifically for your packaging model. This object
>>>>>>>>> create a org.servicemix.common.ServiceUnit object
>>>>>>>>> that contains several org.servicemix.common.Endpoint that will
>>>>>>>>> be responsible for creating according to the bpel process.
>>>>>>>>> Each endpoint will then be activated by the framework when the
>>>>>>>>> service unit is started. You will then be able
>>>>>>>>> to receive exchanges on this endpoint.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Guillaume Nodet
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Charles Souillard wrote:
>>>>>>>>>
>>>>>>>>>> Guillaume,
>>>>>>>>>> Thanks for your help, I will have a look.
>>>>>>>>>>
>>>>>>>>>> I have other questions...
>>>>>>>>>> My goal is to integrate my own BPEL engine (different from PXE).
>>>>>>>>>> For now, I only support WS calls and through servicemix I
>>>>>>>>>> want to be able to send/receive messages with different
>>>>>>>>>> protocols.
>>>>>>>>>>
>>>>>>>>>> I want to be able to deploy new processes dynamically
>>>>>>>>>> (without shutting down servicemix).
>>>>>>>>>> How my new processes will be known by servicemix ?
>>>>>>>>>>
>>>>>>>>>> All examples are based on a specific 'servicemix.xml' file
>>>>>>>>>> which is couple to the example.
>>>>>>>>>> How can I start servicemix in a 'standard' way and then be
>>>>>>>>>> able to receive/send new messages from/to a new process ?
>>>>>>>>>> Do I have to create a new 'servicemix.xml' specific file for
>>>>>>>>>> each new process ?
>>>>>>>>>>
>>>>>>>>>> I saw in http example that the endpoint was harcoded in the
>>>>>>>>>> servicemix.xml file. Is there any other way to do that ?
>>>>>>>>>>
>>>>>>>>>> I am not sure to understand what is a 'lightweight'
>>>>>>>>>> component. Can you explain me ?
>>>>>>>>>>
>>>>>>>>>> By now my BPEL engine sends WS calls. Is there any way to
>>>>>>>>>> keep it unmodified and to configure servicemix to catch these
>>>>>>>>>> calls and then send them through the NMR -> BC ?
>>>>>>>>>> If it is possible, it means it is not mandatory for me to
>>>>>>>>>> change my engine code and I will have the possibility to send
>>>>>>>>>> calls to partner understanding only JMS for example...
>>>>>>>>>>
>>>>>>>>>> I know it is a lot of work for you to answer many questions
>>>>>>>>>> but I am very interested in servicemix and I want to deploy
>>>>>>>>>> my future Bpel Service Engine on it.
>>>>>>>>>>
>>>>>>>>>> Thanks for your answers
>>>>>>>>>> Charles
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>
>>>>>>>>>>> What kind of service engine do you want to implement ?
>>>>>>>>>>> If you want a full jbi compliant SE, you should look at svn
>>>>>>>>>>> head
>>>>>>>>>>> which contains a module named servicemix-common (see
>>>>>>>>>>> http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-common/).
>>>>>>>>>>>
>>>>>>>>>>> This one contains abstract classes to ease the development
>>>>>>>>>>> of SE and BC.
>>>>>>>>>>> There is also a maven plugin to generate the installer.
>>>>>>>>>>> Take a look at some of existing service engines
>>>>>>>>>>> (servicemix-jsr181, servicemix-lwcontainer,
>>>>>>>>>>> servicemix-wsn2005) or binding components (servicemix-http,
>>>>>>>>>>> servicemix-jms).
>>>>>>>>>>>
>>>>>>>>>>> If you want a lightweight component, you can look at base
>>>>>>>>>>> classes in servicemix-core, the
>>>>>>>>>>> org.servicemix.components.util package contains lots of
>>>>>>>>>>> usefull classes for lightweight components
>>>>>>>>>>> (one endpoint, without any deployment). See
>>>>>>>>>>> http://servicemix.org/POJO+support
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>
>>>>>>>>>>> Charles Souillard wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> I was able to create and launch some examples using
>>>>>>>>>>>> servicemix components.
>>>>>>>>>>>>
>>>>>>>>>>>> Now, I want to create a new Service Engine and deploy it in
>>>>>>>>>>>> servicemix.
>>>>>>>>>>>> Does anybody knows where I can find a tutorial or some help ?
>>>>>>>>>>>>
>>>>>>>>>>>> I have already read the JBI spec. In addition I have
>>>>>>>>>>>> downloaded the sun tutorial but it is an old one (written
>>>>>>>>>>>> before the final release of JBI 1.0) and it needs some
>>>>>>>>>>>> com.sun... classes.
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you very much for your help !
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Charles
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
Re: Service Engine development
Posted by Guillaume Nodet <gn...@gmail.com>.
I'm not sure you should use the wsdl deployer as your main deployment
file is the bpel process.
I think you should write your own deployer which will read the bpel
process and create the necessary endpoints.
You have to define a few classes:
* the deployer inheriting from AbstractDeployer class
* a service unit container inheriting the ServiceUnit class
* an endpoint inheriting the Endpoint class
* an ExchangeProcessor : you will certainly need two different
processors, depending on the role of your endpoint (consumer or provider)
The deployer will create a service unit read and the bpel process. It
will create an endpoint each time a partner link will be found with the
necessary role.
Cheers,
Guillaume Nodet
Charles Souillard wrote:
> Guillaume ?
>
> Are you working today ?
>
> If not, is it possible for someone else to answer my questions ?
>
> ************************
> I have started debelopping my SE based on SM commons package which
> helps me a lot...
> Thanks for this pacakge.
>
> I need a precision on the ServiceUnitManager.
> In my case, deploying a process consist in giving to my engine :
> * 1 bpel file (the process)
> * 1 wsdl file (the process wsdl file)
> * 0 or many other wsdl files which are the interfaces of the partners
> I want to call
>
> So I started to work with the AbstractWsdl1Deployer and I modified it
> to take in charge my bpel file and some external wsdl files.
>
> My question concerns the three abstract methods in this class :
> * protected abstract Endpoint createEndpoint(ExtensibilityElement
> portElement, ExtensibilityElement bindingElement,JbiEndpoint
> jbiEndpoint);
> * protected abstract boolean filterPortElement(ExtensibilityElement
> element);
> * protected abstract boolean filterBindingElement(ExtensibilityElement
> element);
>
> I don't know why I have to implement them and I don't know how to
> implement them (as I don't know their use/utilities).
> I had a look at servicemix-http an servicemix-jms but I don't understand.
> In adition these two components (http + jms) are BCs...
> So perhaps the three abstract methods are only necessary for BCs ?
>
>
> I have another problem concerning doing the bridge between NMS and my
> specific Message.
> I had a look at both servicemix-http and servicemix-jsr81 but I have a
> problem understanding what is required/standard from what is specific...
> I think I should create a new class implementing common
> ExchangeProcessor...
> Can you give me a pattern to do that ?
>
> ***********************
> Thanks a lot
> Regards
> Charles
>
>
> Guillaume Nodet wrote:
>
>> The spring client toolkit has not been ported to SM 2.x / 3.x.
>>
>> But i do not think it would suit your needs btw.
>> Its purpose is to create simple components, and i do not think a BPEL
>> process engine is a simple one.
>>
>> If think you have two ways :
>> * use servicemix-commons (which i agree is not well documented ;)
>> * start from scratch with only the jbi api
>>
>> I suggest you start with servicemix-commons and write the the basic
>> needed classes :
>> bootstrap, component, deployer, service unit, endpoint
>> Then you could ask more specific questions that would be easier to
>> answer :)
>>
>> For testing you can take a look at the unit tests in one of the
>> component that uses servicemix-commons.
>> It's easy to set up a jbi container and activate your component
>> without relying on the jbi way.
>>
>> Guillaume Nodet
>>
>> Charles Souillard wrote:
>>
>>> Guillaume,
>>>
>>> I saw on the web (http://servicemix.org/Spring+Client+Toolkit) an
>>> example to create a first simple JBI component.
>>> But this doc is written to run with SM 1.0.
>>> Does this doc exist for SM 2.0.x... (current svn) ?
>>>
>>> Regards,
>>> Charles
>>>
>>> Guillaume Nodet wrote:
>>>
>>>> I do not think that you will be able to reuse directly the wsdl1
>>>> deployer.
>>>>
>>>> You will have to write a few classes :
>>>> * a org.apache.servicemix.common.Deployer : it must accept service
>>>> units (those with a .bpel file in it ?), and create a service unit
>>>> with endpoints in it
>>>> * a service unit : you will use one service unit per bpel process
>>>> and it will store all information relative to the process in it
>>>> * endpoints : each "incoming" partner link will be map to an
>>>> endpoint and will create a jbi endpoint on which you will receive
>>>> messages
>>>> * a component
>>>>
>>>> Calling the process will be done by sending a message to an
>>>> endpoint. You must also write the related ExchangeProcessor which
>>>> will be responsible for givingthe message to the process.
>>>>
>>>> There are two different interactions types : in-out and in-only.
>>>> In jbi, a request / response is performed by only one
>>>> MessageExchange which contains both the request and the response.
>>>> In such a case, if a jms request / response is performed, the jms
>>>> binding component will create an in-out exchange that you will
>>>> receive in your endpoint.
>>>> You have to call your process, retrieve the response, and send it
>>>> back. You do not have to directly use jms or http.
>>>>
>>>> When your process will invoke a partner, you will have to create a
>>>> jbi exchange and send it using the DeliveryChannel.
>>>> See
>>>> https://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/ConsumerProcessor.java
>>>> for an example.
>>>>
>>>> Guillaume Nodet
>>>>
>>>> Charles Souillard wrote:
>>>>
>>>>> Guillaume,
>>>>>
>>>>> I am trying to develop my SE based on the examples you gave me.
>>>>> Can you tell me where I can find a description of what these
>>>>> component are doing (their business logic) ?
>>>>> This could help me understanding how I have to implement common
>>>>> classes of SM for my case.
>>>>>
>>>>> For example, my BPEL processes are using two kinds of xml files :
>>>>> 1) some WSDL files for the WS descriptions :
>>>>> * at least one to expose the new BPEL process as a WebService
>>>>> * optionnaly others to describe others WebServices that the
>>>>> BPEL process will call (or receive a message from)
>>>>> 2) one BPEL file for the process description
>>>>>
>>>>> Do you think my case could be closed to wsdl1 common package ?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> There are many _functionnalities_ in a process life cycle :
>>>>>
>>>>> 1) *deploy the process* : it means creating a WS exposing the
>>>>> process to make it available from anywhere in the world
>>>>> By now, this step consist in deploying a WebService which will
>>>>> call our BPEL engine. So when a WS call is received in the WS
>>>>> engine, the implementation of this WS will call the BPEL engine
>>>>> with input datas.
>>>>>
>>>>> 2) *undeploy the process* : undeploy the WS
>>>>>
>>>>> 3) *call the process* (some application somewhere in the world
>>>>> wants to launch a new instance of the process). That is for this
>>>>> functionnality (and the next one) that we are actually interested
>>>>> in SM. What should be very nice is that SM receive the call and
>>>>> give it through the NMR to the BPEL engine (so I think I have to
>>>>> write a Service Engine to make it possible, isn't it ?). In this
>>>>> case, the remote app could call the process using BC available in
>>>>> SM (JMS or WS for example)
>>>>>
>>>>> 4) *call a remote WS from the process* : in a BPEL process, we can
>>>>> call external WS. Here the needed functionnality is to give the
>>>>> call (a Normalized Message I think) to SM which will send datas in
>>>>> the specific protocol needed by the target partner. If a remote
>>>>> partner activated a HelloWorld process by sending a JMS message,
>>>>> we have to send the callback with output datas through a JMS message.
>>>>>
>>>>> Please let me know if these functionnalities are available ?
>>>>> Can you give me some guidelines to develop my own Service Engine
>>>>> to plug my BPEL engine ?
>>>>>
>>>>> Thanks a lot
>>>>> Regards,
>>>>> Charles
>>>>>
>>>>> Guillaume Nodet wrote:
>>>>>
>>>>>> To answer your question, implementing a component that accepts
>>>>>> service units deployments
>>>>>> involve a bit of coding :) The xbean and wsdl1 packages provides
>>>>>> two examples of deployers
>>>>>> that you can use if they fit your needs, but you can of course
>>>>>> write your own. The first one
>>>>>> uses an xbean/spring xml config file as a deployement, and the
>>>>>> wsdl1 accepts a wsdl file
>>>>>> as a service unit.
>>>>>>
>>>>>> The components you have seen defines some classes, because each
>>>>>> components processes
>>>>>> things in a different way. The lwcontainer is quite simple : it
>>>>>> has only 4 classes which are fairly
>>>>>> simple. I do not really how you could handle service unit
>>>>>> deployments in a simplier way ;)
>>>>>> Could you please provide more informations of the kind of
>>>>>> component you want to develop ?
>>>>>> I may be able to provide you with more specific informations.
>>>>>>
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>>
>>>>>> Charles Souillard wrote:
>>>>>>
>>>>>>> Guillaume,
>>>>>>>
>>>>>>> I am trying to follow the instructions you gave me by
>>>>>>> implementing Deployer class.
>>>>>>>
>>>>>>> I can see in service-common that there are two directories under
>>>>>>> common : xbean and wsdl1.
>>>>>>> What is the goal of these classes ?
>>>>>>> servicemix-jsr181 and servicemix-lwcontainer are implementing
>>>>>>> AbstractXBeanDeployer.
>>>>>>> Which one do I have to implement ?
>>>>>>> I can see that the examples you gave me (jsr181,lwcontainer...)
>>>>>>> have a lot of other classes.
>>>>>>> Why ?
>>>>>>> Do I have to do the same ?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Charles
>>>>>>>
>>>>>>> Guillaume Nodet wrote:
>>>>>>>
>>>>>>>> Your component will have to support deployment of service units.
>>>>>>>> A service unit is a jar that will be exploded by ServiceMix and
>>>>>>>> ServiceMix will give the path to the ServiceUnitManager interface
>>>>>>>> implemented by your component.
>>>>>>>>
>>>>>>>> Most of the documentation on the wiki is currently focused on
>>>>>>>> existing lightweight components : these components
>>>>>>>> are, as you have noticed, hard wired with the servicemix.xml
>>>>>>>> configuration file and, can activate only one endpoint
>>>>>>>> and do not accept deployment.
>>>>>>>> "Heavyweight components" can accept service unit deployments
>>>>>>>> and can activate endpoints at runtime.
>>>>>>>>
>>>>>>>> If you use the servicemix-common project, you will have to
>>>>>>>> implement a org.servicemix.common.Deployer
>>>>>>>> interface specifically for your packaging model. This object
>>>>>>>> create a org.servicemix.common.ServiceUnit object
>>>>>>>> that contains several org.servicemix.common.Endpoint that will
>>>>>>>> be responsible for creating according to the bpel process.
>>>>>>>> Each endpoint will then be activated by the framework when the
>>>>>>>> service unit is started. You will then be able
>>>>>>>> to receive exchanges on this endpoint.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Guillaume Nodet
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Charles Souillard wrote:
>>>>>>>>
>>>>>>>>> Guillaume,
>>>>>>>>> Thanks for your help, I will have a look.
>>>>>>>>>
>>>>>>>>> I have other questions...
>>>>>>>>> My goal is to integrate my own BPEL engine (different from PXE).
>>>>>>>>> For now, I only support WS calls and through servicemix I want
>>>>>>>>> to be able to send/receive messages with different protocols.
>>>>>>>>>
>>>>>>>>> I want to be able to deploy new processes dynamically (without
>>>>>>>>> shutting down servicemix).
>>>>>>>>> How my new processes will be known by servicemix ?
>>>>>>>>>
>>>>>>>>> All examples are based on a specific 'servicemix.xml' file
>>>>>>>>> which is couple to the example.
>>>>>>>>> How can I start servicemix in a 'standard' way and then be
>>>>>>>>> able to receive/send new messages from/to a new process ?
>>>>>>>>> Do I have to create a new 'servicemix.xml' specific file for
>>>>>>>>> each new process ?
>>>>>>>>>
>>>>>>>>> I saw in http example that the endpoint was harcoded in the
>>>>>>>>> servicemix.xml file. Is there any other way to do that ?
>>>>>>>>>
>>>>>>>>> I am not sure to understand what is a 'lightweight' component.
>>>>>>>>> Can you explain me ?
>>>>>>>>>
>>>>>>>>> By now my BPEL engine sends WS calls. Is there any way to keep
>>>>>>>>> it unmodified and to configure servicemix to catch these calls
>>>>>>>>> and then send them through the NMR -> BC ?
>>>>>>>>> If it is possible, it means it is not mandatory for me to
>>>>>>>>> change my engine code and I will have the possibility to send
>>>>>>>>> calls to partner understanding only JMS for example...
>>>>>>>>>
>>>>>>>>> I know it is a lot of work for you to answer many questions
>>>>>>>>> but I am very interested in servicemix and I want to deploy my
>>>>>>>>> future Bpel Service Engine on it.
>>>>>>>>>
>>>>>>>>> Thanks for your answers
>>>>>>>>> Charles
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>
>>>>>>>>>> What kind of service engine do you want to implement ?
>>>>>>>>>> If you want a full jbi compliant SE, you should look at svn head
>>>>>>>>>> which contains a module named servicemix-common (see
>>>>>>>>>> http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-common/).
>>>>>>>>>>
>>>>>>>>>> This one contains abstract classes to ease the development of
>>>>>>>>>> SE and BC.
>>>>>>>>>> There is also a maven plugin to generate the installer.
>>>>>>>>>> Take a look at some of existing service engines
>>>>>>>>>> (servicemix-jsr181, servicemix-lwcontainer,
>>>>>>>>>> servicemix-wsn2005) or binding components (servicemix-http,
>>>>>>>>>> servicemix-jms).
>>>>>>>>>>
>>>>>>>>>> If you want a lightweight component, you can look at base
>>>>>>>>>> classes in servicemix-core, the
>>>>>>>>>> org.servicemix.components.util package contains lots of
>>>>>>>>>> usefull classes for lightweight components
>>>>>>>>>> (one endpoint, without any deployment). See
>>>>>>>>>> http://servicemix.org/POJO+support
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>
>>>>>>>>>> Charles Souillard wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> I was able to create and launch some examples using
>>>>>>>>>>> servicemix components.
>>>>>>>>>>>
>>>>>>>>>>> Now, I want to create a new Service Engine and deploy it in
>>>>>>>>>>> servicemix.
>>>>>>>>>>> Does anybody knows where I can find a tutorial or some help ?
>>>>>>>>>>>
>>>>>>>>>>> I have already read the JBI spec. In addition I have
>>>>>>>>>>> downloaded the sun tutorial but it is an old one (written
>>>>>>>>>>> before the final release of JBI 1.0) and it needs some
>>>>>>>>>>> com.sun... classes.
>>>>>>>>>>>
>>>>>>>>>>> Thank you very much for your help !
>>>>>>>>>>> Regards,
>>>>>>>>>>> Charles
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
Re: Service Engine development
Posted by Charles Souillard <Ch...@ext.bull.net>.
Guillaume ?
Are you working today ?
If not, is it possible for someone else to answer my questions ?
************************
I have started debelopping my SE based on SM commons package which helps
me a lot...
Thanks for this pacakge.
I need a precision on the ServiceUnitManager.
In my case, deploying a process consist in giving to my engine :
* 1 bpel file (the process)
* 1 wsdl file (the process wsdl file)
* 0 or many other wsdl files which are the interfaces of the partners I
want to call
So I started to work with the AbstractWsdl1Deployer and I modified it to
take in charge my bpel file and some external wsdl files.
My question concerns the three abstract methods in this class :
* protected abstract Endpoint createEndpoint(ExtensibilityElement
portElement, ExtensibilityElement bindingElement,JbiEndpoint jbiEndpoint);
* protected abstract boolean filterPortElement(ExtensibilityElement
element);
* protected abstract boolean filterBindingElement(ExtensibilityElement
element);
I don't know why I have to implement them and I don't know how to
implement them (as I don't know their use/utilities).
I had a look at servicemix-http an servicemix-jms but I don't understand.
In adition these two components (http + jms) are BCs...
So perhaps the three abstract methods are only necessary for BCs ?
I have another problem concerning doing the bridge between NMS and my
specific Message.
I had a look at both servicemix-http and servicemix-jsr81 but I have a
problem understanding what is required/standard from what is specific...
I think I should create a new class implementing common
ExchangeProcessor...
Can you give me a pattern to do that ?
***********************
Thanks a lot
Regards
Charles
Guillaume Nodet wrote:
> The spring client toolkit has not been ported to SM 2.x / 3.x.
>
> But i do not think it would suit your needs btw.
> Its purpose is to create simple components, and i do not think a BPEL
> process engine is a simple one.
>
> If think you have two ways :
> * use servicemix-commons (which i agree is not well documented ;)
> * start from scratch with only the jbi api
>
> I suggest you start with servicemix-commons and write the the basic
> needed classes :
> bootstrap, component, deployer, service unit, endpoint
> Then you could ask more specific questions that would be easier to
> answer :)
>
> For testing you can take a look at the unit tests in one of the
> component that uses servicemix-commons.
> It's easy to set up a jbi container and activate your component
> without relying on the jbi way.
>
> Guillaume Nodet
>
> Charles Souillard wrote:
>
>> Guillaume,
>>
>> I saw on the web (http://servicemix.org/Spring+Client+Toolkit) an
>> example to create a first simple JBI component.
>> But this doc is written to run with SM 1.0.
>> Does this doc exist for SM 2.0.x... (current svn) ?
>>
>> Regards,
>> Charles
>>
>> Guillaume Nodet wrote:
>>
>>> I do not think that you will be able to reuse directly the wsdl1
>>> deployer.
>>>
>>> You will have to write a few classes :
>>> * a org.apache.servicemix.common.Deployer : it must accept service
>>> units (those with a .bpel file in it ?), and create a service unit
>>> with endpoints in it
>>> * a service unit : you will use one service unit per bpel process
>>> and it will store all information relative to the process in it
>>> * endpoints : each "incoming" partner link will be map to an
>>> endpoint and will create a jbi endpoint on which you will receive
>>> messages
>>> * a component
>>>
>>> Calling the process will be done by sending a message to an
>>> endpoint. You must also write the related ExchangeProcessor which
>>> will be responsible for givingthe message to the process.
>>>
>>> There are two different interactions types : in-out and in-only.
>>> In jbi, a request / response is performed by only one
>>> MessageExchange which contains both the request and the response.
>>> In such a case, if a jms request / response is performed, the jms
>>> binding component will create an in-out exchange that you will
>>> receive in your endpoint.
>>> You have to call your process, retrieve the response, and send it
>>> back. You do not have to directly use jms or http.
>>>
>>> When your process will invoke a partner, you will have to create a
>>> jbi exchange and send it using the DeliveryChannel.
>>> See
>>> https://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/ConsumerProcessor.java
>>> for an example.
>>>
>>> Guillaume Nodet
>>>
>>> Charles Souillard wrote:
>>>
>>>> Guillaume,
>>>>
>>>> I am trying to develop my SE based on the examples you gave me.
>>>> Can you tell me where I can find a description of what these
>>>> component are doing (their business logic) ?
>>>> This could help me understanding how I have to implement common
>>>> classes of SM for my case.
>>>>
>>>> For example, my BPEL processes are using two kinds of xml files :
>>>> 1) some WSDL files for the WS descriptions :
>>>> * at least one to expose the new BPEL process as a WebService
>>>> * optionnaly others to describe others WebServices that the BPEL
>>>> process will call (or receive a message from)
>>>> 2) one BPEL file for the process description
>>>>
>>>> Do you think my case could be closed to wsdl1 common package ?
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> There are many _functionnalities_ in a process life cycle :
>>>>
>>>> 1) *deploy the process* : it means creating a WS exposing the
>>>> process to make it available from anywhere in the world
>>>> By now, this step consist in deploying a WebService which will
>>>> call our BPEL engine. So when a WS call is received in the WS
>>>> engine, the implementation of this WS will call the BPEL engine
>>>> with input datas.
>>>>
>>>> 2) *undeploy the process* : undeploy the WS
>>>>
>>>> 3) *call the process* (some application somewhere in the world
>>>> wants to launch a new instance of the process). That is for this
>>>> functionnality (and the next one) that we are actually interested
>>>> in SM. What should be very nice is that SM receive the call and
>>>> give it through the NMR to the BPEL engine (so I think I have to
>>>> write a Service Engine to make it possible, isn't it ?). In this
>>>> case, the remote app could call the process using BC available in
>>>> SM (JMS or WS for example)
>>>>
>>>> 4) *call a remote WS from the process* : in a BPEL process, we can
>>>> call external WS. Here the needed functionnality is to give the
>>>> call (a Normalized Message I think) to SM which will send datas in
>>>> the specific protocol needed by the target partner. If a remote
>>>> partner activated a HelloWorld process by sending a JMS message, we
>>>> have to send the callback with output datas through a JMS message.
>>>>
>>>> Please let me know if these functionnalities are available ?
>>>> Can you give me some guidelines to develop my own Service Engine to
>>>> plug my BPEL engine ?
>>>>
>>>> Thanks a lot
>>>> Regards,
>>>> Charles
>>>>
>>>> Guillaume Nodet wrote:
>>>>
>>>>> To answer your question, implementing a component that accepts
>>>>> service units deployments
>>>>> involve a bit of coding :) The xbean and wsdl1 packages provides
>>>>> two examples of deployers
>>>>> that you can use if they fit your needs, but you can of course
>>>>> write your own. The first one
>>>>> uses an xbean/spring xml config file as a deployement, and the
>>>>> wsdl1 accepts a wsdl file
>>>>> as a service unit.
>>>>>
>>>>> The components you have seen defines some classes, because each
>>>>> components processes
>>>>> things in a different way. The lwcontainer is quite simple : it
>>>>> has only 4 classes which are fairly
>>>>> simple. I do not really how you could handle service unit
>>>>> deployments in a simplier way ;)
>>>>> Could you please provide more informations of the kind of
>>>>> component you want to develop ?
>>>>> I may be able to provide you with more specific informations.
>>>>>
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>>
>>>>> Charles Souillard wrote:
>>>>>
>>>>>> Guillaume,
>>>>>>
>>>>>> I am trying to follow the instructions you gave me by
>>>>>> implementing Deployer class.
>>>>>>
>>>>>> I can see in service-common that there are two directories under
>>>>>> common : xbean and wsdl1.
>>>>>> What is the goal of these classes ?
>>>>>> servicemix-jsr181 and servicemix-lwcontainer are implementing
>>>>>> AbstractXBeanDeployer.
>>>>>> Which one do I have to implement ?
>>>>>> I can see that the examples you gave me (jsr181,lwcontainer...)
>>>>>> have a lot of other classes.
>>>>>> Why ?
>>>>>> Do I have to do the same ?
>>>>>>
>>>>>> Thanks,
>>>>>> Charles
>>>>>>
>>>>>> Guillaume Nodet wrote:
>>>>>>
>>>>>>> Your component will have to support deployment of service units.
>>>>>>> A service unit is a jar that will be exploded by ServiceMix and
>>>>>>> ServiceMix will give the path to the ServiceUnitManager interface
>>>>>>> implemented by your component.
>>>>>>>
>>>>>>> Most of the documentation on the wiki is currently focused on
>>>>>>> existing lightweight components : these components
>>>>>>> are, as you have noticed, hard wired with the servicemix.xml
>>>>>>> configuration file and, can activate only one endpoint
>>>>>>> and do not accept deployment.
>>>>>>> "Heavyweight components" can accept service unit deployments and
>>>>>>> can activate endpoints at runtime.
>>>>>>>
>>>>>>> If you use the servicemix-common project, you will have to
>>>>>>> implement a org.servicemix.common.Deployer
>>>>>>> interface specifically for your packaging model. This object
>>>>>>> create a org.servicemix.common.ServiceUnit object
>>>>>>> that contains several org.servicemix.common.Endpoint that will
>>>>>>> be responsible for creating according to the bpel process.
>>>>>>> Each endpoint will then be activated by the framework when the
>>>>>>> service unit is started. You will then be able
>>>>>>> to receive exchanges on this endpoint.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Guillaume Nodet
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Charles Souillard wrote:
>>>>>>>
>>>>>>>> Guillaume,
>>>>>>>> Thanks for your help, I will have a look.
>>>>>>>>
>>>>>>>> I have other questions...
>>>>>>>> My goal is to integrate my own BPEL engine (different from PXE).
>>>>>>>> For now, I only support WS calls and through servicemix I want
>>>>>>>> to be able to send/receive messages with different protocols.
>>>>>>>>
>>>>>>>> I want to be able to deploy new processes dynamically (without
>>>>>>>> shutting down servicemix).
>>>>>>>> How my new processes will be known by servicemix ?
>>>>>>>>
>>>>>>>> All examples are based on a specific 'servicemix.xml' file
>>>>>>>> which is couple to the example.
>>>>>>>> How can I start servicemix in a 'standard' way and then be able
>>>>>>>> to receive/send new messages from/to a new process ?
>>>>>>>> Do I have to create a new 'servicemix.xml' specific file for
>>>>>>>> each new process ?
>>>>>>>>
>>>>>>>> I saw in http example that the endpoint was harcoded in the
>>>>>>>> servicemix.xml file. Is there any other way to do that ?
>>>>>>>>
>>>>>>>> I am not sure to understand what is a 'lightweight' component.
>>>>>>>> Can you explain me ?
>>>>>>>>
>>>>>>>> By now my BPEL engine sends WS calls. Is there any way to keep
>>>>>>>> it unmodified and to configure servicemix to catch these calls
>>>>>>>> and then send them through the NMR -> BC ?
>>>>>>>> If it is possible, it means it is not mandatory for me to
>>>>>>>> change my engine code and I will have the possibility to send
>>>>>>>> calls to partner understanding only JMS for example...
>>>>>>>>
>>>>>>>> I know it is a lot of work for you to answer many questions but
>>>>>>>> I am very interested in servicemix and I want to deploy my
>>>>>>>> future Bpel Service Engine on it.
>>>>>>>>
>>>>>>>> Thanks for your answers
>>>>>>>> Charles
>>>>>>>>
>>>>>>>>
>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>
>>>>>>>>> What kind of service engine do you want to implement ?
>>>>>>>>> If you want a full jbi compliant SE, you should look at svn head
>>>>>>>>> which contains a module named servicemix-common (see
>>>>>>>>> http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-common/).
>>>>>>>>>
>>>>>>>>> This one contains abstract classes to ease the development of
>>>>>>>>> SE and BC.
>>>>>>>>> There is also a maven plugin to generate the installer.
>>>>>>>>> Take a look at some of existing service engines
>>>>>>>>> (servicemix-jsr181, servicemix-lwcontainer,
>>>>>>>>> servicemix-wsn2005) or binding components (servicemix-http,
>>>>>>>>> servicemix-jms).
>>>>>>>>>
>>>>>>>>> If you want a lightweight component, you can look at base
>>>>>>>>> classes in servicemix-core, the
>>>>>>>>> org.servicemix.components.util package contains lots of
>>>>>>>>> usefull classes for lightweight components
>>>>>>>>> (one endpoint, without any deployment). See
>>>>>>>>> http://servicemix.org/POJO+support
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Guillaume Nodet
>>>>>>>>>
>>>>>>>>> Charles Souillard wrote:
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I was able to create and launch some examples using
>>>>>>>>>> servicemix components.
>>>>>>>>>>
>>>>>>>>>> Now, I want to create a new Service Engine and deploy it in
>>>>>>>>>> servicemix.
>>>>>>>>>> Does anybody knows where I can find a tutorial or some help ?
>>>>>>>>>>
>>>>>>>>>> I have already read the JBI spec. In addition I have
>>>>>>>>>> downloaded the sun tutorial but it is an old one (written
>>>>>>>>>> before the final release of JBI 1.0) and it needs some
>>>>>>>>>> com.sun... classes.
>>>>>>>>>>
>>>>>>>>>> Thank you very much for your help !
>>>>>>>>>> Regards,
>>>>>>>>>> Charles
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
Re: Service Engine development
Posted by Guillaume Nodet <gu...@worldonline.fr>.
The spring client toolkit has not been ported to SM 2.x / 3.x.
But i do not think it would suit your needs btw.
Its purpose is to create simple components, and i do not think a BPEL
process engine is a simple one.
If think you have two ways :
* use servicemix-commons (which i agree is not well documented ;)
* start from scratch with only the jbi api
I suggest you start with servicemix-commons and write the the basic
needed classes :
bootstrap, component, deployer, service unit, endpoint
Then you could ask more specific questions that would be easier to answer :)
For testing you can take a look at the unit tests in one of the
component that uses servicemix-commons.
It's easy to set up a jbi container and activate your component without
relying on the jbi way.
Guillaume Nodet
Charles Souillard wrote:
> Guillaume,
>
> I saw on the web (http://servicemix.org/Spring+Client+Toolkit) an
> example to create a first simple JBI component.
> But this doc is written to run with SM 1.0.
> Does this doc exist for SM 2.0.x... (current svn) ?
>
> Regards,
> Charles
>
> Guillaume Nodet wrote:
>
>> I do not think that you will be able to reuse directly the wsdl1
>> deployer.
>>
>> You will have to write a few classes :
>> * a org.apache.servicemix.common.Deployer : it must accept service
>> units (those with a .bpel file in it ?), and create a service unit
>> with endpoints in it
>> * a service unit : you will use one service unit per bpel process
>> and it will store all information relative to the process in it
>> * endpoints : each "incoming" partner link will be map to an
>> endpoint and will create a jbi endpoint on which you will receive
>> messages
>> * a component
>>
>> Calling the process will be done by sending a message to an
>> endpoint. You must also write the related ExchangeProcessor which
>> will be responsible for givingthe message to the process.
>>
>> There are two different interactions types : in-out and in-only.
>> In jbi, a request / response is performed by only one MessageExchange
>> which contains both the request and the response.
>> In such a case, if a jms request / response is performed, the jms
>> binding component will create an in-out exchange that you will
>> receive in your endpoint.
>> You have to call your process, retrieve the response, and send it
>> back. You do not have to directly use jms or http.
>>
>> When your process will invoke a partner, you will have to create a
>> jbi exchange and send it using the DeliveryChannel.
>> See
>> https://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/ConsumerProcessor.java
>> for an example.
>>
>> Guillaume Nodet
>>
>> Charles Souillard wrote:
>>
>>> Guillaume,
>>>
>>> I am trying to develop my SE based on the examples you gave me.
>>> Can you tell me where I can find a description of what these
>>> component are doing (their business logic) ?
>>> This could help me understanding how I have to implement common
>>> classes of SM for my case.
>>>
>>> For example, my BPEL processes are using two kinds of xml files :
>>> 1) some WSDL files for the WS descriptions :
>>> * at least one to expose the new BPEL process as a WebService
>>> * optionnaly others to describe others WebServices that the BPEL
>>> process will call (or receive a message from)
>>> 2) one BPEL file for the process description
>>>
>>> Do you think my case could be closed to wsdl1 common package ?
>>
>>
>>
>>
>>>
>>> There are many _functionnalities_ in a process life cycle :
>>>
>>> 1) *deploy the process* : it means creating a WS exposing the
>>> process to make it available from anywhere in the world
>>> By now, this step consist in deploying a WebService which will
>>> call our BPEL engine. So when a WS call is received in the WS
>>> engine, the implementation of this WS will call the BPEL engine with
>>> input datas.
>>>
>>> 2) *undeploy the process* : undeploy the WS
>>>
>>> 3) *call the process* (some application somewhere in the world wants
>>> to launch a new instance of the process). That is for this
>>> functionnality (and the next one) that we are actually interested in
>>> SM. What should be very nice is that SM receive the call and give it
>>> through the NMR to the BPEL engine (so I think I have to write a
>>> Service Engine to make it possible, isn't it ?). In this case, the
>>> remote app could call the process using BC available in SM (JMS or
>>> WS for example)
>>>
>>> 4) *call a remote WS from the process* : in a BPEL process, we can
>>> call external WS. Here the needed functionnality is to give the call
>>> (a Normalized Message I think) to SM which will send datas in the
>>> specific protocol needed by the target partner. If a remote partner
>>> activated a HelloWorld process by sending a JMS message, we have to
>>> send the callback with output datas through a JMS message.
>>>
>>> Please let me know if these functionnalities are available ?
>>> Can you give me some guidelines to develop my own Service Engine to
>>> plug my BPEL engine ?
>>>
>>> Thanks a lot
>>> Regards,
>>> Charles
>>>
>>> Guillaume Nodet wrote:
>>>
>>>> To answer your question, implementing a component that accepts
>>>> service units deployments
>>>> involve a bit of coding :) The xbean and wsdl1 packages provides
>>>> two examples of deployers
>>>> that you can use if they fit your needs, but you can of course
>>>> write your own. The first one
>>>> uses an xbean/spring xml config file as a deployement, and the
>>>> wsdl1 accepts a wsdl file
>>>> as a service unit.
>>>>
>>>> The components you have seen defines some classes, because each
>>>> components processes
>>>> things in a different way. The lwcontainer is quite simple : it
>>>> has only 4 classes which are fairly
>>>> simple. I do not really how you could handle service unit
>>>> deployments in a simplier way ;)
>>>> Could you please provide more informations of the kind of component
>>>> you want to develop ?
>>>> I may be able to provide you with more specific informations.
>>>>
>>>> Cheers,
>>>> Guillaume Nodet
>>>>
>>>> Charles Souillard wrote:
>>>>
>>>>> Guillaume,
>>>>>
>>>>> I am trying to follow the instructions you gave me by implementing
>>>>> Deployer class.
>>>>>
>>>>> I can see in service-common that there are two directories under
>>>>> common : xbean and wsdl1.
>>>>> What is the goal of these classes ?
>>>>> servicemix-jsr181 and servicemix-lwcontainer are implementing
>>>>> AbstractXBeanDeployer.
>>>>> Which one do I have to implement ?
>>>>> I can see that the examples you gave me (jsr181,lwcontainer...)
>>>>> have a lot of other classes.
>>>>> Why ?
>>>>> Do I have to do the same ?
>>>>>
>>>>> Thanks,
>>>>> Charles
>>>>>
>>>>> Guillaume Nodet wrote:
>>>>>
>>>>>> Your component will have to support deployment of service units.
>>>>>> A service unit is a jar that will be exploded by ServiceMix and
>>>>>> ServiceMix will give the path to the ServiceUnitManager interface
>>>>>> implemented by your component.
>>>>>>
>>>>>> Most of the documentation on the wiki is currently focused on
>>>>>> existing lightweight components : these components
>>>>>> are, as you have noticed, hard wired with the servicemix.xml
>>>>>> configuration file and, can activate only one endpoint
>>>>>> and do not accept deployment.
>>>>>> "Heavyweight components" can accept service unit deployments and
>>>>>> can activate endpoints at runtime.
>>>>>>
>>>>>> If you use the servicemix-common project, you will have to
>>>>>> implement a org.servicemix.common.Deployer
>>>>>> interface specifically for your packaging model. This object
>>>>>> create a org.servicemix.common.ServiceUnit object
>>>>>> that contains several org.servicemix.common.Endpoint that will be
>>>>>> responsible for creating according to the bpel process.
>>>>>> Each endpoint will then be activated by the framework when the
>>>>>> service unit is started. You will then be able
>>>>>> to receive exchanges on this endpoint.
>>>>>>
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>>
>>>>>>
>>>>>>
>>>>>> Charles Souillard wrote:
>>>>>>
>>>>>>> Guillaume,
>>>>>>> Thanks for your help, I will have a look.
>>>>>>>
>>>>>>> I have other questions...
>>>>>>> My goal is to integrate my own BPEL engine (different from PXE).
>>>>>>> For now, I only support WS calls and through servicemix I want
>>>>>>> to be able to send/receive messages with different protocols.
>>>>>>>
>>>>>>> I want to be able to deploy new processes dynamically (without
>>>>>>> shutting down servicemix).
>>>>>>> How my new processes will be known by servicemix ?
>>>>>>>
>>>>>>> All examples are based on a specific 'servicemix.xml' file which
>>>>>>> is couple to the example.
>>>>>>> How can I start servicemix in a 'standard' way and then be able
>>>>>>> to receive/send new messages from/to a new process ?
>>>>>>> Do I have to create a new 'servicemix.xml' specific file for
>>>>>>> each new process ?
>>>>>>>
>>>>>>> I saw in http example that the endpoint was harcoded in the
>>>>>>> servicemix.xml file. Is there any other way to do that ?
>>>>>>>
>>>>>>> I am not sure to understand what is a 'lightweight' component.
>>>>>>> Can you explain me ?
>>>>>>>
>>>>>>> By now my BPEL engine sends WS calls. Is there any way to keep
>>>>>>> it unmodified and to configure servicemix to catch these calls
>>>>>>> and then send them through the NMR -> BC ?
>>>>>>> If it is possible, it means it is not mandatory for me to change
>>>>>>> my engine code and I will have the possibility to send calls to
>>>>>>> partner understanding only JMS for example...
>>>>>>>
>>>>>>> I know it is a lot of work for you to answer many questions but
>>>>>>> I am very interested in servicemix and I want to deploy my
>>>>>>> future Bpel Service Engine on it.
>>>>>>>
>>>>>>> Thanks for your answers
>>>>>>> Charles
>>>>>>>
>>>>>>>
>>>>>>> Guillaume Nodet wrote:
>>>>>>>
>>>>>>>> What kind of service engine do you want to implement ?
>>>>>>>> If you want a full jbi compliant SE, you should look at svn head
>>>>>>>> which contains a module named servicemix-common (see
>>>>>>>> http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-common/).
>>>>>>>>
>>>>>>>> This one contains abstract classes to ease the development of
>>>>>>>> SE and BC.
>>>>>>>> There is also a maven plugin to generate the installer.
>>>>>>>> Take a look at some of existing service engines
>>>>>>>> (servicemix-jsr181, servicemix-lwcontainer,
>>>>>>>> servicemix-wsn2005) or binding components (servicemix-http,
>>>>>>>> servicemix-jms).
>>>>>>>>
>>>>>>>> If you want a lightweight component, you can look at base
>>>>>>>> classes in servicemix-core, the
>>>>>>>> org.servicemix.components.util package contains lots of usefull
>>>>>>>> classes for lightweight components
>>>>>>>> (one endpoint, without any deployment). See
>>>>>>>> http://servicemix.org/POJO+support
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Guillaume Nodet
>>>>>>>>
>>>>>>>> Charles Souillard wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I was able to create and launch some examples using servicemix
>>>>>>>>> components.
>>>>>>>>>
>>>>>>>>> Now, I want to create a new Service Engine and deploy it in
>>>>>>>>> servicemix.
>>>>>>>>> Does anybody knows where I can find a tutorial or some help ?
>>>>>>>>>
>>>>>>>>> I have already read the JBI spec. In addition I have
>>>>>>>>> downloaded the sun tutorial but it is an old one (written
>>>>>>>>> before the final release of JBI 1.0) and it needs some
>>>>>>>>> com.sun... classes.
>>>>>>>>>
>>>>>>>>> Thank you very much for your help !
>>>>>>>>> Regards,
>>>>>>>>> Charles
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
Re: Service Engine development
Posted by Charles Souillard <ch...@ext.bull.net>.
Guillaume,
I saw on the web (http://servicemix.org/Spring+Client+Toolkit) an
example to create a first simple JBI component.
But this doc is written to run with SM 1.0.
Does this doc exist for SM 2.0.x... (current svn) ?
Regards,
Charles
Guillaume Nodet wrote:
> I do not think that you will be able to reuse directly the wsdl1
> deployer.
>
> You will have to write a few classes :
> * a org.apache.servicemix.common.Deployer : it must accept service
> units (those with a .bpel file in it ?), and create a service unit
> with endpoints in it
> * a service unit : you will use one service unit per bpel process and
> it will store all information relative to the process in it
> * endpoints : each "incoming" partner link will be map to an endpoint
> and will create a jbi endpoint on which you will receive messages
> * a component
>
> Calling the process will be done by sending a message to an endpoint.
> You must also write the related ExchangeProcessor which will be
> responsible for givingthe message to the process.
>
> There are two different interactions types : in-out and in-only.
> In jbi, a request / response is performed by only one MessageExchange
> which contains both the request and the response.
> In such a case, if a jms request / response is performed, the jms
> binding component will create an in-out exchange that you will receive
> in your endpoint.
> You have to call your process, retrieve the response, and send it
> back. You do not have to directly use jms or http.
>
> When your process will invoke a partner, you will have to create a jbi
> exchange and send it using the DeliveryChannel.
> See
> https://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/ConsumerProcessor.java
> for an example.
>
> Guillaume Nodet
>
> Charles Souillard wrote:
>
>> Guillaume,
>>
>> I am trying to develop my SE based on the examples you gave me.
>> Can you tell me where I can find a description of what these
>> component are doing (their business logic) ?
>> This could help me understanding how I have to implement common
>> classes of SM for my case.
>>
>> For example, my BPEL processes are using two kinds of xml files :
>> 1) some WSDL files for the WS descriptions :
>> * at least one to expose the new BPEL process as a WebService
>> * optionnaly others to describe others WebServices that the BPEL
>> process will call (or receive a message from)
>> 2) one BPEL file for the process description
>>
>> Do you think my case could be closed to wsdl1 common package ?
>
>
>
>>
>> There are many _functionnalities_ in a process life cycle :
>>
>> 1) *deploy the process* : it means creating a WS exposing the process
>> to make it available from anywhere in the world
>> By now, this step consist in deploying a WebService which will
>> call our BPEL engine. So when a WS call is received in the WS
>> engine, the implementation of this WS will call the BPEL engine with
>> input datas.
>>
>> 2) *undeploy the process* : undeploy the WS
>>
>> 3) *call the process* (some application somewhere in the world wants
>> to launch a new instance of the process). That is for this
>> functionnality (and the next one) that we are actually interested in
>> SM. What should be very nice is that SM receive the call and give it
>> through the NMR to the BPEL engine (so I think I have to write a
>> Service Engine to make it possible, isn't it ?). In this case, the
>> remote app could call the process using BC available in SM (JMS or WS
>> for example)
>>
>> 4) *call a remote WS from the process* : in a BPEL process, we can
>> call external WS. Here the needed functionnality is to give the call
>> (a Normalized Message I think) to SM which will send datas in the
>> specific protocol needed by the target partner. If a remote partner
>> activated a HelloWorld process by sending a JMS message, we have to
>> send the callback with output datas through a JMS message.
>>
>> Please let me know if these functionnalities are available ?
>> Can you give me some guidelines to develop my own Service Engine to
>> plug my BPEL engine ?
>>
>> Thanks a lot
>> Regards,
>> Charles
>>
>> Guillaume Nodet wrote:
>>
>>> To answer your question, implementing a component that accepts
>>> service units deployments
>>> involve a bit of coding :) The xbean and wsdl1 packages provides
>>> two examples of deployers
>>> that you can use if they fit your needs, but you can of course write
>>> your own. The first one
>>> uses an xbean/spring xml config file as a deployement, and the wsdl1
>>> accepts a wsdl file
>>> as a service unit.
>>>
>>> The components you have seen defines some classes, because each
>>> components processes
>>> things in a different way. The lwcontainer is quite simple : it has
>>> only 4 classes which are fairly
>>> simple. I do not really how you could handle service unit
>>> deployments in a simplier way ;)
>>> Could you please provide more informations of the kind of component
>>> you want to develop ?
>>> I may be able to provide you with more specific informations.
>>>
>>> Cheers,
>>> Guillaume Nodet
>>>
>>> Charles Souillard wrote:
>>>
>>>> Guillaume,
>>>>
>>>> I am trying to follow the instructions you gave me by implementing
>>>> Deployer class.
>>>>
>>>> I can see in service-common that there are two directories under
>>>> common : xbean and wsdl1.
>>>> What is the goal of these classes ?
>>>> servicemix-jsr181 and servicemix-lwcontainer are implementing
>>>> AbstractXBeanDeployer.
>>>> Which one do I have to implement ?
>>>> I can see that the examples you gave me (jsr181,lwcontainer...)
>>>> have a lot of other classes.
>>>> Why ?
>>>> Do I have to do the same ?
>>>>
>>>> Thanks,
>>>> Charles
>>>>
>>>> Guillaume Nodet wrote:
>>>>
>>>>> Your component will have to support deployment of service units.
>>>>> A service unit is a jar that will be exploded by ServiceMix and
>>>>> ServiceMix will give the path to the ServiceUnitManager interface
>>>>> implemented by your component.
>>>>>
>>>>> Most of the documentation on the wiki is currently focused on
>>>>> existing lightweight components : these components
>>>>> are, as you have noticed, hard wired with the servicemix.xml
>>>>> configuration file and, can activate only one endpoint
>>>>> and do not accept deployment.
>>>>> "Heavyweight components" can accept service unit deployments and
>>>>> can activate endpoints at runtime.
>>>>>
>>>>> If you use the servicemix-common project, you will have to
>>>>> implement a org.servicemix.common.Deployer
>>>>> interface specifically for your packaging model. This object
>>>>> create a org.servicemix.common.ServiceUnit object
>>>>> that contains several org.servicemix.common.Endpoint that will be
>>>>> responsible for creating according to the bpel process.
>>>>> Each endpoint will then be activated by the framework when the
>>>>> service unit is started. You will then be able
>>>>> to receive exchanges on this endpoint.
>>>>>
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>>
>>>>>
>>>>>
>>>>> Charles Souillard wrote:
>>>>>
>>>>>> Guillaume,
>>>>>> Thanks for your help, I will have a look.
>>>>>>
>>>>>> I have other questions...
>>>>>> My goal is to integrate my own BPEL engine (different from PXE).
>>>>>> For now, I only support WS calls and through servicemix I want to
>>>>>> be able to send/receive messages with different protocols.
>>>>>>
>>>>>> I want to be able to deploy new processes dynamically (without
>>>>>> shutting down servicemix).
>>>>>> How my new processes will be known by servicemix ?
>>>>>>
>>>>>> All examples are based on a specific 'servicemix.xml' file which
>>>>>> is couple to the example.
>>>>>> How can I start servicemix in a 'standard' way and then be able
>>>>>> to receive/send new messages from/to a new process ?
>>>>>> Do I have to create a new 'servicemix.xml' specific file for each
>>>>>> new process ?
>>>>>>
>>>>>> I saw in http example that the endpoint was harcoded in the
>>>>>> servicemix.xml file. Is there any other way to do that ?
>>>>>>
>>>>>> I am not sure to understand what is a 'lightweight' component.
>>>>>> Can you explain me ?
>>>>>>
>>>>>> By now my BPEL engine sends WS calls. Is there any way to keep it
>>>>>> unmodified and to configure servicemix to catch these calls and
>>>>>> then send them through the NMR -> BC ?
>>>>>> If it is possible, it means it is not mandatory for me to change
>>>>>> my engine code and I will have the possibility to send calls to
>>>>>> partner understanding only JMS for example...
>>>>>>
>>>>>> I know it is a lot of work for you to answer many questions but I
>>>>>> am very interested in servicemix and I want to deploy my future
>>>>>> Bpel Service Engine on it.
>>>>>>
>>>>>> Thanks for your answers
>>>>>> Charles
>>>>>>
>>>>>>
>>>>>> Guillaume Nodet wrote:
>>>>>>
>>>>>>> What kind of service engine do you want to implement ?
>>>>>>> If you want a full jbi compliant SE, you should look at svn head
>>>>>>> which contains a module named servicemix-common (see
>>>>>>> http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-common/).
>>>>>>>
>>>>>>> This one contains abstract classes to ease the development of SE
>>>>>>> and BC.
>>>>>>> There is also a maven plugin to generate the installer.
>>>>>>> Take a look at some of existing service engines
>>>>>>> (servicemix-jsr181, servicemix-lwcontainer,
>>>>>>> servicemix-wsn2005) or binding components (servicemix-http,
>>>>>>> servicemix-jms).
>>>>>>>
>>>>>>> If you want a lightweight component, you can look at base
>>>>>>> classes in servicemix-core, the
>>>>>>> org.servicemix.components.util package contains lots of usefull
>>>>>>> classes for lightweight components
>>>>>>> (one endpoint, without any deployment). See
>>>>>>> http://servicemix.org/POJO+support
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Guillaume Nodet
>>>>>>>
>>>>>>> Charles Souillard wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I was able to create and launch some examples using servicemix
>>>>>>>> components.
>>>>>>>>
>>>>>>>> Now, I want to create a new Service Engine and deploy it in
>>>>>>>> servicemix.
>>>>>>>> Does anybody knows where I can find a tutorial or some help ?
>>>>>>>>
>>>>>>>> I have already read the JBI spec. In addition I have downloaded
>>>>>>>> the sun tutorial but it is an old one (written before the final
>>>>>>>> release of JBI 1.0) and it needs some com.sun... classes.
>>>>>>>>
>>>>>>>> Thank you very much for your help !
>>>>>>>> Regards,
>>>>>>>> Charles
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
Re: Service Engine development
Posted by Guillaume Nodet <gu...@worldonline.fr>.
I do not think that you will be able to reuse directly the wsdl1 deployer.
You will have to write a few classes :
* a org.apache.servicemix.common.Deployer : it must accept service
units (those with a .bpel file in it ?), and create a service unit with
endpoints in it
* a service unit : you will use one service unit per bpel process and
it will store all information relative to the process in it
* endpoints : each "incoming" partner link will be map to an endpoint
and will create a jbi endpoint on which you will receive messages
* a component
Calling the process will be done by sending a message to an endpoint.
You must also write the related ExchangeProcessor which will be
responsible for givingthe message to the process.
There are two different interactions types : in-out and in-only.
In jbi, a request / response is performed by only one MessageExchange
which contains both the request and the response.
In such a case, if a jms request / response is performed, the jms
binding component will create an in-out exchange that you will receive
in your endpoint.
You have to call your process, retrieve the response, and send it back.
You do not have to directly use jms or http.
When your process will invoke a partner, you will have to create a jbi
exchange and send it using the DeliveryChannel.
See
https://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/ConsumerProcessor.java
for an example.
Guillaume Nodet
Charles Souillard wrote:
> Guillaume,
>
> I am trying to develop my SE based on the examples you gave me.
> Can you tell me where I can find a description of what these component
> are doing (their business logic) ?
> This could help me understanding how I have to implement common
> classes of SM for my case.
>
> For example, my BPEL processes are using two kinds of xml files :
> 1) some WSDL files for the WS descriptions :
> * at least one to expose the new BPEL process as a WebService
> * optionnaly others to describe others WebServices that the BPEL
> process will call (or receive a message from)
> 2) one BPEL file for the process description
>
> Do you think my case could be closed to wsdl1 common package ?
>
> There are many _functionnalities_ in a process life cycle :
>
> 1) *deploy the process* : it means creating a WS exposing the process
> to make it available from anywhere in the world
> By now, this step consist in deploying a WebService which will call
> our BPEL engine. So when a WS call is received in the WS engine,
> the implementation of this WS will call the BPEL engine with input datas.
>
> 2) *undeploy the process* : undeploy the WS
>
> 3) *call the process* (some application somewhere in the world wants
> to launch a new instance of the process). That is for this
> functionnality (and the next one) that we are actually interested in
> SM. What should be very nice is that SM receive the call and give it
> through the NMR to the BPEL engine (so I think I have to write a
> Service Engine to make it possible, isn't it ?). In this case, the
> remote app could call the process using BC available in SM (JMS or WS
> for example)
>
> 4) *call a remote WS from the process* : in a BPEL process, we can
> call external WS. Here the needed functionnality is to give the call
> (a Normalized Message I think) to SM which will send datas in the
> specific protocol needed by the target partner. If a remote partner
> activated a HelloWorld process by sending a JMS message, we have to
> send the callback with output datas through a JMS message.
>
> Please let me know if these functionnalities are available ?
> Can you give me some guidelines to develop my own Service Engine to
> plug my BPEL engine ?
>
> Thanks a lot
> Regards,
> Charles
>
> Guillaume Nodet wrote:
>
>> To answer your question, implementing a component that accepts
>> service units deployments
>> involve a bit of coding :) The xbean and wsdl1 packages provides two
>> examples of deployers
>> that you can use if they fit your needs, but you can of course write
>> your own. The first one
>> uses an xbean/spring xml config file as a deployement, and the wsdl1
>> accepts a wsdl file
>> as a service unit.
>>
>> The components you have seen defines some classes, because each
>> components processes
>> things in a different way. The lwcontainer is quite simple : it has
>> only 4 classes which are fairly
>> simple. I do not really how you could handle service unit
>> deployments in a simplier way ;)
>> Could you please provide more informations of the kind of component
>> you want to develop ?
>> I may be able to provide you with more specific informations.
>>
>> Cheers,
>> Guillaume Nodet
>>
>> Charles Souillard wrote:
>>
>>> Guillaume,
>>>
>>> I am trying to follow the instructions you gave me by implementing
>>> Deployer class.
>>>
>>> I can see in service-common that there are two directories under
>>> common : xbean and wsdl1.
>>> What is the goal of these classes ?
>>> servicemix-jsr181 and servicemix-lwcontainer are implementing
>>> AbstractXBeanDeployer.
>>> Which one do I have to implement ?
>>> I can see that the examples you gave me (jsr181,lwcontainer...) have
>>> a lot of other classes.
>>> Why ?
>>> Do I have to do the same ?
>>>
>>> Thanks,
>>> Charles
>>>
>>> Guillaume Nodet wrote:
>>>
>>>> Your component will have to support deployment of service units.
>>>> A service unit is a jar that will be exploded by ServiceMix and
>>>> ServiceMix will give the path to the ServiceUnitManager interface
>>>> implemented by your component.
>>>>
>>>> Most of the documentation on the wiki is currently focused on
>>>> existing lightweight components : these components
>>>> are, as you have noticed, hard wired with the servicemix.xml
>>>> configuration file and, can activate only one endpoint
>>>> and do not accept deployment.
>>>> "Heavyweight components" can accept service unit deployments and
>>>> can activate endpoints at runtime.
>>>>
>>>> If you use the servicemix-common project, you will have to
>>>> implement a org.servicemix.common.Deployer
>>>> interface specifically for your packaging model. This object
>>>> create a org.servicemix.common.ServiceUnit object
>>>> that contains several org.servicemix.common.Endpoint that will be
>>>> responsible for creating according to the bpel process.
>>>> Each endpoint will then be activated by the framework when the
>>>> service unit is started. You will then be able
>>>> to receive exchanges on this endpoint.
>>>>
>>>> Cheers,
>>>> Guillaume Nodet
>>>>
>>>>
>>>>
>>>> Charles Souillard wrote:
>>>>
>>>>> Guillaume,
>>>>> Thanks for your help, I will have a look.
>>>>>
>>>>> I have other questions...
>>>>> My goal is to integrate my own BPEL engine (different from PXE).
>>>>> For now, I only support WS calls and through servicemix I want to
>>>>> be able to send/receive messages with different protocols.
>>>>>
>>>>> I want to be able to deploy new processes dynamically (without
>>>>> shutting down servicemix).
>>>>> How my new processes will be known by servicemix ?
>>>>>
>>>>> All examples are based on a specific 'servicemix.xml' file which
>>>>> is couple to the example.
>>>>> How can I start servicemix in a 'standard' way and then be able to
>>>>> receive/send new messages from/to a new process ?
>>>>> Do I have to create a new 'servicemix.xml' specific file for each
>>>>> new process ?
>>>>>
>>>>> I saw in http example that the endpoint was harcoded in the
>>>>> servicemix.xml file. Is there any other way to do that ?
>>>>>
>>>>> I am not sure to understand what is a 'lightweight' component. Can
>>>>> you explain me ?
>>>>>
>>>>> By now my BPEL engine sends WS calls. Is there any way to keep it
>>>>> unmodified and to configure servicemix to catch these calls and
>>>>> then send them through the NMR -> BC ?
>>>>> If it is possible, it means it is not mandatory for me to change
>>>>> my engine code and I will have the possibility to send calls to
>>>>> partner understanding only JMS for example...
>>>>>
>>>>> I know it is a lot of work for you to answer many questions but I
>>>>> am very interested in servicemix and I want to deploy my future
>>>>> Bpel Service Engine on it.
>>>>>
>>>>> Thanks for your answers
>>>>> Charles
>>>>>
>>>>>
>>>>> Guillaume Nodet wrote:
>>>>>
>>>>>> What kind of service engine do you want to implement ?
>>>>>> If you want a full jbi compliant SE, you should look at svn head
>>>>>> which contains a module named servicemix-common (see
>>>>>> http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-common/).
>>>>>>
>>>>>> This one contains abstract classes to ease the development of SE
>>>>>> and BC.
>>>>>> There is also a maven plugin to generate the installer.
>>>>>> Take a look at some of existing service engines
>>>>>> (servicemix-jsr181, servicemix-lwcontainer,
>>>>>> servicemix-wsn2005) or binding components (servicemix-http,
>>>>>> servicemix-jms).
>>>>>>
>>>>>> If you want a lightweight component, you can look at base classes
>>>>>> in servicemix-core, the
>>>>>> org.servicemix.components.util package contains lots of usefull
>>>>>> classes for lightweight components
>>>>>> (one endpoint, without any deployment). See
>>>>>> http://servicemix.org/POJO+support
>>>>>>
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>>
>>>>>> Charles Souillard wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I was able to create and launch some examples using servicemix
>>>>>>> components.
>>>>>>>
>>>>>>> Now, I want to create a new Service Engine and deploy it in
>>>>>>> servicemix.
>>>>>>> Does anybody knows where I can find a tutorial or some help ?
>>>>>>>
>>>>>>> I have already read the JBI spec. In addition I have downloaded
>>>>>>> the sun tutorial but it is an old one (written before the final
>>>>>>> release of JBI 1.0) and it needs some com.sun... classes.
>>>>>>>
>>>>>>> Thank you very much for your help !
>>>>>>> Regards,
>>>>>>> Charles
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Service Engine development
Posted by Charles Souillard <ch...@ext.bull.net>.
Guillaume,
I am trying to develop my SE based on the examples you gave me.
Can you tell me where I can find a description of what these component
are doing (their business logic) ?
This could help me understanding how I have to implement common classes
of SM for my case.
For example, my BPEL processes are using two kinds of xml files :
1) some WSDL files for the WS descriptions :
* at least one to expose the new BPEL process as a WebService
* optionnaly others to describe others WebServices that the BPEL
process will call (or receive a message from)
2) one BPEL file for the process description
Do you think my case could be closed to wsdl1 common package ?
There are many _functionnalities_ in a process life cycle :
1) *deploy the process* : it means creating a WS exposing the process to
make it available from anywhere in the world
By now, this step consist in deploying a WebService which will call
our BPEL engine. So when a WS call is received in the WS engine, the
implementation of this WS will call the BPEL engine with input datas.
2) *undeploy the process* : undeploy the WS
3) *call the process* (some application somewhere in the world wants to
launch a new instance of the process). That is for this functionnality
(and the next one) that we are actually interested in SM. What should be
very nice is that SM receive the call and give it through the NMR to the
BPEL engine (so I think I have to write a Service Engine to make it
possible, isn't it ?). In this case, the remote app could call the
process using BC available in SM (JMS or WS for example)
4) *call a remote WS from the process* : in a BPEL process, we can call
external WS. Here the needed functionnality is to give the call (a
Normalized Message I think) to SM which will send datas in the specific
protocol needed by the target partner. If a remote partner activated a
HelloWorld process by sending a JMS message, we have to send the
callback with output datas through a JMS message.
Please let me know if these functionnalities are available ?
Can you give me some guidelines to develop my own Service Engine to plug
my BPEL engine ?
Thanks a lot
Regards,
Charles
Guillaume Nodet wrote:
> To answer your question, implementing a component that accepts service
> units deployments
> involve a bit of coding :) The xbean and wsdl1 packages provides two
> examples of deployers
> that you can use if they fit your needs, but you can of course write
> your own. The first one
> uses an xbean/spring xml config file as a deployement, and the wsdl1
> accepts a wsdl file
> as a service unit.
>
> The components you have seen defines some classes, because each
> components processes
> things in a different way. The lwcontainer is quite simple : it has
> only 4 classes which are fairly
> simple. I do not really how you could handle service unit deployments
> in a simplier way ;)
> Could you please provide more informations of the kind of component
> you want to develop ?
> I may be able to provide you with more specific informations.
>
> Cheers,
> Guillaume Nodet
>
> Charles Souillard wrote:
>
>> Guillaume,
>>
>> I am trying to follow the instructions you gave me by implementing
>> Deployer class.
>>
>> I can see in service-common that there are two directories under
>> common : xbean and wsdl1.
>> What is the goal of these classes ?
>> servicemix-jsr181 and servicemix-lwcontainer are implementing
>> AbstractXBeanDeployer.
>> Which one do I have to implement ?
>> I can see that the examples you gave me (jsr181,lwcontainer...) have
>> a lot of other classes.
>> Why ?
>> Do I have to do the same ?
>>
>> Thanks,
>> Charles
>>
>> Guillaume Nodet wrote:
>>
>>> Your component will have to support deployment of service units.
>>> A service unit is a jar that will be exploded by ServiceMix and
>>> ServiceMix will give the path to the ServiceUnitManager interface
>>> implemented by your component.
>>>
>>> Most of the documentation on the wiki is currently focused on
>>> existing lightweight components : these components
>>> are, as you have noticed, hard wired with the servicemix.xml
>>> configuration file and, can activate only one endpoint
>>> and do not accept deployment.
>>> "Heavyweight components" can accept service unit deployments and can
>>> activate endpoints at runtime.
>>>
>>> If you use the servicemix-common project, you will have to implement
>>> a org.servicemix.common.Deployer
>>> interface specifically for your packaging model. This object create
>>> a org.servicemix.common.ServiceUnit object
>>> that contains several org.servicemix.common.Endpoint that will be
>>> responsible for creating according to the bpel process.
>>> Each endpoint will then be activated by the framework when the
>>> service unit is started. You will then be able
>>> to receive exchanges on this endpoint.
>>>
>>> Cheers,
>>> Guillaume Nodet
>>>
>>>
>>>
>>> Charles Souillard wrote:
>>>
>>>> Guillaume,
>>>> Thanks for your help, I will have a look.
>>>>
>>>> I have other questions...
>>>> My goal is to integrate my own BPEL engine (different from PXE).
>>>> For now, I only support WS calls and through servicemix I want to
>>>> be able to send/receive messages with different protocols.
>>>>
>>>> I want to be able to deploy new processes dynamically (without
>>>> shutting down servicemix).
>>>> How my new processes will be known by servicemix ?
>>>>
>>>> All examples are based on a specific 'servicemix.xml' file which is
>>>> couple to the example.
>>>> How can I start servicemix in a 'standard' way and then be able to
>>>> receive/send new messages from/to a new process ?
>>>> Do I have to create a new 'servicemix.xml' specific file for each
>>>> new process ?
>>>>
>>>> I saw in http example that the endpoint was harcoded in the
>>>> servicemix.xml file. Is there any other way to do that ?
>>>>
>>>> I am not sure to understand what is a 'lightweight' component. Can
>>>> you explain me ?
>>>>
>>>> By now my BPEL engine sends WS calls. Is there any way to keep it
>>>> unmodified and to configure servicemix to catch these calls and
>>>> then send them through the NMR -> BC ?
>>>> If it is possible, it means it is not mandatory for me to change my
>>>> engine code and I will have the possibility to send calls to
>>>> partner understanding only JMS for example...
>>>>
>>>> I know it is a lot of work for you to answer many questions but I
>>>> am very interested in servicemix and I want to deploy my future
>>>> Bpel Service Engine on it.
>>>>
>>>> Thanks for your answers
>>>> Charles
>>>>
>>>>
>>>> Guillaume Nodet wrote:
>>>>
>>>>> What kind of service engine do you want to implement ?
>>>>> If you want a full jbi compliant SE, you should look at svn head
>>>>> which contains a module named servicemix-common (see
>>>>> http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-common/).
>>>>>
>>>>> This one contains abstract classes to ease the development of SE
>>>>> and BC.
>>>>> There is also a maven plugin to generate the installer.
>>>>> Take a look at some of existing service engines
>>>>> (servicemix-jsr181, servicemix-lwcontainer,
>>>>> servicemix-wsn2005) or binding components (servicemix-http,
>>>>> servicemix-jms).
>>>>>
>>>>> If you want a lightweight component, you can look at base classes
>>>>> in servicemix-core, the
>>>>> org.servicemix.components.util package contains lots of usefull
>>>>> classes for lightweight components
>>>>> (one endpoint, without any deployment). See
>>>>> http://servicemix.org/POJO+support
>>>>>
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>>
>>>>> Charles Souillard wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I was able to create and launch some examples using servicemix
>>>>>> components.
>>>>>>
>>>>>> Now, I want to create a new Service Engine and deploy it in
>>>>>> servicemix.
>>>>>> Does anybody knows where I can find a tutorial or some help ?
>>>>>>
>>>>>> I have already read the JBI spec. In addition I have downloaded
>>>>>> the sun tutorial but it is an old one (written before the final
>>>>>> release of JBI 1.0) and it needs some com.sun... classes.
>>>>>>
>>>>>> Thank you very much for your help !
>>>>>> Regards,
>>>>>> Charles
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Service Engine development
Posted by Guillaume Nodet <gu...@worldonline.fr>.
To answer your question, implementing a component that accepts service
units deployments
involve a bit of coding :) The xbean and wsdl1 packages provides two
examples of deployers
that you can use if they fit your needs, but you can of course write
your own. The first one
uses an xbean/spring xml config file as a deployement, and the wsdl1
accepts a wsdl file
as a service unit.
The components you have seen defines some classes, because each
components processes
things in a different way. The lwcontainer is quite simple : it has
only 4 classes which are fairly
simple. I do not really how you could handle service unit deployments
in a simplier way ;)
Could you please provide more informations of the kind of component you
want to develop ?
I may be able to provide you with more specific informations.
Cheers,
Guillaume Nodet
Charles Souillard wrote:
> Guillaume,
>
> I am trying to follow the instructions you gave me by implementing
> Deployer class.
>
> I can see in service-common that there are two directories under
> common : xbean and wsdl1.
> What is the goal of these classes ?
> servicemix-jsr181 and servicemix-lwcontainer are implementing
> AbstractXBeanDeployer.
> Which one do I have to implement ?
> I can see that the examples you gave me (jsr181,lwcontainer...) have a
> lot of other classes.
> Why ?
> Do I have to do the same ?
>
> Thanks,
> Charles
>
> Guillaume Nodet wrote:
>
>> Your component will have to support deployment of service units.
>> A service unit is a jar that will be exploded by ServiceMix and
>> ServiceMix will give the path to the ServiceUnitManager interface
>> implemented by your component.
>>
>> Most of the documentation on the wiki is currently focused on
>> existing lightweight components : these components
>> are, as you have noticed, hard wired with the servicemix.xml
>> configuration file and, can activate only one endpoint
>> and do not accept deployment.
>> "Heavyweight components" can accept service unit deployments and can
>> activate endpoints at runtime.
>>
>> If you use the servicemix-common project, you will have to implement
>> a org.servicemix.common.Deployer
>> interface specifically for your packaging model. This object create
>> a org.servicemix.common.ServiceUnit object
>> that contains several org.servicemix.common.Endpoint that will be
>> responsible for creating according to the bpel process.
>> Each endpoint will then be activated by the framework when the
>> service unit is started. You will then be able
>> to receive exchanges on this endpoint.
>>
>> Cheers,
>> Guillaume Nodet
>>
>>
>>
>> Charles Souillard wrote:
>>
>>> Guillaume,
>>> Thanks for your help, I will have a look.
>>>
>>> I have other questions...
>>> My goal is to integrate my own BPEL engine (different from PXE).
>>> For now, I only support WS calls and through servicemix I want to be
>>> able to send/receive messages with different protocols.
>>>
>>> I want to be able to deploy new processes dynamically (without
>>> shutting down servicemix).
>>> How my new processes will be known by servicemix ?
>>>
>>> All examples are based on a specific 'servicemix.xml' file which is
>>> couple to the example.
>>> How can I start servicemix in a 'standard' way and then be able to
>>> receive/send new messages from/to a new process ?
>>> Do I have to create a new 'servicemix.xml' specific file for each
>>> new process ?
>>>
>>> I saw in http example that the endpoint was harcoded in the
>>> servicemix.xml file. Is there any other way to do that ?
>>>
>>> I am not sure to understand what is a 'lightweight' component. Can
>>> you explain me ?
>>>
>>> By now my BPEL engine sends WS calls. Is there any way to keep it
>>> unmodified and to configure servicemix to catch these calls and then
>>> send them through the NMR -> BC ?
>>> If it is possible, it means it is not mandatory for me to change my
>>> engine code and I will have the possibility to send calls to partner
>>> understanding only JMS for example...
>>>
>>> I know it is a lot of work for you to answer many questions but I am
>>> very interested in servicemix and I want to deploy my future Bpel
>>> Service Engine on it.
>>>
>>> Thanks for your answers
>>> Charles
>>>
>>>
>>> Guillaume Nodet wrote:
>>>
>>>> What kind of service engine do you want to implement ?
>>>> If you want a full jbi compliant SE, you should look at svn head
>>>> which contains a module named servicemix-common (see
>>>> http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-common/).
>>>>
>>>> This one contains abstract classes to ease the development of SE
>>>> and BC.
>>>> There is also a maven plugin to generate the installer.
>>>> Take a look at some of existing service engines (servicemix-jsr181,
>>>> servicemix-lwcontainer,
>>>> servicemix-wsn2005) or binding components (servicemix-http,
>>>> servicemix-jms).
>>>>
>>>> If you want a lightweight component, you can look at base classes
>>>> in servicemix-core, the
>>>> org.servicemix.components.util package contains lots of usefull
>>>> classes for lightweight components
>>>> (one endpoint, without any deployment). See
>>>> http://servicemix.org/POJO+support
>>>>
>>>> Cheers,
>>>> Guillaume Nodet
>>>>
>>>> Charles Souillard wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I was able to create and launch some examples using servicemix
>>>>> components.
>>>>>
>>>>> Now, I want to create a new Service Engine and deploy it in
>>>>> servicemix.
>>>>> Does anybody knows where I can find a tutorial or some help ?
>>>>>
>>>>> I have already read the JBI spec. In addition I have downloaded
>>>>> the sun tutorial but it is an old one (written before the final
>>>>> release of JBI 1.0) and it needs some com.sun... classes.
>>>>>
>>>>> Thank you very much for your help !
>>>>> Regards,
>>>>> Charles
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Service Engine development
Posted by Charles Souillard <ch...@ext.bull.net>.
Guillaume,
I am trying to follow the instructions you gave me by implementing
Deployer class.
I can see in service-common that there are two directories under common
: xbean and wsdl1.
What is the goal of these classes ?
servicemix-jsr181 and servicemix-lwcontainer are implementing
AbstractXBeanDeployer.
Which one do I have to implement ?
I can see that the examples you gave me (jsr181,lwcontainer...) have a
lot of other classes.
Why ?
Do I have to do the same ?
Thanks,
Charles
Guillaume Nodet wrote:
> Your component will have to support deployment of service units.
> A service unit is a jar that will be exploded by ServiceMix and
> ServiceMix will give the path to the ServiceUnitManager interface
> implemented by your component.
>
> Most of the documentation on the wiki is currently focused on existing
> lightweight components : these components
> are, as you have noticed, hard wired with the servicemix.xml
> configuration file and, can activate only one endpoint
> and do not accept deployment.
> "Heavyweight components" can accept service unit deployments and can
> activate endpoints at runtime.
>
> If you use the servicemix-common project, you will have to implement a
> org.servicemix.common.Deployer
> interface specifically for your packaging model. This object create a
> org.servicemix.common.ServiceUnit object
> that contains several org.servicemix.common.Endpoint that will be
> responsible for creating according to the bpel process.
> Each endpoint will then be activated by the framework when the service
> unit is started. You will then be able
> to receive exchanges on this endpoint.
>
> Cheers,
> Guillaume Nodet
>
>
>
> Charles Souillard wrote:
>
>> Guillaume,
>> Thanks for your help, I will have a look.
>>
>> I have other questions...
>> My goal is to integrate my own BPEL engine (different from PXE).
>> For now, I only support WS calls and through servicemix I want to be
>> able to send/receive messages with different protocols.
>>
>> I want to be able to deploy new processes dynamically (without
>> shutting down servicemix).
>> How my new processes will be known by servicemix ?
>>
>> All examples are based on a specific 'servicemix.xml' file which is
>> couple to the example.
>> How can I start servicemix in a 'standard' way and then be able to
>> receive/send new messages from/to a new process ?
>> Do I have to create a new 'servicemix.xml' specific file for each new
>> process ?
>>
>> I saw in http example that the endpoint was harcoded in the
>> servicemix.xml file. Is there any other way to do that ?
>>
>> I am not sure to understand what is a 'lightweight' component. Can
>> you explain me ?
>>
>> By now my BPEL engine sends WS calls. Is there any way to keep it
>> unmodified and to configure servicemix to catch these calls and then
>> send them through the NMR -> BC ?
>> If it is possible, it means it is not mandatory for me to change my
>> engine code and I will have the possibility to send calls to partner
>> understanding only JMS for example...
>>
>> I know it is a lot of work for you to answer many questions but I am
>> very interested in servicemix and I want to deploy my future Bpel
>> Service Engine on it.
>>
>> Thanks for your answers
>> Charles
>>
>>
>> Guillaume Nodet wrote:
>>
>>> What kind of service engine do you want to implement ?
>>> If you want a full jbi compliant SE, you should look at svn head
>>> which contains a module named servicemix-common (see
>>> http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-common/).
>>>
>>> This one contains abstract classes to ease the development of SE and
>>> BC.
>>> There is also a maven plugin to generate the installer.
>>> Take a look at some of existing service engines (servicemix-jsr181,
>>> servicemix-lwcontainer,
>>> servicemix-wsn2005) or binding components (servicemix-http,
>>> servicemix-jms).
>>>
>>> If you want a lightweight component, you can look at base classes in
>>> servicemix-core, the
>>> org.servicemix.components.util package contains lots of usefull
>>> classes for lightweight components
>>> (one endpoint, without any deployment). See
>>> http://servicemix.org/POJO+support
>>>
>>> Cheers,
>>> Guillaume Nodet
>>>
>>> Charles Souillard wrote:
>>>
>>>> Hi all,
>>>>
>>>> I was able to create and launch some examples using servicemix
>>>> components.
>>>>
>>>> Now, I want to create a new Service Engine and deploy it in
>>>> servicemix.
>>>> Does anybody knows where I can find a tutorial or some help ?
>>>>
>>>> I have already read the JBI spec. In addition I have downloaded the
>>>> sun tutorial but it is an old one (written before the final release
>>>> of JBI 1.0) and it needs some com.sun... classes.
>>>>
>>>> Thank you very much for your help !
>>>> Regards,
>>>> Charles
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Service Engine development
Posted by Guillaume Nodet <gu...@worldonline.fr>.
Your component will have to support deployment of service units.
A service unit is a jar that will be exploded by ServiceMix and
ServiceMix will give the path to the ServiceUnitManager interface
implemented by your component.
Most of the documentation on the wiki is currently focused on existing
lightweight components : these components
are, as you have noticed, hard wired with the servicemix.xml
configuration file and, can activate only one endpoint
and do not accept deployment.
"Heavyweight components" can accept service unit deployments and can
activate endpoints at runtime.
If you use the servicemix-common project, you will have to implement a
org.servicemix.common.Deployer
interface specifically for your packaging model. This object create a
org.servicemix.common.ServiceUnit object
that contains several org.servicemix.common.Endpoint that will be
responsible for creating according to the bpel process.
Each endpoint will then be activated by the framework when the service
unit is started. You will then be able
to receive exchanges on this endpoint.
Cheers,
Guillaume Nodet
Charles Souillard wrote:
> Guillaume,
> Thanks for your help, I will have a look.
>
> I have other questions...
> My goal is to integrate my own BPEL engine (different from PXE).
> For now, I only support WS calls and through servicemix I want to be
> able to send/receive messages with different protocols.
>
> I want to be able to deploy new processes dynamically (without
> shutting down servicemix).
> How my new processes will be known by servicemix ?
>
> All examples are based on a specific 'servicemix.xml' file which is
> couple to the example.
> How can I start servicemix in a 'standard' way and then be able to
> receive/send new messages from/to a new process ?
> Do I have to create a new 'servicemix.xml' specific file for each new
> process ?
>
> I saw in http example that the endpoint was harcoded in the
> servicemix.xml file. Is there any other way to do that ?
>
> I am not sure to understand what is a 'lightweight' component. Can you
> explain me ?
>
> By now my BPEL engine sends WS calls. Is there any way to keep it
> unmodified and to configure servicemix to catch these calls and then
> send them through the NMR -> BC ?
> If it is possible, it means it is not mandatory for me to change my
> engine code and I will have the possibility to send calls to partner
> understanding only JMS for example...
>
> I know it is a lot of work for you to answer many questions but I am
> very interested in servicemix and I want to deploy my future Bpel
> Service Engine on it.
>
> Thanks for your answers
> Charles
>
>
> Guillaume Nodet wrote:
>
>> What kind of service engine do you want to implement ?
>> If you want a full jbi compliant SE, you should look at svn head
>> which contains a module named servicemix-common (see
>> http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-common/).
>>
>> This one contains abstract classes to ease the development of SE and BC.
>> There is also a maven plugin to generate the installer.
>> Take a look at some of existing service engines (servicemix-jsr181,
>> servicemix-lwcontainer,
>> servicemix-wsn2005) or binding components (servicemix-http,
>> servicemix-jms).
>>
>> If you want a lightweight component, you can look at base classes in
>> servicemix-core, the
>> org.servicemix.components.util package contains lots of usefull
>> classes for lightweight components
>> (one endpoint, without any deployment). See
>> http://servicemix.org/POJO+support
>>
>> Cheers,
>> Guillaume Nodet
>>
>> Charles Souillard wrote:
>>
>>> Hi all,
>>>
>>> I was able to create and launch some examples using servicemix
>>> components.
>>>
>>> Now, I want to create a new Service Engine and deploy it in servicemix.
>>> Does anybody knows where I can find a tutorial or some help ?
>>>
>>> I have already read the JBI spec. In addition I have downloaded the
>>> sun tutorial but it is an old one (written before the final release
>>> of JBI 1.0) and it needs some com.sun... classes.
>>>
>>> Thank you very much for your help !
>>> Regards,
>>> Charles
>>>
>>>
>>>
>>>
>>
>>
>
>
Re: Service Engine development
Posted by Charles Souillard <ch...@ext.bull.net>.
Guillaume,
Thanks for your help, I will have a look.
I have other questions...
My goal is to integrate my own BPEL engine (different from PXE).
For now, I only support WS calls and through servicemix I want to be
able to send/receive messages with different protocols.
I want to be able to deploy new processes dynamically (without shutting
down servicemix).
How my new processes will be known by servicemix ?
All examples are based on a specific 'servicemix.xml' file which is
couple to the example.
How can I start servicemix in a 'standard' way and then be able to
receive/send new messages from/to a new process ?
Do I have to create a new 'servicemix.xml' specific file for each new
process ?
I saw in http example that the endpoint was harcoded in the
servicemix.xml file. Is there any other way to do that ?
I am not sure to understand what is a 'lightweight' component. Can you
explain me ?
By now my BPEL engine sends WS calls. Is there any way to keep it
unmodified and to configure servicemix to catch these calls and then
send them through the NMR -> BC ?
If it is possible, it means it is not mandatory for me to change my
engine code and I will have the possibility to send calls to partner
understanding only JMS for example...
I know it is a lot of work for you to answer many questions but I am
very interested in servicemix and I want to deploy my future Bpel
Service Engine on it.
Thanks for your answers
Charles
Guillaume Nodet wrote:
> What kind of service engine do you want to implement ?
> If you want a full jbi compliant SE, you should look at svn head
> which contains a module named servicemix-common (see
> http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-common/).
>
> This one contains abstract classes to ease the development of SE and BC.
> There is also a maven plugin to generate the installer.
> Take a look at some of existing service engines (servicemix-jsr181,
> servicemix-lwcontainer,
> servicemix-wsn2005) or binding components (servicemix-http,
> servicemix-jms).
>
> If you want a lightweight component, you can look at base classes in
> servicemix-core, the
> org.servicemix.components.util package contains lots of usefull
> classes for lightweight components
> (one endpoint, without any deployment). See
> http://servicemix.org/POJO+support
>
> Cheers,
> Guillaume Nodet
>
> Charles Souillard wrote:
>
>> Hi all,
>>
>> I was able to create and launch some examples using servicemix
>> components.
>>
>> Now, I want to create a new Service Engine and deploy it in servicemix.
>> Does anybody knows where I can find a tutorial or some help ?
>>
>> I have already read the JBI spec. In addition I have downloaded the
>> sun tutorial but it is an old one (written before the final release
>> of JBI 1.0) and it needs some com.sun... classes.
>>
>> Thank you very much for your help !
>> Regards,
>> Charles
>>
>>
>>
>>
>
>
Re: Service Engine development
Posted by Guillaume Nodet <gu...@worldonline.fr>.
What kind of service engine do you want to implement ?
If you want a full jbi compliant SE, you should look at svn head
which contains a module named servicemix-common (see
http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-common/).
This one contains abstract classes to ease the development of SE and BC.
There is also a maven plugin to generate the installer.
Take a look at some of existing service engines (servicemix-jsr181,
servicemix-lwcontainer,
servicemix-wsn2005) or binding components (servicemix-http, servicemix-jms).
If you want a lightweight component, you can look at base classes in
servicemix-core, the
org.servicemix.components.util package contains lots of usefull classes
for lightweight components
(one endpoint, without any deployment). See
http://servicemix.org/POJO+support
Cheers,
Guillaume Nodet
Charles Souillard wrote:
> Hi all,
>
> I was able to create and launch some examples using servicemix
> components.
>
> Now, I want to create a new Service Engine and deploy it in servicemix.
> Does anybody knows where I can find a tutorial or some help ?
>
> I have already read the JBI spec. In addition I have downloaded the
> sun tutorial but it is an old one (written before the final release of
> JBI 1.0) and it needs some com.sun... classes.
>
> Thank you very much for your help !
> Regards,
> Charles
>
>
>
>