Hi,
I checked the changes for the first part (references using inbound/
outbound pairs last Friday) as well as cleaned up the connector impl
slightly (it still needs more work, but this can wait). In looking at
wire service, I think we may be able to generalize a bit further and
remove most specific knowledge around composite types from the wiring
infrastructure. For example, public void createWires(Component
component, ComponentDefinition<?> definition) sets the outbound wire
on references and this could probably be refactored to have the wire
passed to the component (in this case a composite) which delegates it
to the child reference. I noticed this type of specialized knowledge
seems to be creeping into some other places as well, which we should
probably try to remove it as much as possible.
Once you make the second set of changes related to async target
invokers we should also look at another set of changes related
supporting multiple bindings per service (as specified in the spec),
as opposed to just one. This will involve moving wires to hang off
some binding artifact and it will also entail a change in how the
builder registry dispatches to binding builders. I should be around
tomorrow unless I get caught in more meetings at work...
Jim
On Sep 20, 2006, at 3:50 PM, Ignacio Silva-Lepe wrote:
Just to touch base on this. I had a conversation with Jim and we
agreed that composite references, in particular those with a
binding such as Axis2Reference, will also be given an outbound wire
so that they can use it to add a DataBindingInterceptor.
In addition, instead of using an outbound invocation handler off of
this outbound wire to interact with the Axis2 operation client, the
Axis2Reference's inbound chains will be linked to the outbound
chains on this new outbound wire and the Axis2AsyncTargetInvoker
will still interact with Axis2's operation client once the
DataBindingInterceptor on the outbound wire has done its thing.
This is a bit of a departure from the original architecture but it
can be turned into an advantage if it gets generalized to bindless
composite references to avoid making new message instances at every
hop from one composite reference to the next, up the recursive
composite hierarchy.
To address Raymond's immediate issue, Jim has volunteered to make
the change on for Axis2Reference as a first step. This will allow
the Axis2 binding and data binding integration work to go forward.
As a second step, we can revisit CompositeReference and retrofit
this change there as well.
Jim, please let me know if I have mis-stated any or all of this wrt
to our conversation.
Thanks
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, September 20, 2006 3:03 AM
Subject: Re: How can we insert a DataBindingInterceptor for the
outbound wire of a composite-level reference?
On Sep 19, 2006, at 11:45 PM, Raymond Feng wrote:
Hi,
I raised a similar issue on this list before but I didn't get any
responses. When I debugged a test case from Rick today, I found
it was due to same problem.
Let's assume we have composite level reference with Axis2 web
service binding.
<reference name="RemoteInteropDocService">
<!-- interface.wsdl interface="http://soapinterop.org/
#wsdl.interface(DocTestPortType)"/ -->
<interface.java interface="org.soapinterop.DocTestPortType"/>
<binding.ws endpoint="http://soapinterop.org/#wsdl.endpoint
(interopDocSvc/interopDocPort)" location="wsdl/interopdoc.wsdl"/>
</reference>
Physically, there are two service contracts involved for this
reference.
1) The interface declared in <interface.xxx>. I assume it's for
the inbound wiring. For example, you can have a reference at a
component being wired to this reference (
component.reference --> composite.reference).
2) The WSDL portType used by the <binding.ws>. It really defines
the contract for the outgoing request. With Axis2, AXIOM is the
databinding. If a portType is not declared for binding.ws, we
should derive it from the interface.xxx (Java2WSDL could be used
for interface.java).
We may have two cases (SC: ServiceContract):
a) component.reference (SC1) --> composite.reference (SC2) -->
Axis2 web service (SC3)
b) composite.reference (SC2) --> Axis2 web service (SC3)
(CompositeContext.locateService(<compositeReferenceName>) is
used to make the invocation)
In case a), the DataBindingInterceptor will be added to the wire
(to be precise, SC1.outbound wire) if SC1 and SC2 require some
mappings.
But we don't have a way to add a DataBindingInterceptor between
SC2 and SC3. As a result, case b) is failing (Rick's test case).
I have tried to do this in the BindingBuilder but it doesn't
seem to be very straightforward with the following observations.
1) Wires are created for Reference by the WireService after the
Reference instance is created by a builder.
2) No outbound wire is created for Reference.
3) WirePostProcessor is not triggered for case b).
One thing I can think of is to allow the builder to set an
optional outbound service contract for the Reference and the
WireService will create the outbound wire for Reference in this
case. And the TargetInvoker should be added to the outbound wire
instead of inbound wire. During connecting, the Connector will
trigger the WirePostProcessor to mediate the inbound wire and
outbound wire. Then we have a chance to add a
DataBindingInterceptor to mediate SC2 and SC3.
On the issue of the outbound wire added to a composite reference
you are right, there should be one. I spoke to Ignacio about this
since it touches on some of the callback and composite reference
work but since I've been out, he should have the latest on if
this was added in (I'm guessing not). If not, I'm sure either he
or I can look into doing that over the next day or so. In any
event, the only case I can think of where we need a mediation
"inside" a reference is when the interface is not compatible with
the binding WSDL.
One further question: what d you mean by
"CompositeContext.locateService(<compositeReferenceName>) is used
to make the invocation"?
Jim
Any thoughts?
Thanks,
Raymond
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
