RE: [oasis-charter-discuss] All these OASIS Service Component Arc hitecturefor XXXX language...

Michael,

I believe that the SCA Assembly and
SCA Policy specifications do provide the language-neutral description of

SCA that allows ease of porting of the
SCA model to new languages and new platforms that you describe in your

email.

These two specifications describe the
general features of SCA that must be considered when creating a definition

of a new SCA implementation type (ie
for components written in some language or using some platform).

The individual language specifications
then describe the details of the model in that language - for example,
how

existing concepts in the language map
to SCA and how SCA artifacts map to the language.  It may also define

extensions to the language or to the
platform that make things simpler and easier for the programmer.

So, on the one hand, the SCA BPEL specification
is short and simple, with most of the document concentrating on

how BPEL partner links map to SCA services
and references.  There are a couple of extensions to BPEL described

that provide a means to map SCA properties
to BPEL processes, but these are few and simple.

On the other hand, the SCA Java specification
is much larger.  It does describe a very simple mapping of Java

POJOs to SCA.  However, it also
describes a Dependency Injection mechanism, plus a set of APIs for getting

more detail contextual information for
advanced users.  The spec also provides a set of language-specific

annotations which are used to provide
inline metadata about the Java component that make the mapping to

SCA clearer and which reduce the amount
of metadata that has to be specified in separate XML files.  Most

of the details of the SCA Java specification
are not mandated directly by the SCA Assembly and SCA Policy

specifications - but they are provided
to give the Java programmer a simple and natural experience in

developing service components.

In preparing the various SCA specifications
in the Open SOA collaboration, we certainly found it useful to 

split the specifications in the way
that we propose for OASIS.  There are very different considerations
and

skills involved in building the SCA
language specifications from the SCA Assembly and SCA Policy specifications

and the membership of the teams working
on the different specifications turned out to be quite different in

most cases.  In addition, some
of the langauge working groups turned out to have a lot of work to do -
the Java

language team had to develop a plain
"Java POJO" specification, then tackle Spring, Java EE and also
handle

JAX-WS, since all of these platforms/frameworks
are used to build components in the Java language - and

each has its unique twists in terms
of connection to SCA.

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.

IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.

Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  

Email:  

"Poulin, Michael"
<> 

04/07/2007 09:22

To

Michael Rowley <>,
"Poulin, Michael" <>, "David
RR Webber (XML)" <>, 

cc



Subject

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

Michael,

 

I am absolutely agree with you
in 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".
My initial message was driven by the question like this: taking in consideration
complexity and specifics of target platforms and languages, will the SCA
standard allow ease porting of the architecture from one platform/language
onto another (like CORBA IDL)? That is, I am talking about a meta-model
of the component architecture that might be "put on the ground"
depending on available/preferable execution environment (where the environment
is quite platform/language specific).

 

- Michael Poulin

From: Michael Rowley [mailto:]

Sent: 03 July 2007 18:30

To: Poulin, Michael; David RR Webber (XML); 

Cc: 

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

 

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

Sent: Tuesday, July 03, 2007 5:09 AM

To: David RR Webber (XML); 

Cc: 

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

Sent: 02 July 2007 15:46

To: 

Cc: 

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" <>

Date: Mon, July 02, 2007 9:17 am

To: <>,  <>

Cc: <>, 

<>

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 comment

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:.
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

oas!

 is-chart

er-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: 
 

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 information

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 

s!

 tandardi

ze 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 with the

work of the other TCs 

in the member section.

The TC will define:

*  APIs a!

 nd 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

!

 !

 implemen

tations 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!

  Compone

nt 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 c!

 omponent

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 E!

 JB session bean binding that allows access to services that ar!

 e

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 n!

 ames, 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

compo!

 nents 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 Beans

c. JAX-WS annotated session beans

3. JAX-WS Components

4. JCA Resource Adapter Components

*  SCA implementation types for
Java EE module typ!

 es, 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

and the SCA policies 

framework

*  Defining constructs for accessing
SCA components from Java EE

presentat!

 ion tier

 

technologies.

 

Out of Scope 

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

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 maximum freedom of action

in defining the 

OASIS standard. However it is recognized
that there will be early

implementations in the 

marketplace based !

 upon the

se 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 specification 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 

samples 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.

 

The TC shall develop the test suite
in collaboration with other TCs

within the Open-CSA Member 

Se!

 ction.

 

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/
 !

 <

/FONT>

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
Implementation Specification

*  A revised SCA EJB Session Bean
Binding Specification.

*  A specification that standardizes
SCA integration with Java EE

These specifications will reflect refinement!

 s, corre

ctions 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 interoperability 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 request 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 revision 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 business 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 r!

 eplace 

these specifications, but to build upon them.

 

Other existing technologies such as
Java Enterprise 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 and 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, 

Michael Beisiegel, IBM, 

Jim Marino, BEA, 

Anish Karmarkar, Oracle, 

Henning Blohm, SAP, 

Ron Barack, SAP, 

Adrian Colyer, Interface21,!

  

Scott Vorthmann, TIBCO, 

Dave Booz, IBM, 

Mike Edwards, IBM, 

Peter Peshev, SAP, 

Peter Walk!

 er, Sun Microsystems, 

Glen Daniels, Progress, 

Kimberly Palko, Progress,  

 

e. Convener:

 

Henning Blohm, SAP, 

 

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-Assembl!

 y 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 Component 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.

 

 

 

 

 

---------------------------------------------------------------------

 

Th

is email list is used solely by OASIS for official consortium

communications.

 

Opt-out requests may be sent to ,

however, all members are strongly encouraged
to maintain a

subscription to this list.

 

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

image001.gif