Re: [sca-bindings] Proposed resolution for BINDINGS-102

[Mike Edwards <mike_edwards@uk.ibm.com>]

Simon,

This seems fine to me.

Perhaps another simple approach would
be to make a declaration right at the start of the specification that it
depends on the
SCA Assembly and SCA Policy specifications
and that much of the terminology used in the bindings specifications is
defined
in those other specifications.


Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

From:	Simon Holdsworth/UK/IBM@IBMGB
To:	sca-bindings@lists.oasis-open.org
Date:	11/12/2009 11:36
Subject:	[sca-bindings] Proposed resolution for BINDINGS-102

---

Overview: 

This issue was raised as a result of a public review comment regarding
the use of terms such as "composite", "reference" and
"service" without any definition. 

The alternatives here are to include a definition of these terms out of
line in the document, or to define them on first use.

Currently they are used in the abstract and introduction of the JCA binding
without definition, so my preference would be to simply update the abstract
and introduction to state that these are defined in the assembly spec and
leave the rest of the text as is.  The only question I have is whether
its OK to use a reference in the abstract, when the reference is actually
defined somewhat further down in the document.  There's also a lot
of redundant and irrelevant text in the abstract so I've cleaned it up.

As a side note this issue was raised against the JCA binding document,
but this resolution has no changes to the normative behaviour.  If
this resolution is acceptable, I would propose that we open editorial action
items against the web service and JMS binding specifications to ensure
that "reference", "service", "composite",
"component", "interface", "bidirectional",
"intent", "mayProvide", "alwaysProvides"
at least include a reference to SCA-Assembly or SCA-Policy on first mention.

Detail: 

Update the abstract from: 

This document presents bindings describing access and connectivity to the
services provided by the Enterprise Information System (EIS). 
This version of the document describes JCA Bindings thus narrowing connectivity
down to the connectivity to the EIS system external to the SCA system,
based on the Java EE Connector Architecture specification and implemented
in Java. 
Further specification is necessary to define EIS Bindings between different
SCA runtimes within SCA system, for example J2EE and EIS based runtimes.
The binding specified in this document applies to the composite’s references
and services. 
... 

To: 

This document specifies the means by which SCA composites and components,
as defined in the SCA Assembly Specification [SCA-Assembly], connect to
and access services provided by Enterprise Information Systems (EIS). The
connectivity is based on the Java EE Connector Architecture (JCA) specification
version 1.5 [JCA15], and is provided via a binding.jca element which applies
to the references and services of an SCA composite or SCA component.
... 

Update the introduction to replace the same text by the same new text,
replace: 

This binding places no requirement to support bidirectional interfaces,
SCA runtimes can implement support for bidirectional interfaces via extensions.

by: 

This binding places no requirement on SCA runtimes to support bidirectional
interfaces as defined by the SCA Assembly Specification [SCA-Assembly],
SCA runtimes can implement support for bidirectional interfaces using extensions
to the binding element. 

Update the section on policy (section 3) to be clear, and consistent with
binding.ws, by replacing: 

This JCA Binding specification does not support intents such as mayProvide
or alwaysProvides as JCA Specification does not define generic Resource
Adapter characteristics that could be set using intents.

With: 

The JCA Specification [JCA15] does not define generic Resource Adapter
characteristics that could be set using standard policy intents as defined
in the SCA Policy Specification [SCA-Policy]. This specification places
no requirements on the intents that are listed as either @alwaysProvides
or @mayProvides in the bindingType for binding.jca.

Regards, Simon 

Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair,
AT&T and Boeing Lab Advocate
MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
Internet - Simon_Holdsworth@uk.ibm.com

---

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