Re: [sca-assembly] NEW ISSUE: (v1.2) Some way to "late bind" references toglobal domain channels

Logged as:  http://www.osoa.org/jira/browse/ASSEMBLY-259

Yours, Mike

Dr Mike Edwards
 Mail Point 146, Hursley
Park

STSM
 Winchester, Hants SO21
2JN

SCA & Services
Standards
 United Kingdom

Co-Chair OASIS SCA
Assembly TC
 

IBM Software Group
  

Phone:
+44-1962 818014
  

Mobile:
+44-7802-467431 (274097)
  

e-mail:

  

 

 

From:
Eric Johnson <>

To:
OASIS SCA Assembly <>

Date:
15/02/2011 01:23

Subject:
[sca-assembly] NEW ISSUE: (v1.2) Some
way to "late bind" references to global domain channels

Title: Some way to "late bind" references to
global domain channels

Target: Assembly 1.2 WD 03

Description:

Define some way that a composite can "late bind" references to
global domain channels (GDCs) on the @targets of producers and @sources
of consumers.

Scenario A: A company that has multiple SCA domains - perhaps as a consequence
of acquisition, or perhaps for testing and deployment purposes. However,
they may want to deploy the same or similar SCA composites to each of those
domains (as part of implementation.composite). However, for historical,
management, or implementation reasons the GDCs have different names in
the different environments. To reduce the amount of "wiring"
of producers and consumers that needs to be done when actually deployed,
it would be significantly easier to simply "late-bind" references
to GDCs.

Scenario B: A third-party developer of SCA composites defines two or more
composites that can be deployed to an SCA eventing environment. To leverage
eventing, said composites might most easily reference GDCs, such that when
two or more of the composites from the third-party are deployed, they start
communicating with each other as intended, and yet the manager of the domain
can simultaneously guarantee that the requisite GDCs do not conflict with
other uses already deployed.

Proposal:

(Note that this particular issue is a subset of the problems encompassed
by ASSEMBLY-227, so a solution there could equally well apply here, but
barring a solution to that which we can agree upon...)

In the abstract:

As per scenario B, the third-party developer is likely to want to refer
to a well-known "subject/channel/topic" as developed by the third-party.
In traditional naming scenarios, this is typically done with an XML QName,
as in a WSDL portType, or an XML Schema ComplexType. To that end, the third
party wants to define:

1.        a
logical QName, exposed as part of the componentType of a composite, that
an assembler can bind to a particular GDC

2.        a
short-hand label that can reference the construct in the @source or @target
attribute

3.        a
binding between that short-hand label and the logical QName.

At least when it comes to #3, a logical choice for the
short-hand label that makes #3 a no-op, is the "prefix:NCName"
syntax common in XML.

A composer, confronted with this extra thing in the componentType, needs
a way to bind said QName to a particular channel.

In referring to said logical reference, the @source or @target attribute
can do something like:

$tpns:global.channel.one

(tpns - abbreviation for third-party name space)

Since the "$" cannot be used in an NCName, this doesn't conflict
with "private" channel references. Further, "/" is
used to reference GDCs, so this syntax is not in conflict with that either.

-Eric.

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