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: <[email protected]>
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]
