Hi Raymond,
This is something that I picked up from ASM. This is the way method
signatures are input to the ASM Bytecode Generator. Anyways, here is an
attempt. I have modified the opertation bindings to bring out what was
in
my mind. I have used square-brackets ([) for some clarity only... so
that
you are able to quickly delimit paramters and return result.
@Remotable
@DataBinding(name = "sdo") // Interface-level databinding declaration
public interface Dummy {
// Order and Shipment are SDO DataObject(s), Date is a plain java
object
Shipment createShipment(Order order, Date deadline);
@DataBinding
[(name="jaxb", attributes={ @DataAttr(name ="contextPath", value= "
com.example.ipo.jaxb") }),(name="java")](name="jaxb", attributes={
@DataAttr(name ="contextPath", value= "com.example.ipo.jaxb")})
}
In this, we explicitly mention the target types for all parameters and
also
the return type. The databinding framework would transform only if the
source and target types are different. So in the case of the second
parameter 'deadline' there would be no conversion since the framework
will
find that the source and target type are both Java.
Thanks
- Venkat
On 9/28/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
Inspired by the JAX-WS/JSR 181 annotation styles, I come out with the
following example.
@Remotable
@DataBinding(name = "sdo") // Interface-level databinding declaration
public interface Dummy {
// Order and Shipment are SDO DataObject(s), Date is a plain java
object
// @DataParam marks the parameter and @DataResult marks the return
value, please note @DataResult applies to "METHOD". Both are optional
@DataResult Shipment createShipment(@DataParam Order order, Date
deadline);
@DataBinding(name = "jaxb", attributes = { @DataAttr(name =
"contextPath", value = "com.example.ipo.jaxb") }) // operation-level
databinding
@DataResult CreditReport checkCredit(@DataParam Customer customer);
@DataBinding(name = "xml:string")
@DataResult String evaluate(@DataParam String xml, String xpath);
}
Venkat, can you illustrate your syntax with my example so that I
understand
better?
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Wednesday, September 27, 2006 11:09 PM
Subject: Re: Parameter-level databinding support
>
> On Sep 27, 2006, at 11:04 PM, Venkata Krishnan wrote:
>
>> Hi Raymond,
>>
>> I agree with Jim on that the indexing is cryptic. How about
this...
>>
>> @DataType((<arg1_type>, <arg2_type>)<returnType>).
>>
> This to me is a lot easier to follow. Raymond, to the higher level
> question, the example seems a bit strange so maybe you can
explain it
> further?
>
> Jim
>
>> i.e. we specify for all arguments and the returntype. The
transformer
>> decides to transform only those whose source and target types
differ.
>> Makes
>> sense ?
>>
>> Thanks
>>
>> - Venkat
>>
>>
>> On 9/27/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>> On Sep 27, 2006, at 9:32 AM, Raymond Feng wrote:
>>>
>>> > Hi,
>>> >
>>> > It seems that we have to revisit this issue again. During past
>>> > discussions, we thought it would be sufficient to only support
>>> > interface and operation level databinding declarations and
assumed
>>> > that mixed databindings on the same operation was crazy :-).
>>> >
>>> > I now have difficulties to identify which parameters for a java
>>> > method should be transformed based on the interface/
operation level
>>> > databinding. Let's have an example below.
>>> >
>>> > Case 1: The "xml" parameter is an XML string, but "plainStr"
is a
>>> > simple plain string
>>> > @DataType(name="xml:string")
>>> > String myOp(String xml, String plainStr, int i);
>>> >
>>> > I can ssume that parameters with primitive types such as "i"
bear
>>> > JavaDataBinding but I cannot differentiate "xml" and
>>> > "plainStr" (neither the return value).
>>> >
>>> > Case 2:
>>> > @DataType(name="commonj.sdo.DataObject)
>>> > Address getCustomer(Customer customer, String str, Object obj);
>>> >
>>> > Is it reasonable to have "Customer" a DataObject and
"Address" a
>>> > java bean? How about "obj"?
>>> >
>>> This seems a bit strange. What meaning do str and obj have in the
>>> service contract? Maybe there is a better example?
>>>
>>> > The key issue here is that java method by default uses
>>> > JavaDataBinding. Declaring a different databinding such as
>>> > XMLString or SDO actually starts to have mixed databindings
for one
>>> > method.
>>> >
>>> > Interestingly, this issue is not really a problem for WSDL
which
>>> > usually types the operation parameters as XSD types and a
java/xml
>>> > binding technology such as AXIOM, DOM, SDO or JAXB comes
behind it.
>>> > One databinding for the whole WSDL port type sounds reasonable.
>>> >
>>> > I have a proposal to add an attribute to the operation level
>>> > databinding declarations to explicitly spell out the list of
>>> > parameters (or return value).
>>> >
>>> > @DataType(name="commonj.sdo.DataObject" parameters={0, 2,
-1}) //
>>> > "parameters" is a list of indexes for the args, -1 for
return value
>>> >
>>> Indexing like this is error prone and difficult to read. If do
need
>>> multiple parameter types, we should have an an optional attribute
>>> specifying the return type and a collection of data types for
>>> parameters similar to @Constructor
>>>
>>> > If "parameters" is not specified then we assume it applies
to all
>>> > parameters and the return value.
>>> >
>>> > What do you guys think?
>>> >
>>> > 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]
