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
