WS EJB invocation

[heiko.braun]

Web service invocations have been done by locating the ejb container and executing #localInvoke(...) on it.

We used to locate the container by object name:

kernel.getInstalledContext( objectName.getCanonicalName() )

With the latest codebase I see that the objectname for a simple jar deployment changed from

jboss.j2ee:name=Ejb3WSEndpointImpl,service=EJB3,jar=webservices-ejb3.jar

to

jboss.j2ee:ear=webservices-ejb3.jar,jar=webservices-ejb3.jar,name=Ejb3WSEndpointImpl,service=EJB3

which used to be the case when an ejb.jar was deployed inside an ear.

I am currently wondering

- why that changed (bug?)
- and if there is better way to do this at all.

[heiko.braun]

I don't know why, but for some reason the Ejb3Deployment of a jar seems to pretend a parent ear scope.

[starksm64]

It changed because the DeploymentScope is now handling the resolution of references to other components, so there is always a DeploymentScope. Previously this only existed for ears. Use the DeploymentScope getEjbContainer methods to obtain the container:

public interface DeploymentScope extends JavaEEApplication
{
 /**
 * Obtain the EJBContainer best matching the business interface
 * @param businessIntf - the business interface to match
 * @param vfsContext - the vfs path to the deploment initiating the request
 * @return the matching EJBContainer if found, null otherwise.
 */
 EJBContainer getEjbContainer(Class businessIntf, String vfsContext)
 throws NameNotFoundException;
 /**
 * Obtain the EJBContainer best matching the business interface
 * @param ejbLink - the referencing ejb-link
 * @param businessIntf - the business interface to match
 * @param vfsContext - the vfs path to the deploment initiating the request
 * @return the matching EJBContainer if found, null otherwise.
 */
 EJBContainer getEjbContainer(String ejbLink, Class businessIntf, String vfsContext);

}

[wolfc]

It's weird to have the jar (JavaEEModule) acts as a JavaEEApplication.

Anyway the WS endpoint does not have a relation with a business interface, so it needs to get the object name from somewhere. Maybe we should add this to the metadata?

In future (EJB 3.1) the WS endpoint should invoke the no-interface view.

[heiko.braun]

For me the easiest would be to publish the ObjectName with DeploymentUnit attachments using a fixed property name that's part of the WS SPI.

[heiko.braun]

Please forget my last comment ;)

[heiko.braun]

Looking closer makes me think that the best place would be JBossEnterpriseBeanMetaData.

[starksm64]

"wolfc" wrote:
It's weird to have the jar (JavaEEModule) acts as a JavaEEApplication.

Anyway the WS endpoint does not have a relation with a business interface, so it needs to get the object name from somewhere. Maybe we should add this to the metadata?

In future (EJB 3.1) the WS endpoint should invoke the no-interface view.

Resolution is required regardless of the structure.

[starksm64]

For me the easiest would be to publish the ObjectName with DeploymentUnit attachments using a fixed property name that's part of the WS SPI.

...
Looking closer makes me think that the best place would be JBossEnterpriseBeanMetaData.

Using an ObjectName certainly makes no sense. We don't even know if there is going to be a jmx view in the future. Its certainly not the api for invoking on the container.

Identifying the endpoints at the JBossEnterpriseBeanMetaData and on the servlet side, the JBossWebMetaData/JBossServletMetaData is what makes sense.

You would still need an api to get hold of the container to invoke on for the given ejb-name, servlet-name though. The DeploymentScope.getEjbContainer(String ejbLink, Class businessIntf, String vfsContext) works for the ejb-name. The businessIntf is just for fallback if known, but is not needed.

We can just add a method DeploymentScope.getEjbContainer(String containerName) and make the container name come from the getContainerName/setContainerName on the JBossEnterpriseBeanMetaData.

[heiko.braun]

You would still need an api to get hold of the container to invoke on

Currently we use the MC kernel todo a lookup by name, which uses the legacy ObjectName.

DeploymentScope.getEjbContainer(String ejbLink, Class businessIntf, String vfsContext) works for the ejb-name.

Does this mean I can simply use the ejb-name for ejb-link and thus resolve the corresponding container? If that's the case, then I am all set.

[heiko.braun]

Regarding the legacy ObjectName: To the WS contract it doesn't actually matter what property is being used to identify the ejb container to drive subsequent invocations. We just need a stable property that derives from the ejb3 meta data.

[starksm64]

Currently we use the MC kernel todo a lookup by name, which uses the legacy ObjectName.

Ok, are we comfortable as that as the lookup mechanism? We can make sure its available on the JBossEnterpriseBeanMetaData.

DeploymentScope.getEjbContainer(String ejbLink, Class businessIntf, String vfsContext) works for the ejb-name.

Does this mean I can simply use the ejb-name for ejb-link and thus resolve the corresponding container? If that's the case, then I am all set.

That is what could be used now, but the problem with resolving the name is that its not unique. If for a given ejb deployment, you use its local ejb-names this will just work.

What I also proposed was ensuring the container name was made available on the JBossEnterpriseBeanMetaData, and DeploymentScope would support lookup of the EJBContainer by that name.

[heiko.braun]

That is what could be used now, but the problem with resolving the name is that its not unique. If for a given ejb deployment, you use its local ejb-names this will just work.

Right, but that unit of work happens inside a deployer anyway. So it's scoped to a particular deployment.

ensuring the container name was made available on the JBossEnterpriseBeanMetaData,

Yes, that was my first idea as well. In the beginning i was thinking that a indirect reference to the container using a lookup might be better way then picking the container at deploy time and associating it with the web service meta data. However, both the ejb and the web service deployer are chained anyway, so we shouldn't run into trouble here.

Or do you see a technical reason to prefer invocation by lookup over direct association in this case?

However, I will evaluate the later option today and let you know how it goes.

[heiko.braun]

OK, looking at the second option and talking to Carlo we agreed that invocation through the MC lookup makes more sense. We get into all kinds of additional questions otherwise. One of the reasons why I started looking into this, was that we needed to get rid of Ejb3Deployment (or the dependency on it). If we add the container name to the meta data it would leave the WS deployer with a dependency on meta data and the WS SPI. Which seems pretty straight forward.

Scott, can add it to JBossEnterpriseBeanMetaData?

[starksm64]

Yes, I'll do it today and update the JBossASKernel integration to use it.

http://jira.jboss.com/jira/browse/JBMETA-32