sca-j message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: AW: [sca-j] [JAVA-2] Determining the data binding to use (e.g. JAXB or SDO)
- From: "Barack, Ron" <ron.barack@sap.com>
- To: "David Booz" <booz@us.ibm.com>, <sca-j@lists.oasis-open.org>
- Date: Sat, 21 Feb 2009 16:03:24 +0100
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
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
"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]