[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] [Issue 253]: (1.2) Must a global domain channelbe deployed before it can be used?
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: mike_edwards@uk.ibm.com
>>
>>
>>
>>
>>
>> From: Danny van der Rijn <dannyv@tibco.com>
>> To: Mike Edwards/UK/IBM@IBMGB
>> Cc: OASIS Assembly <sca-assembly@lists.oasis-open.org>
>> 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: _mike_edwards@uk.ibm.com_ <mailto:mike_edwards@uk.ibm.com>
>>
>>
>>
>>
>>
>> From: Danny van der Rijn _<dannyv@tibco.com>_
>> <mailto:dannyv@tibco.com>
>> To: Mike Edwards/UK/IBM@IBMGB
>> Cc: _sca-assembly@lists.oasis-open.org_
>> <mailto:sca-assembly@lists.oasis-open.org>
>> 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: _mike_edwards@uk.ibm.com_ <mailto:mike_edwards@uk.ibm.com>
>>
>>
>>
>>
>>
>> From: Anish Karmarkar _<Anish.Karmarkar@oracle.com>_
>> <mailto:Anish.Karmarkar@oracle.com>
>> To: _sca-assembly@lists.oasis-open.org_
>> <mailto:sca-assembly@lists.oasis-open.org>
>> 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: _mike_edwards@uk.ibm.com_ <mailto:mike_edwards@uk.ibm.com>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> From: Eric Johnson _<eric@tibco.com>_ <mailto:eric@tibco.com>
>> >>> To: Anish Karmarkar _<Anish.Karmarkar@oracle.com>_
>> <mailto:Anish.Karmarkar@oracle.com>
>> >>> Cc: _sca-assembly@lists.oasis-open.org_
>> <mailto:sca-assembly@lists.oasis-open.org>
>> >>> 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_<eric@tibco.com>_ <mailto:eric@tibco.com>
>> >>> >>>>> To: OASIS SCA Assembly_<sca-assembly@lists.oasis-open.org>_
>> <mailto:sca-assembly@lists.oasis-open.org>
>> >>> >>>>> 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
S/MIME Cryptographic Signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]