← Prev in month ← Prev in thread
Next in thread → Next in month →

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

From
Barack, Ron <>
Date
2009-02-21T23:07:02+00:00
ID
Thread
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:] 

Gesendet: Samstag, 21. Februar 2009 16:03
An: David Booz; 

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:] 

Gesendet: Freitag, 20. Februar 2009 15:09
An: 

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:

"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" 
      <>

  

    
To:
    
<>

  

    
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
← Prev in month ← Prev in thread
Next in thread → Next in month →