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

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

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:	mike_edwards@uk.ibm.com

From:	Eric Johnson <eric@tibco.com>
To:	OASIS SCA Assembly <sca-assembly@lists.oasis-open.org>
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