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