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):
getNamingContext()
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 :)
-dain
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 <guillaume.nodet@worldonline.fr> 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
>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
|