On 2/19/07, Ramon Buckland <[EMAIL PROTECTED]> wrote:
Hi peoples,
<snipped>
What I would "like" to do, is to (a) have the balanceStuff (hb1) WSDL expose the combined WSDL of endpoints ep1, ep2 and ep3 but only certain interfaces of that WSDL. (b) have a message sent to hb1, automatically route to ep1, ep2 or ep3 depending on who actually can handle the message. (more on this below) (c) not have to use "static" WSDL files everywhere (we have 30 + opeartions, and growing rapidly) Regarding (a), the http:endpoint by reading it's documentation states that when used as an xbean deployment with NO wsdlResource, it will locate the wsdl to expose from the endpoint it is the consumer for Sounds good, can it do more than one endpoint ?
This is not possible currently. However, I don't think such an endpoint can be described using a single WSDL. I think the only solution would be to define a single service with 3 different endpoints, each one bound to a different port type, but this is not supported yet.
Regarding (b), the JBI spec states that a message is routed in order of specificity based on the interfaces, service, then endpoint. Because "interface" (wsdl 2.0) is specified as the portType in 1.0, would it not be possible to just make sure each message "accepted" is for a unique interface, one that 1 and only one endpoint provides. ie can I route just based on the interface alone that is effectively provided by the client, and is the interface in a WSDL for the http-endpoint sufficient to do the job.
Why not implementing a router component which would be a bit more intelligent than the EIP xpath router, by looking through the WSDLs of the JBI endpoints and selecting the endpoint that implements the needed operation ? I think it would be better suited as a standalone component rather than embedding this logic in the http BC or container itself (though, I guess it may be argued).
Regarding (c), can one http-endpoint be bound to more than one endpoint such that routing automagically occurs based on interface matching ?
Not really sure about that. I'm not sure that putting some routing strategy inside the http BC is a good idea. As explained earlier, i'd rather try to create a custom (or generic) router based on the EIP abstract router ... What do you think ?
I know this is a bunch of Ideas here, but I was wondering if it's already in there and I don't know about it or something else. Our fallback option is to use a monolithic WSDL for each endpoint exposed on a few http-endpoints and to use EIP xpath routing to switch the messages around where there is a "one to many" for one httpbinding endpoint to "JBI endpoint" mapping. It's just that the management of this xpath routingwill become bigger than we want it, and one of these endpoints allows some pretty fancy dynamic changes to the WSDL and a static config breaks it's very nature.
Yeah, this is easy to understand ... The problem with the mutliple WSDLs is a bit weird. Maybe WSDL2 would help, as it supports interface inheritance. Maybe each of your endpoint ep1, ep2, ep2 could support more than one interface (this is not really possible using WSDL 1.1). You could go as far as defining an interface for a single operation ; each JBI endpoint would implement one or more interface, and routing could happen transparently, just using interface routing. In such a case, we may be able to find a way to say that servicemix-http would send the exchange to the interface that implement the operation invoked, thus allowing all the endpoints implementing this interface to receive the exchange. I don't think this is really possible with WSDL 1.1 unfortunately.
phew .. take a breath. hope that makes sense. r.,
-- Cheers, Guillaume Nodet ------------------------ Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
