Hi,
More updates on this topic.
1) I changed the Operation model to take an inputType, an outputType and a
list of faultTypes. The inputType is a special DataType with its logical
type representing the parameters. For a java method, the inputType looks
like:
databinding: "java:parameters" (for the Object[] --> Object[] conversion)
physical: "java.lang.Object[]"
logical: List<DataType<T>> (A list of DataTypes, each element in the list
representing a parameter type. The list is empty for no-arg.
2) Add speical databindings/transformers to represent the inputTypes from
different IDLs so that we can perform payload transformations. For example,
Object[] --> Object[] and Object[] --> OMElement.
3) Add "isWireable(ServiceContract source, ServiceContract target)" to the
WireService and provide an implementation in JDKWireService. Right now, I
relax the the checking on remotable operations so that only name is matched.
3) A databinding sample based on the dummy EchoBinding with the on-demand
transformation across the following two interfaces.
@DataType(name="java.lang.String")
@Remotable
public interface Interface1 {
Object call(Object msg);
Object call1(Object msg);
}
@DataType(name="org.w3c.dom.Node") // interface-level
@Remotable
public interface Interface2 {
Node call(Node msg);
@DataType(name="javax.xml.stream.XMLStreamReader") // operation-level
XMLStreamReader call1(XMLStreamReader msg);
}
And here's the result:
ComponentA --> Received message: <foo>123</foo> [java.lang.String]
ComponentB --> Received message: [#document: null]
[org.apache.xerces.dom.DeferredDocumentImpl]
ComponentB --> Returned message: [#document: null]
[org.apache.xerces.dom.DeferredDocumentImpl]
ComponentA --> Returned message: <?xml version="1.0"
encoding="UTF-16"?><foo>123</foo> [java.lang.String]
ComponentA --> Received message: <foo>123</foo> [java.lang.String]
ComponentB --> Received message:
[EMAIL PROTECTED]
[org.apache.axiom.om.impl.llom.OMStAXWrapper]
ComponentB --> Returned message:
[EMAIL PROTECTED]
[org.apache.axiom.om.impl.llom.OMStAXWrapper]
ComponentA --> Returned message: <foo>123</foo> [java.lang.String]
Accidentally, I verified the two-hop transformations from XMLString -->
AXIOM --> XMLStreamReader and the reverse because I forgot to register the
direct transformers. :-)
4) Several issues that are worked around
1. I have to add "addInterceptor(int index, Interceptor interceptor)" method
to the InvocationChain so that I can add the DataBinding interceptor before
the TargetInvokerInterceptor.
2. There's no component init dependency accross composites. In my case, some
transformers from databinding-axiom have dependencies on
databinding-framework which is still an extension at this moment. I have to
add the "databinding.scdl" to the "test" to make it part of the "core".
I think I'm ready to check in the changes so that other folks can help if
there's no objections.
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, September 07, 2006 11:47 AM
Subject: Re: Update on the databinding integration and open issues for
discussion
On Sep 7, 2006, at 11:26 AM, Raymond Feng wrote:
I propose that we change the Operation model as follows:
Operation
--- name (Name of the operation)
--- inputType (For java, it's a DataType representing the Object [].
For WSDL, it could be a DataType representing the top-level request
element using Axiom or other databindings)
--- outputType (For java, it's a DataType representing the
returnType. For WSDL, it could be a DataType representing the top- level
response element using Axiom or other databindings)
--- faultTypes (A list of DataTypes representing the faults/
exceptions)
OK
DataType
--- databinding
--- phsicalType
--- logicalType
--- properties (A list of DataProperty(s) for the DataType to
represent the visible children)
Why properties? For example, a Java argument list does not have named
parameters (in the source yes but not in the public contract).
Can we just use:
physicaltype: Object[].class
logicalType: Class[]{Customer.class, String.class}
and
physicalType: OMElement.class
logicalType: QName{http://example.com, order}
DataProperty
--- name (QName of the property)
--- type (DataType for the property)
QName only makes sense for XML - what would that be in the Java case?
For the DataType/DataProperty recursion, we don't have to go too deep.
For example, we may only require a list of properties for the DataType
for the inputType.
There's something fishy here if the properties only apply in certain use
cases.
--
Jeremy
---------------------------------------------------------------------
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]
