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,
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
"Pavlov, Plamen" ---02/20/2009 06:48:15 AM---Hi
Folks, Taking into account the short time frame till the public review and the
|
|
|
|
|
|
|
|
|
|
|
|
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