sca-j message
[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
- From: Simon Nash <NASH@uk.ibm.com>
- To: sca-j@lists.oasis-open.org
- Date: Thu, 10 Jul 2008 12:21:54 +0100
Vladimir,
Many thanks for your offer to help with
JAVA-2. I will schedule this discussion for the F2F meeting next
week. If you can come with a proposal or at least some ideas for
discussion, that would be great.
Thanks also for the new issues you have
brought forward. These need to be submitted to the sca-j list in
a specific format, as follows:
- - - - - - - - - - - - - - -
The subject line of the email should
be: NEW ISSUE: <a brief title for the issue>
The body of the email should contain
the following sections:
TARGET: <name of the specification
affected, with section numbers if possible>
DESCRIPTION:
<One or more paragraphs describing
the issue. This should focus on describing the problem (why do we
need to make a change) rather than on a proposed solution.>
PROPOSAL:
<(optional) a proposed resolution
for the issue>
- - - - - - - - - - - - - - -
An example can be found at http://lists.oasis-open.org/archives/sca-j/200806/msg00001.html
Please send 3 separate emails in the
above format for the 3 issues that you would like to raise. For each
of these, the TC will vote on whether to open the issue.
<my personal opinion>
I think the descriptions in the first
2 issues are detailed enough for the issues to be opened. However,
I think the third issue needs more detail before it can be opened, perhaps
with some examples of what the problems are.
</my personal opinion>
Simon
Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156 Fax +44-1962-818999
"Savchenko, Vladimir"
<vladimir.savchenko@sap.com>
10/07/2008 08:27
|
To
| Simon Nash/UK/IBM@IBMGB, <sca-j@lists.oasis-open.org>
|
cc
|
|
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
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]