OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oasis-charter-discuss message

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


Subject: RE: [oasis-charter-discuss] All these OASIS Service Component Architecture for XXXX language...


Title: Message
David,
 
SCA standardizes both the metadata related to the "<-->" in the "BPEL <--> Spring>" composition, as well as how each component technology (BPEL, Spring, etc) can expose the SCA metadata. The latter is what is aimed by the language binding specifications. Without standardizing how SCA components can be developed in each of the language/platform environment, we are leaving a wide gap open that may potentially be filled by each vendors in a proprietary manner. Where as by standardizing the SCA implementation technologies in Java, BPEL, Spring, etc, we are making it easier to adopt SCA in these environments (portability of skills) and also enabling portability of the SCA based compositions.
 
-- Sanjay


From: Martin Chapman [mailto:martin.chapman@oracle.com]
Sent: Thursday, Jul 05, 2007 6:25 AM
To: 'David RR Webber (XML)'; 'Michael Rowley'
Cc: oasis-charter-discuss@lists.oasis-open.org; 'Poulin,Michael'; mary.mcrae@oasis-open.org
Subject: RE: [oasis-charter-discuss] All these OASIS Service Component Architecture for XXXX language...

Please let us not confuse the architecture with the way we have structured into TCs. Whether its all in one TC or across multiple TCs is an administrartive decision.
 
Martin.
-----Original Message-----
From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: Tuesday, July 03, 2007 6:56 PM
To: Michael Rowley
Cc: oasis-charter-discuss@lists.oasis-open.org; Poulin,Michael; mary.mcrae@oasis-open.org
Subject: RE: [oasis-charter-discuss] All these OASIS Service Component Architecture for XXXX language...

Michael,
 
Ok - thanks for that insightful reply.  However - conceptually I'm still not buying this!  I've always worked on the premise that you specify the APIs and the touch point BETWEEN the components - and not the internal workings of the components themselves!?!
 
Therefore in the BPEL <-> Spring case - those internal details would be implementer specific - but the <-> would conform to the overall SCA.  Otherwise each time you need to define a new SCA!?!  E.g. if I build the <-> once - I should be able to connect to any other <-> compatible language - without also having to create it over again?
 
Somehow - if we are not able to do that - it would appear that we have failed before we even start?
 
Thanks, DW

"The way to be is to do" - Confucius (551-472 B.C.)


-------- Original Message --------
Subject: RE: [oasis-charter-discuss] All these OASIS Service Component
Architecture for XXXX language...
From: "Michael Rowley" <mrowley@bea.com>
Date: Tue, July 03, 2007 1:30 pm
To: "Poulin,  Michael" <Michael.Poulin@uk.fid-intl.com>,  "David RR
Webber (XML)" <david@drrw.info>,  <mary.mcrae@oasis-open.org>
Cc: <oasis-charter-discuss@lists.oasis-open.org>

