Good question. I'm sure that if we get far enough through the rest of
the debate, that we can agree on an answer to this question. I can
think of a few alternatives off the top of my head:
- reference count and garbage collect, as you suggest
- coming up with a standard way to construct a URI for the 10.7.2 operation
- leave this as unstandardized as it shouldn't affect interoperability.
Danny
On 2/14/2011 3:45 PM, Anish Karmarkar wrote:
> There is one issue wrt auto-deploy that has not been discussed in this
> long thread that I wish to bring up: "garbage collection" of
> auto-deployed channels.
>
> Auto-deployed channels (obviously) don't require any explicit action
> to deploy channels other than deployment of a producer/consumer that
> uses that channel. In a dynamic SCA environment, the composites that
> contained the producer/consumer that led to the auto-deploy of global
> channels may be undeployed at some later time. This will leave the
> domain-level channels that no one is using (and possible will never
> use) intact. Since these channels were auto-deployed, it stands to
> reason that they should be auto-undeployed (or garbage collected).
> Especially, since the administrator does not have a composite to point
> to, to get rid of the auto-deployed channel using the Assembly "10.7.2
> remove from Domain-Level Composite" operation.
>
> -Anish
> --
>
> On 2/10/2011 2:48 AM, Mike Edwards wrote:
>>
>> Danny,
>>
>> I'm less about making arguments and more about trying to describe the
>> Event Processing ideas in the same terms that we
>> have already described for services in the current V1.1 specifications.
>> There, the spec does describe different styles of
>> runtime, with differing approaches to deployment and to the possibility
>> of redeployment.
>>
>> I tried to point out that auto-deployment carries an implication of
>> redeployment, since if the runtime auto-deploys some channel
>> for which there is actually a concrete channel supplied by some later
>> deployment, then we are inevitably into the realm of
>> redeployment.
>>
>> Redeployment of a channel is at the least a tricky thing. The same can
>> be said of the redeployment of a service component.
>> Basically, what happens to anything that is "in flight"? I was trying to
>> address some of these issues for auto-deploy channels in what I wrote.
>>
>>
>> Now, let me make my position clear on "auto deployment". I think that we
>> have similar behaviour applied in particular to PolicySets,
>> with the notion that in principle an SCA Runtime can have other
>> mechanisms to supply these things to the Domain, other than by
>> deploying the contents of one or more Contributions. eg there is the
>> concept of PolicySets being deployed from some kind of
>> Repository and not necessarily being held in any application
>> Contribution. The current specs don't disallow this, although they
>> deliberately don't say much about it since the possibilities for
>> implementation are very broad and there is little normative to say.
>> What it is - is outside the standards.
>>
>> So, I could envisage auto-deployment along the same lines. Something
>> that any SCA Runtime could choose to provide by some
>> means, but where the SCA specifications say very little. If an SCA
>> runtime chooses to provide auto-deployment, then it can do so
>> in any way it wishes.
>>
>>
>> The downside for an application developer is that their application, as
>> contained in a set of Contributions, may not work on some SCA
>> runtimes, if the developer/assembler chooses not to contain one or more
>> Domain Channels within their composites, that they rely on
>> in some components within the application. If they do this, then their
>> application may work fine on an SCA runtime that supports
>> auto-creation but fail when run with a runtime that does not support
>> auto-creation. The same is true, I note, of PolicySets - if the
>> application does not supply them, there is no guarantee that they will
>> be made available through some other mechanism by the
>> SCA runtime.
>>
>> However, for any SCA Runtime that DOES provide auto-creation, there is a
>> need to describe what happens if, due to the sequence of
>> deployments, some auto-created channel is "replaced" by the later
>> deployment of a "real channel". In my opinion, it would be wise to
>> try to avoid such a situation. However, I don't see a way of preventing
>> this situation - perhaps this is something that you'd like to describe.
>>
>>
>> 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: Danny van der Rijn <>
>> To: Mike Edwards/UK/IBM@IBMGB
>> Cc: OASIS Assembly <>
>> Date: 09/02/2011 17:34
>> Subject: Re: [sca-assembly] [Issue 253]: (1.2) Must a global domain
>> channel be deployed before it can be used?
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> Mike -
>>
>> Your arguments seem to me to be more arguing against case a) than
>> against autocreation, as they hold for *any* more restrictive
>> redeployment, not just one whose previously deployed state was perhaps
>> auto-deployed.
>>
>> Auto-deployment (as I envision it) is merely shorthand for an actual
>> deployment. ("Your composite references a global domain channel that
>> hasn't been deployed. Shall I create one for you and deploy it, or would
>> you prefer me to reject deployment of your composite outright?") Your
>> arguments just point out another weakness I see in the concept of global
>> domain channels.
>>
>> Danny
>>
>> On 2/9/2011 2:45 AM, Mike Edwards wrote:
>>
>> Danny,
>>
>> SCA Runtime "styles";
>>
>> a) Reconfiguration/Redeployment is allowed
>> b) Reconfiguration/Redeployment is not allowed
>>
>> Case b) is the simpler of the two. In this case, all the configuration
>> must be present when the runtime is started.
>> Either Domain channels are part of the configuration at this point or
>> not - if not, then any references to Domain
>> channels would either be errors (no auto-creation of channels) or would
>> require auto-creation of channels.
>>
>> Case a) is the case where there can be separate deployment of (some)
>> consumers & producers and of the
>> channel(s) that they connect to. I note that this can only happen for
>> Domain level channels. Once separate
>> deployment is possible, then the timing of deployment matters - if
>> Channel deployment is later than deployment
>> of any of the producers that connect to the channel, then it the
>> question of auto-creation comes into play.
>> If no auto-creation is NOT allowed by the runtime, then any event
>> produced will have nowhere to go, which might
>> be flagged as an error (since the producer is configured to transmit the
>> events). If auto-creation is allowed, then
>> the events will be flowed to an auto-created Channel and on to whatever
>> consumers are connected to that channel.
>>
>> When the Channels are later deployed into such a runtime, I assume that
>> the auto-created Channels get "replaced"
>> by the deployed versions, with whatever configuration they carry. Since
>> the configuration may carry Filters, this may
>> mean that some events get forwarded by the auto-created channel that
>> don't get forwarded by the specifically
>> deployed channel. I'm not sure what this would mean for the consumers
>> attached to the channel. More problematic
>> would be any binding and policy information attached - the binding could
>> indicate the need to have the channel use
>> some specific existing infrastructure (eg some MQ queue) - and if the
>> intention is that events flow to/from the existing
>> infrastructure, then the auto-deploy channel is unlikely to do this.
>>
>> I think the result of this is that during the period when any
>> auto-deploy channels are being used, before the point
>> where the specifically configured channels are active, that some events
>> may not reach all their intended destination(s)
>> and some events may not be received by some SCA consumers listening on
>> those channels.
>>
>> All of which might argue for a process of deploying the Domain channels
>> first, which kind of undermines the idea of
>> auto-deploying those channels.
>>
>>
>>
>> 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: .com_ <mailto:>
>>
>>
>>
>>
>>
>> From: Danny van der Rijn _<>_
>> <mailto:>
>> To: Mike Edwards/UK/IBM@IBMGB
>> Cc: -open.org_
>> <mailto:>
>> Date: 08/02/2011 22:02
>> Subject: Re: [sca-assembly] [Issue 253]: (1.2) Must a global domain
>> channel be deployed before it can be used?
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> OK, I'll take a stab at answering your question, although I'm just
>> presenting one alternative among many.
>>
>> First, though, your wording interests me:
>>
>> in the case where the channel concerned DOES
>> have configuration and it so happens that the channel is deployed to the
>> Domain some time after some of the
>> producers and consumers using the channel are deployed to the Domain.
>>
>>
>> What intrigues me is the notion that your use case allows you to assert
>> that something about the channel's configuration. Can that configuration
>> never change? If so, how would you deal with changing that? By
>> undeploying and redeploying it? Some other means?
>>
>> I would apply whatever answer you have to that question to this one.
>>
>> To wit:
>>
>> Say that you do allow some form of runtime redeployment or modification.
>> So in this case the implementation MAY autodeploy the channel (RFC 2119
>> wording intentional). If someone chooses to redeploy the channel with
>> further configuration later, so be it. Use whatever form of modification
>> you were going to support in the case where the prior configuration was
>> not auto-deployed.
>>
>> Say you don't allow modification. Then I'd say that your implementation
>> should either not allow for autodeployment, or that your implementation
>> should put up some reasonable bar to autodeployment.
>>
>> Danny
>>
>> On 2/8/2011 1:51 AM, Mike Edwards wrote:
>>
>> Folks,
>>
>> I'd appreciate it if someone could explain how things would work in the
>> case where the channel concerned DOES
>> have configuration and it so happens that the channel is deployed to the
>> Domain some time after some of the
>> producers and consumers using the channel are deployed to the Domain.
>>
>>
>> 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: .com_ <mailto:>
>>
>>
>>
>>
>>
>> From: Anish Karmarkar _<>_
>> <mailto:>
>> To: -open.org_
>> <mailto:>
>> Date: 08/02/2011 09:15
>> Subject: Re: [sca-assembly] [Issue 253]: (1.2) Must a global domain
>> channel be deployed before it can be used?
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> Danny and Eric's arguments have convinced me that auto-creation of
>> global channels make sense. It would certainly simplify config/deploy --
>> I won't have to create a separate composite that contains only the
>> channel name and then deploy it to the domain. Currently we do allow
>> this for the default channel ("//"). As Eric points out, my issue wrt
>> error detection can be dealt with by tools (I can have a global option
>> or flag for the deployer). Given that we already allow this for the
>> default channel, and channels currently require no additional
>> configuration (one can have configuration, but is not required to),
>> autocreation would provide a consistent model and would make simple
>> deployment scenarios easier.
>>
>> -Anish
>> --
>>
>> On 2/7/2011 9:50 AM, Eric Johnson wrote:
>> > To be more explicit, and echo Danny's point, I think we have four
>> options:
>> >
>> > 1) Mandate that auto-creation of channels works
>> > 2) Mandate that auto-creation of channels never works
>> > 3) Identify specific situations where #1 or #2 are possible
>> > 4) Take no position (this may still imply changes to the spec, insofar
>> > as we highlight the point, while taking no sides)
>> >
>> > I raised the issue because #4, it seems to me, leaves the door open
>> for
>> > interoperability failures. ("I deployed X over here with no problems,
>> > but it doesn't work over there.")
>> >
>> > Insofar as I've recall the discussion of the concrete use cases for
>> > global domain channels (Oracle's F2F presentation), we explicitly
>> noted:
>> > no filters, no policies, and no bindings on said channels. Meaning,
>> > configuration optional, and it's just a name. If it is just a name,
>> why
>> > can't I auto-create?
>> >
>> > Anish notes that some people like the safety net of predefined names,
>> > and I agree that's useful. However, that can be addressed in a variety
>> > of ways that aren't nearly so heavy-handed as to simply deny the
>> > deployment. ("The domain contribution includes references to global
>> > domain channel "foo" that doesn't yet exist. Continue/Cancel?).
>> >
>> > -Eric.
>> >
>> > On 2/7/11 9:30 AM, Danny van der Rijn wrote:
>> >> Yet all their configuration is optional?
>> >>
>> >> On 2/7/2011 3:39 AM, Mike Edwards wrote:
>> >>>
>> >>> Eric,
>> >>>
>> >>> My view is that global channels - indeed any channels - are more
>> than
>> >>> a name - they have configuration associated
>> >>> with them. A system which does not require them to be declared makes
>> >>> it difficult to provide required configuration.
>> >>>
>> >>> 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: .com_ <mailto:>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> From: Eric Johnson _<>_ <mailto:>
>> >>> To: Anish Karmarkar _<>_
>> <mailto:>
>> >>> Cc: -open.org_
>> <mailto:>
>> >>> Date: 04/02/2011 17:14
>> >>> Subject: Re: [sca-assembly] [Issue 253]: (1.2) Must a global domain
>> >>> channel be deployed before it can be used?
>> >>>
>> >>>
>> >>>
>> ------------------------------------------------------------------------
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On 2/4/11 1:37 AM, Anish Karmarkar wrote:
>> >>> > I don't see this being different than say requiring that a
>> variable be
>> >>> > declared before it is used.
>> >>> <eej>
>> >>> Which might be a perfect analogy.
>> >>>
>> >>> If the only point of a global channel is to establish a name, then
>> >>> there's actually minimal value to declaring it before it is used.
>> Many
>> >>> dynamic languages work this way - Python & Ruby. In the case of
>> global
>> >>> domain channels, for many use cases, filters and bindings don't make
>> >>> sense, so the channel just becomes a name. At which point,
>> declaration
>> >>> before use looks like ceremony over substance.
>> >>>
>> >>> </eej>
>> >>> >
>> >>> > -Anish
>> >>> > --
>> >>> >
>> >>> > On 2/1/2011 10:11 AM, Danny van der Rijn wrote:
>> >>> >> An interesting argument for tight coupling...
>> >>> >>
>> >>> >> On 2/1/2011 6:19 AM, Anish Karmarkar wrote:
>> >>> >>> I think this is a fine issue to raise, but I don't quite
>> support the
>> >>> >>> auto-creation proposal. The only global channel that is
>> >>> >>> 'auto-deployed' or always exists is the default channel.
>> >>> >>>
>> >>> >>> I would want the runtime to tell me if I referenced a channel
>> >>> that has
>> >>> >>> not been deployed (unless it is the default channel, which is
>> the
>> >>> >>> exception). If I want a producer and consumer (especially if
>> they are
>> >>> >>> in different composites) to communicate over a common channel, I
>> >>> would
>> >>> >>> want the system to catch typos. For example, if the producer is
>> >>> >>> connected to the channel "//omg" and the consumer is
>> connected to
>> >>> >>> "//zomg", they would be deployed fine but my application
>> would not
>> >>> >>> work correctly.
>> >>> >>>
>> >>> >>> -Anish
>> >>> >>> --
>> >>> >>>
>> >>> >>> On 1/31/2011 10:19 AM, Eric Johnson wrote:
>> >>> >>>> Hi Peter,
>> >>> >>>>
>> >>> >>>> On 1/31/11 10:02 AM, Peter Niblett wrote:
>> >>> >>>>> Eric
>> >>> >>>>>
>> >>> >>>>> You said..
>> >>> >>>>>
>> >>> >>>>> Neither of the above indicate whether or not the global domain
>> >>> >>>>> channel
>> >>> >>>>> can be used before it is referenced.
>> >>> >>>>
>> >>> >>>> Ah yes, the joys of a muddled brain on Monday morning. You're
>> >>> >>>> correct -
>> >>> >>>> the question is whether or not the global domain channel can
>> be used
>> >>> >>>> before it is *created* via a contribution.
>> >>> >>>>
>> >>> >>>> Thanks for catching my circularity.
>> >>> >>>>
>> >>> >>>> -Eric.
>> >>> >>>>>
>> >>> >>>>> I'm not sure how you can "use" a channel without referencing
>> it (I
>> >>> >>>>> assume "reference" means "wire to/from"), but I think the
>> question
>> >>> >>>>> you
>> >>> >>>>> are asking is the one in the title - "can you reference a
>> channel
>> >>> >>>>> that
>> >>> >>>>> hasn't been defined to the SCA assembly?". I think this is one
>> >>> place
>> >>> >>>>> where the current spec is clear.. you can't reference a domain
>> >>> >>>>> channel
>> >>> >>>>> that hasn't been defined.
>> >>> >>>>>
>> >>> >>>>> So it looks as though your issue is to say that we should
>> >>> change the
>> >>> >>>>> spec to say that it permits (in fact requires) autocreation of
>> >>> domain
>> >>> >>>>> channels. Presumably these channels would have to be
>> created with
>> >>> >>>>> default attributes (though I know you think they shouldn't
>> have
>> >>> >>>>> attributes at all).
>> >>> >>>>>
>> >>> >>>>> Regards
>> >>> >>>>>
>> >>> >>>>> Peter Niblett
>> >>> >>>>> IBM Senior Technical Staff Member
>> >>> >>>>> Member of the IBM Academy of Technology
>> >>> >>>>> +44 1962 815055
>> >>> >>>>> +44 7825 657662 (mobile)
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>> From: Eric Johnson_<>_ <mailto:>
>> >>> >>>>> To: OASIS SCA Assembly_<>_
>> <mailto:>
>> >>> >>>>> Date: 31/01/2011 17:19
>> >>> >>>>> Subject: [sca-assembly] NEW ISSUE: (1.2) Must a global domain
>> >>> channel
>> >>> >>>>> be deployed before it can be used?
>> >>> >>>>>
>> >>>
>> ------------------------------------------------------------------------
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>> Title: Must a global domain channel be deployed before it
>> can be
>> >>> >>>>> used?
>> >>> >>>>>
>> >>> >>>>> Target: Assembly 1.2 WD 03
>> >>> >>>>>
>> >>> >>>>> Description:
>> >>> >>>>>
>> >>> >>>>> Via the "@target" and "@source" attributes defined on a
>> consumer&
>> >>> >>>>> producer, the assembler can reference global domain channels.
>> >>> >>>>>
>> >>> >>>>> In section 5.8, the presumed to be normative text reads "SCA
>> >>> runtimes
>> >>> >>>>> MUST support the use of domain channels [ASM????]." That is
>> >>> followed
>> >>> >>>>> by:
>> >>> >>>>>
>> >>> >>>>> "To create a Domain Channel, deploy a composite containing a
>> >>> channel
>> >>> >>>>> directly to the SCA Domain (i.e., do not use that composite
>> as the
>> >>> >>>>> implementation of some component in the Domain)."
>> >>> >>>>>
>> >>> >>>>> Neither of the above indicate whether or not the global domain
>> >>> >>>>> channel
>> >>> >>>>> can be used before it is referenced.
>> >>> >>>>>
>> >>> >>>>> Proposal:
>> >>> >>>>>
>> >>> >>>>> General theme: do not require the global domain channel to
>> exist
>> >>> >>>>> before
>> >>> >>>>> it can be used.
>> >>> >>>>>
>> >>> >>>>> Specific text (needs refinement?):
>> >>> >>>>>
>> >>> >>>>> In section 5.8, Paragraph #2, append:
>> >>> >>>>>
>> >>> >>>>> When contributing artifacts to a domain that contain
>> references to
>> >>> >>>>> global domain channels that have not been created, the SCA
>> runtime
>> >>> >>>>> MUST
>> >>> >>>>> automatically create said global domain channels, and cannot
>> reject
>> >>> >>>>> such
>> >>> >>>>> contributions [ASM????].
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>>
>> ---------------------------------------------------------------------
>> >>> >>>>> To unsubscribe from this mail list, you must leave the
>> OASIS TC
>> >>> that
>> >>> >>>>> generates this mail. Follow this link to all your TCs in
>> OASIS at:
>> >>> >>>>>
>> >>>
>> _https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php_
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>>
>> ------------------------------------------------------------------------
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>> /
>> >>> >>>>> /
>> >>> >>>>>
>> >>> >>>>> /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/
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>
>> >>> >>>
>> ---------------------------------------------------------------------
>> >>> >>> To unsubscribe from this mail list, you must leave the OASIS TC
>> that
>> >>> >>> generates this mail. Follow this link to all your TCs in
>> OASIS at:
>> >>> >>>
>> >>>
>> _https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php_
>> >>> >>
>> >>> >
>> >>> >
>> ---------------------------------------------------------------------
>> >>> > To unsubscribe from this mail list, you must leave the OASIS TC
>> that
>> >>> > generates this mail. Follow this link to all your TCs in OASIS at:
>> >>> >
>> _https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php_
>> >>>
>> >>>
>> ---------------------------------------------------------------------
>> >>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> >>> generates this mail. Follow this link to all your TCs in OASIS at:
>> >>>
>> _https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php_
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> ------------------------------------------------------------------------
>> >>>
>> >>> /
>> >>> /
>> >>>
>> >>> /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/
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail. Follow this link to all your TCs in OASIS at:_
>> __https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php_
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> /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/
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> /
>> /
>>
>> /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/
>>
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
