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


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

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

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


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.


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


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

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