On Sep 22, 2006, at 12:01 AM, Raymond Feng wrote:
Hi,
With Jim's fix for the wiring, I can move further. But I have to
make the following changes to make the end-to-end successful.
1) Add a "setBindingServiceContract" and getBindingServiceContract
() to Reference and Service interfaces.
2) The binding builders can optionally contribute a
bindingServiceContract to the Reference/Service by calling
setBindingServiceContract(...)
3) The JDKWireService will check the existence of the
bindingServiceContract and use it for Service.inboundWire and
Reference.outboundWire. If no bindingServiceContract, then we
assume the bindingServiceContract is the same as the one from
<interface.xxx>.
I thought it would use interface.xxx since the wire services
generates proxies given to SCA clients (e.g. components). The binding
service contract would be used by the target invoker to dispatch an
invocation and hence would have to perform a mapping from the
operation specified by interface.xxx.
With the above the changes, I can now run the WebService interop
test case from Rick successfully (with some SCDL and dependency
adjustments).
Do you think the changes I made is the right fix? If so, I can
commit them into SVN tomorrow.
Thanks,
Raymond
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, September 21, 2006 5:22 PM
Subject: Fwd: How can we insert a DataBindingInterceptor for the
outbound wire of a composite-level reference?
For some reason my isp bounced this...
Jim
Begin forwarded message:
From: Jim Marino <[EMAIL PROTECTED]>
Date: September 21, 2006 2:52:59 PM PDT
To: [email protected]
Subject: Re: How can we insert a DataBindingInterceptor for the
outbound wire of a composite-level reference?
On Sep 21, 2006, at 1:23 PM, Raymond Feng wrote:
Hi, Jim.
I'm preparing the move now, basically refining the code and
adding more test cases.
For package names, I'm thinking of the following:
org.apache.tuscany.spi.databinding (DataBinding SPIs)
org.apache.tuscany.spi.databinding.extension (DataBinding
related base classes for extensibility)
org.apache.tuscany.core.databinding (Core DataBinding
implementations)
org.apache.tuscany.core.databinding.xml (Other simple
databindings and transformers, for DOM, StAX, SAX, I/O etc)
Just to be clear, I only think the base databinding framework
should go in core (I think that is what you have in mind) -e.g.
JAXB, Castor, SDO, etc. would still be service extensions.
BTW, we will need to add "idl/wsdl" as a dependency to the core
for the databinding part.
I guess we have to put that in right? It would be nice if we
didn't but it may be something that has to be done.
Jim
Sounds reasonable?
Thanks,
Raymond
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, September 20, 2006 11:51 AM
Subject: Re: How can we insert a DataBindingInterceptor for the
outbound wire of a composite-level reference?
O.K. great. In the meantime, do you want to work on moving the
databinding framework pieces into core assuming no one objects?
Jim
On Sep 20, 2006, at 11:30 AM, Raymond Feng wrote:
Hi, Jim.
Thanks for the prompt response. I'll be waiting for the fix to
complete the databinding integration story. If I can help
here, please let me know.
What I meant "CompositeContext.locateService
(<compositeReferenceName>) " is to get a proxy against the
composite reference directly and invoke it instead of
going through a component reference (which is wired to the
composite reference). Basically, it is the case b) in the
orginal note.
Thanks,
Raymond
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, September 20, 2006 12: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]
-------------------------------------------------------------------
--
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]
