Hi,
Please see my comments on the databinding part.
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Friday, February 16, 2007 12:41 PM
Subject: wire post processing and implementation vs. contract metadata
In doing the wiring refactor to support distribution, it struck me that
we need to modify how and when wire post processing takes place, as well
as how related metadata is tracked in the runtime.
In terms of wire post processing in general, I think we need to move it
to the master. Here is how I see that process working:
- On the master, the logical assembly model is processed in multiple
stages (I'm leaving details out in order to focus on wire post
processing). When the model is processed, PhysicalComponentDefinitions
and WireDefinitions will be created. A WireDefinition contains a list of
InterceptorDefinitions that constitute a Wire. I propose we move the
existing wire post processor implementations (DataBinding and
AllowsPassByValue) to the phase where WireDefinitions are created since
they deal with defining a wire and not post-processing it. They will deal
with logical model objects and produce an InterceptorDefinition,
something to the effect of:
buildWireDefinition(WireDefinition definition, ModelObject source,
ModelObject target)
There may be a post-process step along the way but it will not be to add
new InterceptorDefinitions.
- WireDefinitions will be marshalled to a slave (potentially along with
PhysicalComponentDefinitions)
- On the slave, the WireDefinitions will be reconstituted. They will then
be passed to the Connector which will have one method:
Connector.connect(WireDefinition wd) throws WiringException
- The connector will create a Wire (WireService will no longer exist and
it's proxy creation functions will be moved to a ProxyService)
- The connector will dispatch to InterceptorBuilders to add interceptors
to the wire and then will attach the Wire to its source.
The above process will mean that the existing WireProcessors will need to
be moved to the master as part of a InterceptorDefinitionBuilder (we can
change the name) and that PolicyBuilders will go away. We will also need
to add InterceptorBuilders which run on the slave and create interceptors
based on InterceptorDefinitions created by the
InterceptorDefinitionBuilder.
In regards to the second issue, how wire-related metadata is tracked, I
believe we may be conflating service contract vs. implementation
metadata, and that we need to make a distinction. Specifically:
- Databinding technology is not reflected in the service contract but in
the implementation contract. For example, different component
implementations may choose different databinding technologies. Currently,
we pass this information as part of Operation, which is part of the
ServiceContract.
I can see the following paths below with potentially different data
contracts that require transformations:
1. component1.ref1 --> component2.svc1
a) component1's implementation contract --> component1.ref1's
ServiceContract
b) component1.ref1's ServiceContract --> component2.svc1's
ServiceContract
c) component2.svc1's ServiceContract --> component2's implementation
contract
2. composite.service1 w/ binding1
a) binding1's contract (mandated by the transport/protocol stack, for
example, AXIOM for Axis2) --> composite.service1 ServiceContract (by the
interface definition under <service>)
3. composite.reference1 w/ binding1
a) composite.reference1's ServiceContract (by the interface definition
under the <reference>) --> Composite reference's binding contract (mandated
by the transport/protocol stack)
There are different cases:
1) Case 1: A "weak" interface implemented by a method expecting a
databinding-specific data. The implementation has a contract which is not
the same as the ServiceContract for the service.
public interface GenericInterface {
Address getAddress(Customer customer);
}
Both Address and Customer are plain interfaces.
Then if the implementation code only work off the common interfaces, then no
transformation is required. If it happens that impl code will cast the
interface to some hidden contract such as commonj.sdo.DataObject, then we
need to have the method in the impl class to express such requirements.
Another case is that we provide a componentType file for a POJO component to
indicate that it exposes service using WSDL. Then the ServiceContract for
the POJO component now is a WSDL service contract.
A similar case would be that a JavaScript component using interface.java, so
the incoming data should be conforming to the java interface. But the
JavaScript code might want to deal with all the data as XMLBeans.
For references and services with bindings, it becomes more obvious to see
the databinding requirement from the binding contracts. For example, the
binding.axis2 would only consume and provide data in AXIOM. The databinding
information will be provided by binding extensions and set to the binding
metadata.
2) Case 2: Two remotable interfaces with different databindings for the
reference and target service
Let's assume there are two remotable interfaces generated from the same WSDL
under two different databindings (SDO vs. JAXB):
public interface JAXBInterface {
JAXBAddress getAddress(JAXBCustomer customer);
}
public interface SDOInterface {
SDOAddress getAddress(SDOCustomer customer);
}
We now have two components: Component1 is implemented using SDO while
Component2 is implemented using JAXB. Component1 has a reference "ref1"
typed by SDOInterface (because component1 will use SDO data for the outbound
service call) while Component2 has a service "svc1" typed by JAXBInterface
(because component2 only accepts JAXB data).
Should we support the wiring from Component1.ref1-->Component2.svc1? (I
think it's resonable as the two interfaces can be mapped against each other
because both are representation of the same WSDL portType using different
databindings.
- AllowsPassByReference is set on AtomicComponentExtension but should be
per-operation and not on the extension class. Again, it should be in an
implementation contract.
I propose we introduce metadata on the ComponentType for the purpose of
tracking this component implementation-related metadata for operations
offered by a component implementation. For composite services and
references, we can add the metadata to BindingDefinition. For the latter,
it would be the job of the Binding implementation (e.g. Axis, CXF, etc.)
to add the metadata based on its capabilities or configuration. This will
allow us to move databinding information out of SCDL.
+1.
I'm in the process of making the Wiring changes to kernel now. After
that, I'd like to tackle the problems I outlined above. Is anyone
interested in working on this and/or have suggestions or alternatives in
mind?
Jim
---------------------------------------------------------------------
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]