David and Michael,
SCA is intended to provide a fairly complete set of technologies that make it possible to develop, configure and deploy service-based applications using multiple languages. Some of the pieces of this picture, such as assembly and policy, can be created in a way that is independent of the language that is used for developing components.
However, the components themselves must be developed using some language. How development in each language looks is designed to be as simple as possible, where one way to achieve this simplicity is to use mechanisms that are natural for the language in question. This implies that we need language-specific TC's that design the programming model for creating SCA components with that language.
Therefore, to achieve portability and to simplify the development of SCA compliant components using the various, popular languages/platforms, SCA defines mappings of the SCA concepts and the language-neutral syntax to the native model/syntax of individual language/platforms. In some cases, the applicable mappings may be relatively simple and short. However, in other cases, especially where the development platforms are complex and rich in functionality (e.g. Java EE, Spring), mapping of SCA to the native concepts and syntax involves significant amount of work.
To make this concrete, you can look at the SCA specifications that describe the programming model for the first three languages tackled: Java, C++ and BPEL, and for the the first development platform: Spring.
You can see from these specifications, that the programming models are sufficiently large and different (especially BPEL's) that it would be difficult to try to create a single specification that represented all three programming models in a way that the specialization for each language could just be a short appendix.
We also want to provide more than just "non-normative guides".  It is important that developers be able to create SCA components for each of these languages in a way that will be portable between different implementations of SCA.
Michael Rowley

From: Poulin, Michael [mailto:Michael.Poulin@uk.fid-intl.com]
Sent: Tuesday, July 03, 2007 5:09 AM
To: David RR Webber (XML); mary.mcrae@oasis-open.org
Cc: oasis-charter-discuss@lists.oasis-open.org
Subject: RE: [oasis-charter-discuss] All these OASIS Service Component Architecture for XXXX language...

Hi Mary,

I also was surprised a little with the separation right away. I thought it might be a core SCA TC in the beginning continued with sub-TC for 'platform' porting later on.

Cheers,

- Michael Poulin


From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: 02 July 2007 15:46
To: mary.mcrae@oasis-open.org
Cc: oasis-charter-discuss@lists.oasis-open.org
Subject: [oasis-charter-discuss] All these OASIS Service Component Architecture for XXXX language...

Mary,

Is it just me - but I thought the whole point of SCA was that there is a common consistent approach - that is language agnostic - and that you should not need a TC for every language out there implementing SCA...

Rather - from the base SCA work - you should be able to develop simple Appendices - for BPEL, Java, C++, VB, Delphi, Ruby, SQL et al as non-normative guides.

Am I missing something here?  Or is this really just a case of everyone deciding they have to own their own little patch of the turf?!?

DW

"The way to be is to do" - Confucius (551-472 B.C.)




-------- Original Message --------
Subject: [members] Proposed Charter for OASIS Service Component
Architecture for Java(tm) (SCA J) Technical Committee - 4 of 6
From: "Mary McRae" <mary.mcrae@oasis-open.org>
Date: Mon, July 02, 2007 9:17 am
To: <members@lists.oasis-open.org>,  <tc-announce@lists.oasis-open.org>
Cc: <oasis-charter-discuss@lists.oasis-open.org>,
<opencsa-ms@lists.oasis-open.org>

To OASIS Members:
 
  A draft TC charter has been submitted to establish the OASIS Service
Component Architecture for Java(tm) (SCA J)
Technical Committee. In accordance with the OASIS TC Process Policy
section 2.2: 
(http://www.oasis-open.org/committees/process.php#2.2) the proposed
charter is hereby submitted for comment. The comm
ent
period shall remain open until 11:45 pm ET on 16 July 2007. 
 
  OASIS maintains a mailing list for the purpose of submitting
comments on proposed charters. Any OASIS member may post
to this list by sending email to:
mailto:oasis-charter-discuss@lists.oasis-open.org. All messages will
be publicly archived at: 
http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members
who wish to receive emails must join the group by
selecting "join group" on the group home page:
http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/.
Employees of organizational members do not require
primary representative approval to subscribe to the
oasis-charter-discuss e-mail.
 
  A telephone conference will be held among the Convener, the OASIS TC
Administrator, and those proposers who wish to
attend within four days of the close of the comment period. The
announcement and call-in information will be noted on
the OASIS Charter Discuss Group Calendar.
 
  We encourage member comment and ask that you note the name of the
proposed TC (SCA-J) in the subject line of your
email message. 
 
Regards,
 
Mary
 
---------------------------------------------------
Mary P McRae
Manager of TC Administration, OASIS
email: mary.mcrae@oasis-open.org  
web: www.oasis-open.org
phone: 603.232.9090
 
 
===========
PROPOSED CHARTER FOR REVIEW AND COMMENT
 
OASIS SERVICE COMPONENT ARCHITECTURE FOR 
JAVA(TM) TC
1. Normative informati!
 on
a. Name
OASIS Service Component Architecture for Java(tm) (SCA J) Technical
Committee
 
Member Section Affiliation
Open CSA Member Section
 
b. Statement of Purpose
The purpose of the OASIS SCA-J Technical Committee (TC) is to develop
specifications that 
standardize the use of the use of Java(tm) technologies within an SCA
domain.  This TC is part of 
the Open-CSA member section and its work must be coordinated w!
 ith the
work of the other TCs 
in the member section.
The TC will define:
*  APIs and annotations that facilitate the declaration and use of SCA
constructs from Java.  
*  A Java-based programming model for creating SCA component!
 
implementations that 
depends only on Java Standard Edition, version 5 or greater.
*  A Java-based programming model for creating SCA component
implementations that use 
the technologies of the Spring Framework Core. 
*  Mechanisms that allow an SCA domain to use and interoperate with
constructs defined 
by Java Enterprise Edition, enabling the following scenarios:
1. Accessing EJB session beans that have been deployed to JavaEE
runtimes through SCA 
references that use an EJB-specific binding.
2. Providing SCA services through an EJB session!
  bean binding.
3. Consumption of SCA-exposed services from Java EE components in an
SCA-aware 
JavaEE runtime.
4. Use of Java EE components as Service Component Implementations.
5. Use of recursive SCA assembly in Java EE applications.
6. Use of Java EE modules as Service Component Implementations.
The work of this committee will be based the following specifications,
submitted to the TC as a 
reference:
*  SCA Java Component Implementation Specification
*  SCA Java Common Annotations and APIs
*  SCA Spring Component Implementation
*  SCA EJB(tm) Session Bean Binding
 
c. Scope
The scope of this TC includes work to define any of the following:
*  Java annotations and API'sfor declaring, using or configuring any
SCA-related construct.
*  Java API's for accessing and manipulating data that is associated
with the runtime 
context of an SCA component or client.
*  A Java-based programming model for creating SCA component
implementations that 
depends only on Java Standard Edition, version 5 or greater.
*  A 
Java-based programming model for creating SCA component
implementations that 
use the technologies of the Spring Framework Core. 
*  An EJB session bean binding that allows access to services that are
deployed as 
JavaEE EJBs or to make SCA services available as EJBs.
*  Java-specific characteristics of the packaging format used for an
SCA contribution that 
may be deployed to Java-based runtimes. 
*  Mechanisms for resolving Java class names, QNames and other artifact
references 
within a Java-based SCA runtime.  Such a mechanism may make use of
existing 
standardized artifact resolution mechanisms.
*  Annotations for standard policy intents that may be used by
components in a Java-
based SCA runtime.
The following additional in-scope items relate to the development of a
specification for the 
integration of SCA with Java EE:
*  SCA implementation types for components of Java EE programming models:
1. Web Components
2. EJB Components
a. Session Beans
b. Message-Driven B!
 eans
c. JAX-WS annotated session beans
3. JAX-WS Components
4. JCA Resource Adapter Components
*  SCA implementation types for Java EE module types, such as EJB JARs
and EARs.
*  SCA deployment for Java EE
1. For Enterprise Application packages (.ear)
2. For single module packages (ejb-jar, .war, .rar)
*  The use of SCA assembly:
1. Within the deployment package that can be used with JavaEE
2. Over existing packages within the SCA Domain
*  Definition of the relationship!
  between policy equivalents in Java EE
< PRE style="MARGIN-LEFT: 0.5in">and the SCA policies
framework
*  Defining constructs for accessing SCA components from Java EE
presentation tier 
technologies.
 
Out of Sco!
 pe 
The following is a non-exhaustive list. It is provided only for the
sake of clarity. If some function, 
mechanism or feature is not mentioned here, and it is not mentioned in
the Scope of Work section 
either, then it will be deemed to be out of scope.
The TC will not define Service Provider Interfaces (SPIs)
 that may be
used to extend a Java 
based SCA runtime.
The TC will not define APIs that modify the contents of an installed
composite definition.
The TC will not define API's related to managing a Java-based SCA
runtime, including:
*  Java APIs for initiating and shutting down a runtime that can host
SCA components or 
clients.
*  Java APIs associated with the deployment of SCA components
(including composites).
The TC will not define new SCA implementation types, other than!
  those
<
FONT face="Courier New" size=2>mentioned in the in-
scope section.
The TC will not define SCA intents or policy sets.  
The TC will not define any wire-level protocols.
The TC will not define a mapping of user-defined data formats (in XML
or otherwise) into or out of 
Java constructs.
 
Upwards Compatibility
 
There are no formal requirements for upwards compatibility from the
input documents to 
this TC. This is to ensure that the TC has m!
 aximum freedom of action
in defining the 
OASIS standard. However it is recognized that there will be early
implementations in the 
marketplace based upon these input documents and careful consideration
must be applied 
to any change of feature/function that would cause incompatibilities
in the OASIS 
standard at:
 
*  Source Code level
*  Compiled Object Code
*  XML data definitions
 
At minimum, known enhancements to the input documents that will cause
compatibility 
issues with early implementations in the marketplace will be specified
in a chapter in the 
specification offering migration guidance.
 
Conformance
 
In line with the OASIS TC process, the TC will produce normative
conformance information 
describing the normative characteristics of the specification and
specific statements about what 
an implementation must!
  do to conform to the specification, and what
aspects are optional (if any).
 
 
Test Suite
 
The TC will produce a test suite which can be used to test conformance
to the spec!
 ification which 
will include:
 
1. A series of valid and invalid test cases which cover as much as is
practical of the 
conformance statements of the specifications produced by this TC, with
a description of 
each of the artifacts involved, constraints on the environment, the
test case 
characteristics and their expected behavior.
 
2. Example bindings may form part of the test suite, and are only
provided as working 
sa!
 mples which can be replaced by other specific bindings.
 
The Test Suite shall be packaged separately from the specifications
produced by the TC and will 
contain a set of materials including but not limited to SCA composite
and related SCA files, Java 
files, WSDL files, XSD files.<
/PRE>
 
The TC shall develop the test suite in collaboration with other TCs
within the Open-CSA Member 
Section.
 
The following material should be considered as best practice for the
preparation of 
conformance and test suite materials:
*  From OASIS: material on specification conformance statements: 
http://www.oasis-open.org/committees/download.php/305/conformance_requirements-v1.pdf
 
 
*  From the W3C, material on specification variability, test metadata &
specification clarity: 
http://www.w3.org/TR/2005/NOTE-spec-variability-20050831/  
http://www.w3.org/TR/2005/NOTE-test-metadata-20050914/  
http://www.w3.org/TR/qaframe-spec/
 
d. Deliverables
The TC has the following set of deliverables.
*  A revised SCA Java Component Implementation Specification.
*  A revised SCA Java Common Annotations and APIs Specification
*  A revised SCA Spring Component Im
plementation Specification
*  A revised SCA EJB Session Bean Binding Specification.
*  A specification that standardizes SCA integration with Java EE
These specifications will reflect refinements, corrections or material
technological improvements 
with respect to the input documents and in accordance with this charter.
Ratification of the above specifications as OASIS Standards, including
a brief period to address 
any errata, will mark the end of the TC's lifecycle.
The TC may choose to vary the number of the specification documents
and their titles.
 
Exit Criteria
 
The TC shall define concrete exit criteria that include at least two
independent offerings 
that implement and are compliant with the all normative portions of
specifications and 
demonstrate interoperabilit!
 y and portability as appropriate. Note that
these are minimums 
and that the TC is free to set more stringent criteria.
 
Maintenance
 
Once the TC has completed work on a deliverable and it has become an
OASIS standard, 
the TC will enter "maintenance mode" for the deliverable.
 
The purpose of maintenance mode is to provide minor revisions to
previously adopted 
deliverables to clarify ambiguities, inconsistencies and obvious
errors.  Maintenance 
mode is not intended to enhance a deliverable or extend its
functionality.
 
The TC will collect issues raised against the deliverables and
periodically process those 
issues.  Issues that reques!
 t or require new or enhanced functionality

shall be marked as 
enhancement requests and set aside.  Issues that result in the
clarification or correction of 
the deliverables shall be processed.  The TC shall maintain a list of
these adopted 
clarifications and shall periodically create a new minor revis!
 ion of
the deliverables 
including these updates.  Periodically, but at least once a year, the
TC shall produce and 
vote upon a new minor revision of the deliverables.
 
e. IPR Mode
 
The TC will operate under the RF on Limited Terms mode under the OASIS
IPR Policy.
 
f. Anticipated Audience
The anticipated audience for this work includes:
*  Vendors offering Java-based SCA runtimes;
*  Other specification authors that need Java APIs and annotations for
SCA constructs.
*  Software architects and programmers, who design, write or integrate
SCA applications.
 
g. Language
TC busi
ness will be conducted in English.
 
 
2. Non-normative information regarding the startup of the TC
 
a. Related and similar work
 
The SCA specifications are intended to encompass a range of
technologies which are 
useful in implementing service-oriented solutions.  These include the
range of Web-
services related specifications such as WSDL and SOAP, the various
WS-Security 
specifications, WS-Addressing,
 WS-Notification. The list is extensive
and there is no 
limit to the relevance of these specifications to SCA.  SCA does not
intend to replace 
these specifications, but to build upon them.
 
Other existing technologies such as Java E!
 nterprise Edition, the
Spring Framework and 
CORBA also have a relationship to SCA and SCA anticipates optionally
using these in 
relevant parts of the specifications (eg to define specific
implementation types for 
artifacts such as JEE EJBs a!
 nd Spring application contexts).
 
 
b. Proposed date, time, and location of first TC meeting
 
Date: Sept 6
Time: 13:00 EDT
Duration: 1 hour
Mode: Teleconference
Telephone: Dial-in TBC, along with e-Meeting facilities
Sponsor: SAP
 
 
Date: Sept 18
Time: 09:00 EDT
Duration: 3 days (in parallel with F2F meetings of other TCs
affiliated with this member 
section)
Mode: F2F meeting in East-Coast USA location (location TBC)
Telephone: Dial-in TBC, along with e-Meeting facilities
Sponsor: SAP
 
c. On-going schedule
 
Weekly 60 Minute teleconferences sponsored by TBC.
Time TBC by the TC.
 
It is anticipated that the committee will meet face-to-face once every
quarter at a date and 
venue to be decided by the TC, but with a commitment to hold meetings
in different 
regions of the world so as to share the effort of travel.
 
d. Supporters:
 
The following eligible individuals are in support of this proposal:
 
Michael Rowley, BEA, mrowley@bea.com
Michael Beisiegel, IBM, mbgl@us.ibm.com
Jim Marino, BEA, jmarino@bea.com
Anish Karmarkar, Oracle, anis
h.karmarkar@oracle.com
Henning Blohm, SAP, henning.blohm@sap.com
Ron Barack, SAP, ron.barack@sap.com
Adrian Colyer, Interface21, adrian.colyer@interface21.com
Scott Vorthmann, TIBCO, scottv@tibco.com
Dave Booz, IBM, booz@us.ibm.com
Mike Edwards, IBM, mike_edwards@uk.ibm.com
Peter Peshev, SAP, peter.peshev@sap.com
Peter Walker, Sun Microsystems, peter.walker@sun.com
Glen Daniels, Progress, gdaniels@progress.com
Kimberly Palko, Progress,  k
palko@progress.com
 
e. Convener:
 
Henning Blohm, SAP, henning.blohm@sap.com
 
f. Name of Member Section to which this TC is Affiliated
 
Open CSA member section.
 
g. Anticipated contributions
 
It is expected that the following SCA Specifications, Version 1.00, as
published in March 
2007 will be a contributions from the Open SOA Collaboration:
 
*  SCA Java Common Annotations and APIs 
*  SCA Java Component Implementation
*  SCA Spring Component Implementation
 (see [2]), along with references to the other SCA Version 1.00
specifications (see [2]), 
plus any work performed by the Open SOA collaboration between March
2007 and the 
start of the work of the SCA-Assembly TC.
 
h. Draft FAQ Document
 
Intentionally left empty.
 
i. Proposed working title
 
SCA Java Component Implementation Specification.
SCA Java Common Annotations and APIs Specification
SCA Spring Comp!
 onent Implementation Specification
SCA EJB Session Bean Binding Specification.
SCA Java EE Integration Specification
 
 
References
[1] Service Component Archtecture Assembly Specification Version 1.0
http://www.osoa.org/download/attachments/35/SCA_AssemblyModel_V100.pdf
 
[2] Service Component Architecture Version 1.0 Specifications
http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications
 
Java and all Java-based trademarks are trademarks of Sun Microsystems,
Inc. in the 
United States, other countries, or both.
 
 
 

 
 
---------------------------------------------------------------------
 
This email list is used solely by OASIS for official consortium
communications.
 
Opt-out requests may be sent to member-services@oasis-open.org,
however, all members are strongly encouraged to maintain a
subscription to this list.
 


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