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
