geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: ServiceMix integration
Date Tue, 04 Apr 2006 22:09:06 GMT
It appears that the JBI spec didn't provide any way to normalize the  
JNDI environment between different app servers (JBI 1.0 page 241):

   public javax.naming.InitialContext getNamingContext()
   Get the JNDI naming context for this component. This context is a  
standard JNDI InitialContext but
   its content will vary based based on the environment in which the  
JBI implementation is running.
   Returns: the JNDI naming context; must be non-null.

Rather than try to shoehorn ServiceMix into a Geronimo paradigm,  
Guillaume how do you want this to work in Geronimo?

Based on the number of requests for a global JNDI, I think we need to  
finally implement it regardless of how distasteful some may find it.   
Of course, I'd schedule it for Geronimo 1.2 :)


On Apr 4, 2006, at 9:46 AM, Aaron Mulder wrote:

> I guess I'm wondering how this will work with other app servers, and
> how portable the code will be.  Let's say you're trying to deploy the
> same EJB+JBI configuration in ServiceMix+Geronimo and also
> ServiceMix+App Server X where that product supports a global JNDI
> space.
> Will the code look like this?
> SomeEJBHome home = null;
> if(amIinGeronimo()) {
>     // Geronimo uses local JNDI space with mapping file
>     home = new InitialContext().lookup("java:comp/env/ejb/SomeEJB");
> } else if(amIinAppServerX()) {
>     // App Server X uses global JNDI space
>     home = new InitialContext().lookup("ejb/SomeEJB");
> } else ...
> Or would you plan to have geronimo-jbi.xml and also appserverx-jbi.xml
> so that the code could be the same for both
> ("java:comp/env/ejb/SomeEJB") and it would just be the mapping
> strategy that was different depending on which product you were
> deploying in?
> I think it would be "more portable" to have the code always use the
> local JNDI space and assume that each app server will have their own
> way to write a mapping file (product-jbi.xml or whatever) to force
> something into a local JNDI space accessible to the JBI components.
> This way the code wouldn't be different for different servers, only
> the config files.  However, 1) that requires you always write a
> mapping file and 2) we have no proof that any other app server would
> allow a local JNDI space for JBI components...
> It seems like a bit of a dilemma.  I'm comfortable going with a
> geronimo-jbi.xml strategy if you are.
> If we wanted to minimize mapping requirements, we could try to do
> something like map all EJBs in the same EAR into the local JNDI space
> of the JBI component by default, though the auto-generated names might
> be a bit ugly (java:comp/env/name-of-ejb-jar-in-ear/name-of-ejb-in- 
> ejb-jar).
>  Then you'd only need to provide manual mapping for any EJBs in a
> different EAR.  I'm not sure how easy this would be to implement (in
> particular, I think it would be hard if we couldn't force the EJB
> deployer to run before the JBI deployer), but we might as well think
> about what we'd like to see and then we can figure out how easy it is
> to do it.  :)
> Another related question I have is, will you be able to deploy both
> JBI components (containers, such as a BPEL engine) and also JBI
> service units (things to deploy into those JBI components, such as a
> specific BPEL process) using the Geronimo deployer infrastructure?  I
> think I understand deploying Service Units (in a Service Assembly zip)
> but I don't understand what a JBI component deployment looks like
> (other than it's a JAR).  Will both of these require resource mapping,
> or will it only be the service units that need specific resources?
> That is, will it be the case that you give the BPEL Engine a database
> to save its state to for all its processes, or will you only give each
> BPEL Business Process a database that the engine should save its state
> to?
> Thanks,
>     Aaron
> P.S. I'd also like to have a way to automatically connect Session EJBs
> to the JBI bus if they define a WSDL interface.  But this is a
> different issue.  :)
> On 4/4/06, Guillaume Nodet <> wrote:
>> 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
>> 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 <> 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

View raw message