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: RE: [LIKELY JUNK]AW: [sca-j] [JAVA-2] Determining the data binding to use (e.g. JAXB or SDO)

Hi Colleagues,


I would like to describe in detail the technical challenges we've faced, while designing and implementing an SCA Runtime that would be able to handle SDO and JAX-WS/JAX-B based endpoints.


Before i continue, I would like to emphasize that the challenges and issues described below are not scoped to the SCA-J spec alone. The End-2-End solution has to come from alliginih SCA-J, SCA-Asssembly, SCA-Bindings and hte SCA J2EE Spec. Doing less than this will only provide a local solution (like curing a symptom) rather solving the core problem.


The JAXB-2 Issue, in its core speaks about a method to select at design time, which data-binding technology to be used at runtime. Like I've seen from your comments, as well as based on my initial assumptions - the staight-forward solution of this is to define some property on some of the SCDL artifacts and explain that it will instruct the SCA Runtime to do one thing or another.


A it turned out during the design - the problem is not to define the property, rather to deifne the semantics in a way that they fit a growing domain of requirements and preconditions.


The target scenario is - A Service with interface.wsdl and binding.ws, and a component with implementation.ejb or implementation.bpm hosting the implementation.


Case 1:

         Implementation is an EJB and required Data Binding is JAX-WS/JAX-B. E.g. this is the case of an Outside-In EJB (Generated out of the WSDL). According to JAX-WS Spec the @WebService annotation on the implementation class or on an SEI together with the WSDL fully defines the mapping.

         Currently there is no normative statement in any of the SCA spec regarding relationship between @Service, @WebService, interface.wsdl and binding.ws. W/o this, using a JAX-WS based binding is vendor specific. So we need to spend efforts in defining those items as a precondition.


Case 2:

         Implementation is an EJB and required Data Binding is SDO. The EJB takes Static or Dynamic SDO. Service uses interface.wsdl.

         In this case there is no definition at all how interface.wsdl will map to SDO. Cases like Document-style unwrapping, In-Out parameters (Holders), Exception handling are left to the vendor as a whole. Again a cross-spec effort needs to be done to define the scenario E2E.


Case 3:

         Setup is same as Case 2 (e.g. a prerequisite is that Case 2 is solved).

         The focus is now on management of the SDO Helper Context. This can be done either by the SCA Runtime, or by the Implementation Provider, or by the actuall Implementation. In all cases a property has to exist which defines the expected behavoir. And in the case where HC is managed by the Impl, the interface between the SCA Runtime and the Impl has to be defined - how SCA Runtime will obtain the HC and what would be the lifecycle of this HC


Case 4:

         Implementation is a generic process in some BPM Impl Provider. Compared to the previous cases - where the Java Class could eventually be retrieved by the Impl Provider (even if this isn't normatively defined) - in this case there is no class. The options here are either the Impl Provider to supply information about the expected binding, or to preset the binding information in the SCDL. This is a quite common case for future Implementation Providers - and I am not aware of having something normatively defined.

Case Etc.:

         There are lot's of other cases that may make sense elaborating before comming to a normative solution and in any case time is not enough to define them, as well as the spec focus was in a different direction up to now (Callbacks etc..)

         Just to name a few interesting data binding areas:

o   Having a Stream as input (e.g. for a rubust management of cases where input is 100, 500, 1000+ MB).

o   Binding.sca - e.g. in case a Reference calls a Service in the local environment - to define a way how to avoid data binding and reuse whatever SDO or JAXB was used by the reference.

o   Maybe there are also others that are worth addressing.


I hope I could express the reasoning behind our proposal that this issue cannot be resolved right now, and whatever solution we try to push needs to be alligned with all the other related specs.


Regards, Vladimir


From: Barack, Ron [mailto:ron.barack@sap.com]
Sent: Saturday, 21. February 2009 17:03
To: David Booz; sca-j@lists.oasis-open.org
Subject: [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,




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

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


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




02/20/2009 06:48 AM


[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,


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