Hi Alex !
Great work ! I'm looking forward to see it in action !
Since we met at Apache Con, I made some experiments on soap using
several stacks : axis2, xfire, activesoap.
Here are my thoughts on using a soap stack:
* 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 ...
* 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
* 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
* 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....
* 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. 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.
* 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 ...
Btw, a good shared repository could be the sandbox at
https://svn.apache.org/repos/asf/incubator/servicemix/trunk/sandbox/ :)
Cheers,
Guillaume Nodet
Alex Boisvert wrote:
(Added axis-dev to CC: list)
Howdy,
I'm in the process of designing an Axis2-based binding component and
wanted to solicit feedback and review before I get too far.
The BC would support two main use-cases:
-expose internal JBI components over protocols/transports supported by
Axis2
-allow JBI components to access external web services using Axis2
To expose an internal service, one would create a service unit that
would identify the internal service, and provide an Axis2 services.xml
descriptor to configure the processing chain, binding and port
information (e.g. protocol, transport, policy, security, ...)
At runtime, the BC would obtain the internal service description (WSDL)
via Component.getDescription() and update its binding and port
information according the Axis2 configuration such that the resulting
WSDL can be provided dynamically to external consumers (e.g. via HTTP
GET).
For external services, one would create a service unit containing a
service description (WSDL) and an optional Axis2 services.xml descriptor
if a special processing chain is required.
The BC would then expose this external service on the JBI bus, which may
then be resolved using service type, service name, service endpoint,
external endpoint and (eventually) service reference.
The BC descriptor would look something like this:
<Axis2BC-descriptor>
<service>
<type>internal/external</type>
<!-- route element only valid if service type is "internal" -->
<route>
<interfaceName>QName</interfaceName>
<serviceName>QName</serviceName>
<endpoint>NCName</endpoint>
</route>
</service>
</Axis2BC-descriptor>
And the service unit layout would look like this:
meta-inf/jbi.xml (JBI service unit descriptor)
meta-inf/Manifest.mf (JAR manifest)
meta-inf/services.xml (Axis2 service descriptor)
MyExternalService.wsdl (WSDL for external service, if applicable)
That's what I've got so far. I have ideas on additional features for
the BC but I want to get the basics right first.
BTW, is anybody already working on something similar? Maybe we can work
together. Also, if anyone is interested in helping out during the early
development stage, please let me know and we could arrange to setup a
shared repository.
cheers,
alex
