geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <guillaume.no...@worldonline.fr>
Subject Re: ServiceMix integration
Date Tue, 04 Apr 2006 16:20:56 GMT
Thanks Aaron, see comments inline...

Aaron Mulder wrote:

>Guillaume,
>
>You're right that there's generally no server-wide JNDI context.  It's
>possible to look up any resource in the server at runtime using
>Geronimo-specific APIs (such as Kernel.listGBeans, or using the JSR-77
>management APIs).  For J2EE apps, the standard practice leans towards
>binding everything at deployment time, so we have a deployment
>descriptor that maps the declared resources to actual resources in the
>server during deployment.  Then we create the component-specific JNDI
>space during deployment containing the resources to be made avaliable
>to the component, because that's what J2EE dictates.  But it's not the
>only possible way things could work.
>  
>
Thanks for these precisions.  It confirms what i was thinking by looking 
at the code.

>I'm having trouble wrapping my head around how resources should
>normally work in ServiceMix.  Is there some place in jbi.xml or other
>standard JBI deployment information for, say, a service unit to
>declare that it needs resources like a JMS connection factory and
>destination?  If not, how is ServiceMix/Geronimo supposed to know what
>resources to provide?  Is there just an assumption that a global JNDI
>namespace will be present containing every resource in the server and
>each component can look up whatever it wants to?
>  
>
The only relationship between JBI and JNDI is that the JBI container 
should provide an InitialContext for a JBI component.
See 
http://java.sun.com/integration/1.0/docs/sdk/api/javax/jbi/component/ComponentContext.html
In addition to the JNDI context, a MBeanServer and a TransactionManager 
should be provided.  These are really the only links between JBI and J2EE.
However, the purpose of JBI is to integrate things, so I guess accessing 
JMS resources, EJBs or JDBC datasources ia a must.
Let's take a real example: the BPE BPEL engine (in incubating ODE apache 
project) uses EJB as a persistence mechanism (the current JBI component 
for BPE only uses memory persistence), so the BPEL engine itself has to 
be deployed in Geronimo.  Then the JBI component would need to lookup 
and call these EJB to actually perform the work. 

The questions you are asking are really the ones for which i look 
answers.  I have no real idea what is the best way.  The only thing I 
know is that the JBI spec does not define anything on that.  I was 
thinking of creating a geronimo-jbi.xml deployment plan where JNDI 
resources would be specified and where gbeans could be added.  I guess 
this is the only solution to work around the problem that there is no 
global JNDI context.

In addition, if we take the ODE-BPE engine, I think that the EJB jar and 
the JBI component could be deployed inside the same EAR.  This means 
that the J2EE deployer should be enhanced to support JBI modules.  
Obviously, this is not supported by the J2EE specs, and as djencks said, 
this need to be tuned off if needed.
(Though if the JBI container configuration is stopped, I think this will 
be automatic).

I 'm really looking for feedback on this as I am not not a J2EE expert, 
nor a Geronimo expert ...

Cheers,
Guillaume Nodet

>Thanks,
>    Aaron
>
>On 4/4/06, Guillaume Nodet <guillaume.nodet@worldonline.fr> wrote:
>  
>
>>Thanks to dain and djencks advises, I have began to write a real
>>ServiceMix integration for Geronimo.
>>However I am facing a number of problems.
>>
>>The problem is that the JBI spec needs some things to be done when
>>undeploying jbi artifacts so I will be in need of an event fired before
>>undeployment (and not after as this is the current case).  Let me
>>explain the use case for this.
>>The JBI container is a server (like a web server or EJB server): it
>>accepts three kind of deployment artifacts: component, shared libraries
>>and service assemblies.  A shared library is a collection of jars to be
>>added to the classpath of a component.  A component is also a container,
>>like a BPEL engine for example.  A service assembly is a package
>>containing service units.  These service units are given to a target
>>component upon deployment.  A service unit could a BPEL process.
>>When deploying a BPEL process onto a BPEL engine, the engine may have to
>>store the process in a database at deployment time and remove the clean
>>the database when undeploying the service unit.  The JBI spec has all
>>the needed interfaces to perform these deployment / undeployment steps.
>>The only problem is that I have not found any way to know when a
>>configuration is being undeployed.
>>Looking at the kernel, it seems it should be quite easy to do, so I
>>think I will raise a JIRA for that and attach a patch at a later time.
>>
>>The next problem, which is IMHO more important, is how to access managed
>>resources.  In the previous BPEL engine example, the component has to
>>access a database.  A JMS component would access a JMS connection
>>factory.  These resources should be accessed via JNDI.  I have browsed
>>the naming / deployer code these past days and AFAIK, there is no
>>server-wide JNDI context.  When a web app is deployed, a specific JNDI
>>context is created (and bound to the thread with interceptors), that
>>includes all the bindings referenced in the web deployment descriptor.
>>This leads me to think that I have to create a geronimo-jbi.xml
>>deployment descriptor which will contain resource references and / or
>>additional gbeans for the configuration.
>>I fear this will lead to another problem, which is the fact that these
>>resources are usually deployed inside an EAR and JBI artifacts can not...
>>So the main questions is: did I miss something ? Is there any easier way
>>to access server-wide resources or do I really have to create a specific
>>deployment plan of some kind ?
>>
>>Cheers,
>>Guillaume Nodet
>>
>>
>>
>>    
>>
>
>
>  
>

Mime
View raw message