ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Boisvert" <boisv...@intalio.com>
Subject Re: Axis2 Integration
Date Tue, 18 Sep 2007 19:46:54 GMT
On 9/14/07, Thilina Gunarathne <csethil@gmail.com> wrote:
> > So basically the WAR version of ODE is packaged inside Axis2, so almost
> > everything that holds for a classic Axis2 deployment still holds (minor
> a
> > couple of things specific to our configuration like the services URL
> space
> > or ws-addressing).
> Just for my info: Are you all are using the new Axis2 pluggable deployer
> model ?

No, I was not aware of it.  Do you have any pointers about this?

>The integration itself is pretty simple, we just create
> > services into Axis2 and use the receiver to get messages and forward
> them to
> > our infrastructure. However everything is programmatic as we need a
> dynamic
> > behavior (if you hot-deploy a process, the service gets created, if you
> > undeploy the service is removed) as Alex mentioned. So we had to let go
> of
> > the Axis2 static service configuration (i.e. the configuration files) to
> > provide that dynamicity.
> Fair enough.. But is there a configuration file for the BPEL process?
> If there is one we can use it to configure the service upfront.
> I can see a axis2.xml under the WEB-INF/conf/ folder. Does ODE use
> it?.. I'm going to try engaging a module globally using that axis2.xml
> and see how it'll go.

The configuration file for the BPEL process is deploy.xml.  Right now it
simply binds partnerLinks to WSDL endpoints.

I believe engaging a module globally should work.

>  * One possibility could be to allow the inclusion of a service.xml in a
> > process deployment and have ODE feed that into Axis2 when it creates the
> > service for a process.
> May be we can reuse a ODE process configuration file (if there is
> any).. AFAIKS only a subset of the things which we can configure in
> the services.xml will be usefull in ODE.
> I think providing the ability to engage a axis2 module's for the
> processes service interface will gain a lot for ODE. It would be
> really nice if we can engage Rampart module and secure a process
> endpoint, even though I'm not sure whether that kind  of use cases
> actually exists.

I definitely agree.  We should be able to leverage Axis2's configurability
and extra features on a per-endpoint basis.

> If you want to get familiar with our integration, the easiest way for now
> is
> > to look at the source. A service gets registered using the
> ODEAxisService
> > [1]. Messages are sent using ExternalService[2] and received using our
> > message receiver [3]. We could work out something by adding a method in
> > ProcessConf (passed to createService in [1]) to access the deployed
> > service.xml.
> In the ExternalService[1] I found the following lines...
>             if (cached == null || cached._expire < now) {
>                 cached = new CachedServiceClient();
>                 ConfigurationContext ctx = new
> ConfigurationContext(_axisConfig);
> Wonder whether you considered using the same configuration context of
> the server for the above client invocations rather than creating new
> configuration contexts for each and every client..
> If we used the same config context, then in my use case I can put the
> received headers in to the property bag of the config context and then
> retrieve them in the out path. I know configContext is not the right
> point to put them, but at least I can do that for the moment.

The above hack was to improve performance while retaining (limited) dynamic
configuration. Yes, if it's possible, I think we should reuse the
ConfigurationContext.  I think it's just our (mis)understanding of Axis2's
architecture that is showing here.  We should spend some time to review this
and ask you question so we get a clearer picture.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message