Thoughts on ws integration

[asoldano]

Hi,

I've been reasoning a bit on what will need to be done to add ws functionalities to AS 7. While the final work will need to wait for the ejb3 subsystem to be available, the current web subsystem should be enough for a limited support (POJO endpoints only), hence for starting looking at the integration.

The domain model additions due to the ws subsystem should be quite trivial; first questions/doubts come when dealing with the deployment instead. As far as I can see, other subsystems define activators that create deployment chains; each of them come with its chain selector and given set of processors that actually deal with the deployment. Selectors seems to trigger the chain processing depending on the kind of the deployment (a war, jar, sar, etc.), or more generally speaking on basic reasoning over the deployment package (name of the virtual file, manifest contents, etc.).

A selector can't be easily defined for detecting "ws deployments" as of course a webservice endpoint could be part of a web deployment or of an ejb deployment.

In AS 5/6 the ws deployers (let's talk about the REAL ones only here) were basically running in between the ejb/web ones, properly modifying (or creating in the case of ejb3 ws deployments) the JBossWebMetaData that was later consumed by the TomcatDeployer.

With the current AS7 architecture, we'd probably need integration hooks for interleaving the ws processors with the web ones. Of course having the web subsystem directly depend on anything in the ws one is not acceptable.

The alternative -defining a new chain for the ws deployment and calling the required web processors in there- is most probably not going to work.

What options do you see here?

[wolfc]

Can you also outline in this thread what exactly you require out of EJB 3?

It's probably a list of interfaces which need to be implemented there, not?

[thomas.diesler]

Alessio,

in future we are probably going to see less deployment chains, possibly just one. The web subsystem could be enabled to setup endpoints based metadata that you attach to the DeploymentUnitContext. A (better) alternative would be that the WS DUP registers a WSService that has a dependency on some JBossWebService. When the WSService activates it uses well defined/stable API from the JBossWebService to setup a web endpoint.

IMHO, this is generally needed because other subsystems like the OSGi HttpService may also need to setup Http endpoints through API. Perhaps you can use

[JBOSGI-308] Implement the HttpService ontop of JBossWeb

as the entry point to this discussion. In short, JBossWeb would need to expose a set of well defined services that allows others to setup endpoints.

[dmlloyd]

Alessio Soldano wrote:

[...]

The domain model additions due to the ws subsystem should be quite trivial; first questions/doubts come when dealing with the deployment instead. As far as I can see, other subsystems define activators that create deployment chains; each of them come with its chain selector and given set of processors that actually deal with the deployment. Selectors seems to trigger the chain processing depending on the kind of the deployment (a war, jar, sar, etc.), or more generally speaking on basic reasoning over the deployment package (name of the virtual file, manifest contents, etc.).

This needs to change in my opinion.  We need to convert to a single deployment unit processing chain, where each processor is responsible for detecting whether it applies to the processed deployment.

Alessio Soldano wrote:

In AS 5/6 the ws deployers (let's talk about the REAL ones only here) were basically running in between the ejb/web ones, properly modifying (or creating in the case of ejb3 ws deployments) the JBossWebMetaData that was later consumed by the TomcatDeployer.

With the current AS7 architecture, we'd probably need integration hooks for interleaving the ws processors with the web ones. Of course having the web subsystem directly depend on anything in the ws one is not acceptable.

The alternative -defining a new chain for the ws deployment and calling the required web processors in there- is most probably not going to work.

What options do you see here?

Once we flatten it out to one chain, it should just be a question of inserting the processor at the right point to process or create WAR deployment information for the web service endpoints etc.

[asoldano]

This needs to change in my opinion.  We need to convert to a single deployment unit processing chain, where each processor is responsible for detecting whether it applies to the processed deployment.

Yes, that's most likely to be OK for our needs here. After all I can see a kind of mapping with the deployers in AS 5/6 at that point...

[asoldano]

Thomas Diesler wrote:

Alessio,

in future we are probably going to see less deployment chains, possibly just one. The web subsystem could be enabled to setup endpoints based metadata that you attach to the DeploymentUnitContext. A (better) alternative would be that the WS DUP registers a WSService that has a dependency on some JBossWebService. When the WSService activates it uses well defined/stable API from the JBossWebService to setup a web endpoint.

IMHO, this is generally needed because other subsystems like the OSGi HttpService may also need to setup Http endpoints through API. Perhaps you can use

[JBOSGI-308] Implement the HttpService ontop of JBossWeb

as the entry point to this discussion. In short, JBossWeb would need to expose a set of well defined services that allows others to setup endpoints.

Yep, thanks for the reply, this alternative would be nice too...

[asoldano]

For the records: https://jira.jboss.org/browse/JBAS-8633

[asoldano]

Carlo,

as of today the needs in terms of EJB3-WS integration are the same as what we had on AS 5/6.

This said, we do plan to review / clean the jbossws-spi as soon as the ws version for AS 6 goes final. At that point we might want to comment with more/up-to-date details.

[asoldano]

Alessio Soldano wrote:

Thomas Diesler wrote:

Alessio,

in future we are probably going to see less deployment chains, possibly just one. The web subsystem could be enabled to setup endpoints based metadata that you attach to the DeploymentUnitContext. A (better) alternative would be that the WS DUP registers a WSService that has a dependency on some JBossWebService. When the WSService activates it uses well defined/stable API from the JBossWebService to setup a web endpoint.

IMHO, this is generally needed because other subsystems like the OSGi HttpService may also need to setup Http endpoints through API. Perhaps you can use

[JBOSGI-308] Implement the HttpService ontop of JBossWeb

as the entry point to this discussion. In short, JBossWeb would need to expose a set of well defined services that allows others to setup endpoints.

Yep, thanks for the reply, this alternative would be nice too...

Just to track what Thomas and me had been discussing yesterday, this alternative approach would enable us to design the AS7 integration of ws in a way such that the webservice subsystem can really expose a service for starting/stopping endpoints independently from the deployment. This would basically make  it possible to support the following usecases:

• other subsystems (osgi for instance) can rely on this ws subsystem service providing an endpoint they can depend on
• the declaration of an endpoint can become part of the domain xml, basically allowing for addition of "default" endpoints declaration to the domain

Cross link: http://community.jboss.org/thread/158869

Message was edited by: Alessio Soldano - added link to osgi dev forum thread on the httpservice requirement