OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: AW: [LIKELY JUNK]AW: [sca-j] [JAVA-2] Determining the data binding to use (e.g. JAXB or SDO)


for completeness, according to the 2.1.1 spec, if the static SDO *is* a class, then it must implement DataObject.


Von: Barack, Ron [mailto:ron.barack@sap.com]
Gesendet: Samstag, 21. Februar 2009 16:03
An: David Booz; sca-j@lists.oasis-open.org
Betreff: [LIKELY JUNK]AW: [sca-j] [JAVA-2] Determining the data binding to use (e.g. JAXB or SDO)

Hi Dave, Everyone,
 
As you maybe remember (if you remember me at all, since I haven't been active in SCA recently) I am chair of the SDO TC.  We were having our virtual F2F last week, and I discussed this issue briefly with another SDO TC member, one who also serves on the JAXB EG.
 
Although there are ways to modify a the JAXB mapping, it's a pretty safe pretty safe bet that the classes used with JAXB are in fact classes, and not interfaces.  And while an SDO vendor may support the use of implementation classes as static SDOs, this is a vendor extension.  Interfaces are the standard Java mapping for complex types in SDO.  I'm refering here to SDO 2.1.1, recently in public review in the JCP.
 
Putting these two facts together leads to a rule that, although not 100% reliable, should at least cover the 80% case:  if it's a class, use JAXB, if it's an interface, use SDO.  Of course, some mechanism should be provided to override this, be this is a pretty reasonable default behavior.
 
By the way, SDO 3.0 provides a mechanism for a much more flexible mapping between the Java interfaces and the WSDL/XSD through which the SDOs are exposed as a web servers.  The basic idea is that since SDO, like java and RDBs tend to have bi-directional, m:n relationships and generally non-containment relationships, there are a whole set of WSDLs/XSDs to which the SDO fits, each XSD imposing a different containment structure on the data.  Moreover, SDO 3.0 provides XML serialization for data graphs that have no containment structure at all.  My feeling is that this is all very relevant to SCA bindings.  But we've just released our first CD, and it will be a few months before SDO 3 is ready for public draft.
 
Best Regards,
Ron
 


Von: David Booz [mailto:booz@us.ibm.com]
Gesendet: Freitag, 20. Februar 2009 15:09
An: sca-j@lists.oasis-open.org
Betreff: Re: [sca-j] [JAVA-2] Determining the data binding to use (e.g. JAXB or SDO)

I don't think that's an acceptable answer. Given that the application databinding is an open extensibility point in the programming model, the applications will need a way (a hint maybe) to indicate the databinding technology they are using (it is not always introspectable). At the very minimum I think we need an extensibility point analogous to <wireFormat/>.

If I would have known you were thinking of CNAing this, I would have taken over the issue to provide a proposal. I guess I now need to come up with a proposal in the next few days.

Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com

Inactive hide details for "Pavlov, Plamen" ---02/20/2009 06:48:15 AM---Hi Folks, Taking into account the short time frame till "Pavlov, Plamen" ---02/20/2009 06:48:15 AM---Hi Folks, Taking into account the short time frame till the public review and the


From:

"Pavlov, Plamen" <plamen.pavlov@sap.com>

To:

<sca-j@lists.oasis-open.org>

Date:

02/20/2009 06:48 AM

Subject:

[sca-j] [JAVA-2] Determining the data binding to use (e.g. JAXB or SDO)





Hi Folks,

Taking into account the short time frame till the public review and the complexity of the topic, the proposal is:

Close current issue with no action and leave the discussion for the next release.

Best Regards,

Plamen



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]