axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Boisvert <boisv...@intalio.com>
Subject Re: Axis2 JBI binding component
Date Tue, 17 Jan 2006 02:45:32 GMT

Guillaume,

Sorry for the late reply, I hadn't noticed your answer because it was 
filtered in my axis2 folder which I don't read every day because of the 
high volume of emails.

See my comments below.

Guillaume Nodet wrote:
> * the soap envelope should not be sent on the jbi bus: one of the 
> problem is when using rpc.  the jbi spec defines a wrapper schema for 
> wsdl 1.1 parts, but ...

Yep, no SOAP envelope on the JBI bus.

> * soap headers must be sent in some form on the bus so that the target 
> components may be able to process them we must use specify a property to 
> put a map containing those headers on the message, and eventually a 
> common format
>    - use "javax.jbi.protocol.headers" (defined by the spec) for a 
> Map<String,String> containing protocol headers (http / jms for ex.)
>    - use "javax.jbi.soap.headers" (not defined by the spec) for a 
> Map<QName,Element> containing soap headers

Ok, good idea.  I will follow these guidelines.

> * use of soap:mustUnderstand on headers:  can we allow the target 
> component to process soap headers ?  if yes, we must supply a 
> place-holder to say which headers were successfully processed

I'm not sure if you're talking about the BC or the ultimate recipient of 
the message.

My understanding is the BC does not have to interpret the mustUnderstand 
attribute because it does not actually process the message.  As for the 
ultimate recipient, it MUST send back a fault if it doesn't understand 
the header.

http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#muprocessing

Now, if the originating component wants to pass out-of-band information 
to the BC, I would use specific properties on the JBI message, such as a 
Map<String,String> containing properties specific to the BC.

> * use of ws-addressing :  how will ws-addressing be engaged ?  how will 
> these informations be used ? For example, if a replyTo header is given, 
> will this information apply at the BC side, or the target endpoint side 
> ?   I think I may have missed something but I do not really understand 
> how this may be mapped the the jbi exchanges meps.  I mean if such 
> information is to be applied on a Service Engine, it may conflicts with 
> the JBI spec: an in-out exchange MUST be routed back to the consumer, 
> else there will be lots of problems.  Another point I do not really 
> understand, but maybe the someone will be able to help me:  a url is 
> mapped to a service so if I send a message on a given url specifying a 
> wsa:To endpoint, it seems that it will become inconsistent: the request 
> will be routed to another service :(  I 'd rather have a non-mapped url 
> which could be used to send requests containing wsa informations....

I agree there seems to a conflict here between JBI and WSA but I don't 
know what is the solution.  Maybe something to submit to the JBI spec 
committee?

For the use-cases I'm currently considering, the WSA information could 
be handled by the BC and therefore be abstracted from the consumer in 
the form of a javax.jbi.servicedesc.ServiceEndpoint.

> * use of the wsdl : JBI spec has been written with WSDL 2 in mind, which 
> means that RPC style is not really supported.  I'm not a soap expert, 
> but lots of binding informations are geared toward the unmarshalling 
> layer and I do not see how you will create these informations.  But once 
> again, I may miss something.

Good point.  I was initially assuming that internal services exposed 
through the BC would use document-literal binding.  I guess rpc-literal 
would also be possible.   As you point out, RPC encoding would be much 
more complex to support but, thankfully it's going out of style! (pun 
intended)

>  Another point is the use of a HTTP GET to 
> retrieve the wsdl.  I think this a great feature, but i would like to 
> have something that could apply on the whole JBI bus : maybe using a 
> UDDI registry where WSDL would be automatically published by ServiceMix, 
> or have a web console that would list all endpoints / wsdls.  I am not 
> sure that this should be done specifically for the Axis2 BC.  Moreover, 
> these would not be accessible for other transports such as JMS.

Yes, the BC should support for HTTP GET to retrieve the WSDL;  I believe 
the basic building blocks are already there in Axis2 and there's also a 
console work-in-progress that will allow browsing deployed services.

As for publishing to UDDI, I don't know if there's anything in the works 
to support this with Axis2.   I would make sense to have UDDI publishing 
as a service on the JBI bus, although I have never seen a service with 
JMS binding published on UDDI.   Do people on this list actually intend 
to do that?

> * i was wondering if we could allow automatic binding of internal 
> endpoints.  Such binding components may not require any information at 
> all (in addition to the JBI endpoint to proxy), so that could be done 
> automatically or maybe without any real deployment.  I know that this 
> somewhat violate the JBI spec, but this is for ease of use ...

That would certainly be an interesting feature for development, although 
I'm not so sure about the value of this in an industrial application 
since most of the time you'll want to define the endpoint, processing 
pipeline and/or quality of service aspects of the service (e.g. security).

> Btw, a good shared repository could be the sandbox at 
> https://svn.apache.org/repos/asf/incubator/servicemix/trunk/sandbox/ :)

Noted!  I'll come back to you when I have rudimentary code.

Thanks for your input!

alex


Mime
View raw message