I'll try to explain what I see as the issue. An application has a
"deployment" model and it has an "endpoint" model. The RI is merging the
2 when deploying in servlets. It is saying that just because an
application is deployed as a servlet it will only want to use servlet
endpoints. This is not the case. Consider an example application (we
have this at a customer)
- main endpoint is JMS
- receiver is BPEL engine
- BPEL script contains invokes to a partnerlink over http that result in
asynchronous callbacks
- the callbacks come over http
- the service WSDL publishes 2 services, one for the JMS endpoint to the
MyPortType and one for the callback endpoint for the CallbackPortType.
- it is deployed within a servlet
The deployment model here is servlet. There are 2 endpoint models - HTTP
(servlet-based) and JMS. The HTTP callback could also have been
implemented over JMS or any other transport but the deployment would
still be as a servlet.
Apart from the WSServletCallbackListener enforcing that all endpoints
are current HTTP and hosted by the servlet, the other component I feel
is missing is a factory that can take a transport URL and produce a
WSEndpoint for it (which may not be Adapter based since the requirement
for a transport is really just to be able to receive a message, convert
it to a Packet and put it into the Tubeline).
I've started to play with the spring integration project to see if I can
make that work around this.
Kohsuke Kawaguchi wrote:
> Oleksiy Stashok wrote:
>> I think there is the way to return custom port URL, please look at
>> HttpAdapter.createPortAddressResolver() and how it is used. Seems
>> inheriting HttpAdapterList it's possible to make it.
>
> Two independent transports really shouldn't be messing with each
> other. HttpAdapter is really meant just for HTTP transport.
>
>> As for publishing wsdl via custom transport - think it's really
>> feature we miss now. Think MEX should solve that problem, but so far
>> it supports just HTTP transport, but AFAIK there are plans to support
>> custom ones.
>
> This is a big problem we need to fix, IMO. It's embarassing.
>
It would be nice to have but I wouldn't say it is embarassing. I can't
think of a customer that has needed anything other than HTTP and UDDI
access to WSDL.
Pete