[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-j] Call for volunteers to help resolve SCA-J issues
+1 on your issue 1
issue 2 - I am attempting to address that with a proposal I submitted for
existing issue JAVA-1, so this may be a duplicate.
I agree with Simon that I would also need some more info on your third
issue to help me understand it.
Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com
"Savchenko,
Vladimir"
<vladimir.savchen To
ko@sap.com> "Simon Nash" <NASH@uk.ibm.com>,
<sca-j@lists.oasis-open.org>
07/10/2008 03:27 cc
AM
Subject
RE: [sca-j] Call for volunteers to
help resolve SCA-J issues
Hi Simon,
I would like to handle this one:
JAVA-2 Determining the data binding to use (e.g. JAXB or SDO)
Currently we are in the middle of the implementation of our SCA based
framwork, and it turns out is is a real problem, when those different
technologies collide (esp. now while SDO does not yet have the concept of
JAXB <> SDO bridging defined). Currently this is one of the most critical
issues for us that prevent us from going the straight-forward way and use
the spec as it is.
I would aslo like to use the opportunity to raise three additional issues
(sorry if this is not the right process, but i am still new, and the issue
is important :) ).
Issue 1
--------
IMO SCA-J and SCA-Bindigs specs have focused on the so called
“Inside-Out”-case. E.g. start with the Java Implementation, and then expose
it as web service. Most of the issues relate to this process, and most of
the examples are – “component with service with interface.java, promoted to
service on composite level with interface.wsdl”.
If I am mistaken – then I appologise myslef…
But – it seems that a more common scenario is when one starts with WSDL.
This would mean that “interface.java” does not need to be mentioned at all.
And we will have components with a Service element with ‘interface.wsdl’.
The SCA-J tells for this – just follow JAX-WS. But there are no examples.
And there are really intetresting cases. e.g..
-> Use JAX-WS and JAXB for data binding
-> Use JAX-WS and SDO for data binding
> Use Static SDO
> Use dynamic SDO
-> How to handle the WS Annotations coming from JSR 181,
and how are they related to the ones defined in SCA-J ?
I am not telling that the current spec does not address this topic. Just
that it may be enriched with more examples and made more formal, so that we
can reach some state of interoperability on this topi at some point of
time.
Issue 2
--------
Currently SCA is missing an API to do dynamic calls. E.g. assuming that
there is a framework that based on some metadata dynamically creates SDO
DataObjects, knows which is the SCA reference to be invoked, knows the
operation name. Then an API to do a dynamic call to this reference is very
convenient.
The SDO specification defines the so called Data Access Service entity,
which is an abstract entity used to call services. As far as I am aware –
the DAS API is not specified too formally.
Maybe the focus of SCA-J is not to have such APIs at the end. And leave it
as a vendor specific solution, but it would be interesting to discuss what
t do in such case.
Issue 3
--------
Somehow i get the feeling that the WSDL <> Java and integration with SCA
and SDO is not very well represented in the Spec. At least for me this is a
real problem. In the past, I’ve led the team at SAP that has implemented
JAX-RPC *, JAX-WS and some proprietary frameworks for WS Processing, and i
have an internal fear that if this is not tackled, a lot of problems may
arise at a later point of time, when this gets productive.
Regards, Vladimir
From: Simon Nash [mailto:NASH@uk.ibm.com]
Sent: Wednesday, 9. July 2008 17:44
To: sca-j@lists.oasis-open.org:
Subject: [sca-j] Call for volunteers to help resolve SCA-J issues
I'm looking for volunteers to help with proposals/ideas for resolving some
of the open issues in the SCA-J TC that don't currently have specific
proposals for resolution. It would be great if we could make progress on a
few of these at next week's F2F. Is anyone willing to offer to help with
any of the issues listed below that don't currently have a name attached?
What constitutes "help" can be very broadly defined :-)
The following are considered (by me) to be more straightforward:
JAVA-38 Inconsistent rules for the use of @reference annotation
JAVA-39 Incorrect example in Java Component Implementation Spec v1.00 -
Sec 1.2.4 (Anish)
JAVA-47 Missing description of what the @EagerInit annotation does.
JAVA-48 @Callback annotation does not feature in section on Interfaces
JAVA-49 Version requirements for SDO, JAXB and JAX-WS
The following are considered (by me) to be more controversial and/or
difficult:
JAVA-1 Accessing SCA Services from non-SCA component code
JAVA-2 Determining the data binding to use (e.g. JAXB or SDO)
JAVA-3 Local services expose implementation classes as their type
JAVA-6 @AllowsPassByReference requires more detailed description
JAVA-13 ComponentContext.getProperty(...) ill defined
JAVA-14 Conversation Attributes are not in Java Schema
JAVA-21 Clarify Request Scope lifetime
JAVA-25 Callback Simplification (Simon)
JAVA-27 Security Annotations in generated Component Type
JAVA-30 "Process" Scope
JAVA-37 Injection on private fields - or not
JAVA-41 Inconsistent method description for @Init and @Destroy annotations
JAVA-46 equals() method on ServiceReference and CallableReference
Simon
Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156 Fax +44-1962-818999
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]