sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [sca-assembly] ISSUE 5: Component type allows to specify wire targetson references: PROPOSAL
- From: Bryan Aupperle <aupperle@us.ibm.com>
- To: "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
- Date: Mon, 17 Mar 2008 07:39:30 -0600
My comments as <ba> </ba>
Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect
Research Triangle Park, NC
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com
Mike Edwards <mike_edwards@uk.ibm.com>
03/17/2008 06:28 AM
|
To
| "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [sca-assembly] ISSUE 5: Component
type allows to specify wire targets on references: PROPOSAL |
|
Folks,
Some comments inline as <mje>
</mje>
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
"Peshev, Peter"
<peter.peshev@sap.com>
14/03/2008 17:32
|
To
| Graham Charters/UK/IBM@IBMGB
|
cc
| "David Booz" <booz@us.ibm.com>,
"Patil, Sanjay" <sanjay.patil@sap.com>, <sca-assembly@lists.oasis-open.org>
|
Subject
| RE: [sca-assembly] ISSUE 5: Component
type allows to specify wire targets on references: PROPOSAL |
|
Hi Graham,
IMO if there is another XML file called componentType which basically
duplicates the SCDL configuration in another syntax, and the componentType
can serve as SCDL replacement, that's not much of a simplicity , but only
brings confusion what is the difference between the two.
<mje>
The simplicity is not having XML at all.
You'll probably get bored with me saying this, but I prefer a situation
in which there is *never* any componentType FILE.
The componentType is a notional data structure, ideally completely derived
from the contents of the actual implementation
to which it relates.
So the idea of providing suitable annotations to enable the implementation
artifact to completely populate the
componentType data structure is in fact in support of this simple concept.
</mje>
Just thinking loudly (I may be ashamed afterwards) , for such "quick-n-dirty"
usecases that we want to merge the data - how about offering the possibility
to define the componentType tag (without any configurations,
targets,etc.) inside the SCDL, the configurations should still be
done via the existing concept of components & composites, and
adding recommendation that a best practice is to keep them apart as separate
artifacts.
<mje>
First, I stand on my soapbox: This is most certainly NOT "quick-n-dirty".
It is *quick* and it is *simple".
However, using the word "dirty" implies that something incorrect
and not to be encouraged is going on here.
Far from it. An implementation that is fully annotated fits into
the wider SCA world beautifully. It is completely
usable within a composite and can be reconfigured by that composite just
in the same way that any implementation
can be reconfigured.
As for keeping the componentType tag within the SCDL - my point is and
always has been that the componentType
information should never normally be written down by anyone - it is a notional
or virtual data structure extracted from
the implementation. So combining the componentType into the SCDL
make no sense to me at all.
<ba> Not all of the languages
we are working on support support extraction from the implementation. C
& CPP do not provide annotations. We can use tools to build a
componentType from annotated, but the annotations would not be available
from the executable at runtime. I agree that the componentType should
be a separate artifact, but it is a necessary artifact.
</ba>
As for doing configurations via composites and components, my proposed
approach does not change that at all.
However, I don't regard it as "best practice" to keep things
as separate artifacts. Horses for courses here.
In simple cases, combining all the configuration data in the implementation
artifact is the best and simplest
approach. In other cases, where complex compositions are going on,
then there needs to be a suitable
composite file providing appropriate configuration for the components.
</mje>
About the "new annotations for java" route and reusing existing
metadata. First, supplying an SCA target as in the issue 5 text is
hardly existing metadata, that's something that the SCA brought, so we
will need new annotation and concept. While bringing new functionality
we should try to keep balance between the existing number of annotations,
the overall complexity and decide on case by case basis. When I am looking
at the existing 30 annotations in org.osoa.java I am already feeling they
are too much already. Personally, I would be happy to drop some of
them (especially some conversational & callback oriented), and add
something some like @Reference(defaultTarget="goshko"). But that's
a discussion for another TC
<mje>
I can agree that perhaps there are too many existing annotations - a number
of which are unique to Java and do not relate to the
Assembly model. We should take a critical look at them and see what
pruning might be possible.
HOWEVER, the suggestion of having Java annotations that correspond to specific
concepts that are already in the Assembly
specification is not adding a concept, in my opinion - it is only providing
a concrete Java realization of something already
present in SCA. No-one has to use annotations (other than @Remotable
on interfaces, I believe) but if they are targetting
an SCA environment with their Java implementations, then developers may
want/need to deal with SCA concepts and i is
valuable for them to be able to express those concepts in Java rather than
having to switch to XML.
</mje>
Best Regards
Peter
From: Graham Charters [mailto:CHARTERS@uk.ibm.com]
Sent: Thursday, 13. March 2008 23:25
To: Peshev, Peter
Cc: David Booz; Patil, Sanjay; sca-assembly@lists.oasis-open.org
Subject: RE: [sca-assembly] ISSUE 5: Component type allows to specify
wire targets on references: PROPOSAL
Hi Peter, I've added some comments below in <gcc></gcc>
Regards,
Graham.
Graham Charters PhD CEng MBCS CITP
SWG AB Projects
IBM United Kingdom Limited, MP 146, Hursley Park, Winchester, SO21 2JN,
UK
Tel: (Ext) +44-1962-816527 (Int) 7-246527 (Fax)
+44-1962-818999
Internet: charters@uk.ibm.com
"Peshev, Peter" <peter.peshev@sap.com> wrote on 13/03/2008
18:53:18:
> Hi Graham,
>
> Just to make sure I understand, basically you are saying -- SCA is
too
> complex to be used by some developers, so let's allow SCA without
SCA
> SCDL artifacts to appease those people by allowing "quick-n-dirty"
fully
> configured components. Right ?
<gcc> Partly. It's not just some developers, it's some scenarios
where the flexibility and role distinctions (and how they are burned into
the programming model) actually get in the way of them achieving their
goal. There's also the 'mandatory' use of XML as part of that.</gcc>
>
> If yes, how exactly are you planning to provide this "quick-n-dirty"
> configuration of SCA.
> -- By componentType side files in XML format, which I would
say are
> equally complex to SCDL-s
> -- By introducing introspection rules for different technologies
and
> how they could generate the new fully configured componentType. Probably
> that would result to new constructs in the respective implementation
> types (new annotations for java, etc.).
<gcc>I think it's the latter, and I also think that's business-as-usual
for SCA. When defining an implementation type, I think it's good
to re-use existing metadata through some existing introspection capability.
Some technologies support this, and some don't, in which case we
can describe them with an XML componentType or add some introspection capability
to the technology (the C++ spec did this, open source PHP SCA did this,
etc...). We've already gone down the "new annotations for java"
route with the SCA Java annotations.</gcc>
>
> Btw, IMHO if something went too complex and developers refuse
to use it
> , we should simplify it, instead of adding new capabilities and another
> layer of complexity in the specs.
>
<gcc>I totally agree with the first part, regarding simplifying,
what I don't understand is how this is really another layer of complexity.
It follows the SCA model (the definition for services, references,
properties, bindings, etc.), it just allows the information to be specified
in a single artefact, but still be re-used in a full SCA assembly without
having to re-declare everything. It's up to each implementation type
to choose whether they support that approach. </gcc>
> Best Regards
> Peter
>
> ________________________________
>
> From: Graham Charters [mailto:CHARTERS@uk.ibm.com]
> Sent: Thursday, 13. March 2008 17:16
> To: Patil, Sanjay
> Cc: David Booz; sca-assembly@lists.oasis-open.org
> Subject: RE: [sca-assembly] ISSUE 5: Component type allows to specify
> wire targets on references: PROPOSAL
>
>
>
> Hi Sanjay,
>
> I'm not Dave, or Mike, but I'd like to chip in ;-) . I think
they've
> both covered most of the points I would make, regarding easing adoption
> by making it quick to get started, and the fact that a single person
is
> performing multiple roles. Regarding your questions:
>
> > Question: Why in the world do you need to generate a componentType
for
> > this use case of 'directly deploying a fully configured
> implementation'?
> > I thought you wanted to directly deploy a fully configured
> > implementation because pointy brackets may hurt and bleed, right?
So
> > just go ahead and deploy the fully configured implementation.
Why
> bother
> > about generating a componentType (which would have pointy brackets)?
>
> I think this comes down to how these fully configured implementations
> get re-used and reconfigured in a pointy brackets world. Mike
mentioned
> this in his response about not requiring everything to be redeclared.
>
> I think we have an opportunity here to enable a broader community
of
> developers, which can bring skills and build assets to our SOA
> programming model. If we don't make it a smooth progression
from the
> "quick-n-dirty" fully configured world to the world of SCDL,
then I
> think we'll be limiting the applicability of SCA, and helping persuade
> the "quick-n-dirty" folks to choose another technology.
>
>
> Regards,
>
> Graham.
>
>
>
> Graham Charters PhD CEng MBCS CITP
> SWG AB Projects
> IBM United Kingdom Limited, MP 146, Hursley Park, Winchester, SO21
2JN,
> UK
> Tel: (Ext) +44-1962-816527 (Int) 7-246527
(Fax) +44-1962-818999
> Internet: charters@uk.ibm.com
>
>
> "Patil, Sanjay" <sanjay.patil@sap.com> wrote on 13/03/2008
04:05:29:
>
> >
> > Hi Dave,
> >
> > One question from my side while Mike is still sleeping ...
> >
> > <Sanjay> As I said in my email below, the use case of 'fully
> configured
> > implementation' does not require specifying binding/target
on
> > References
> > in the ComponentType. What you need is an ability for implementations
> > to
> > include information that would otherwise be part of deployable
> > composites,
> > and this issue belongs to the C&I specifications, IMO.
</Sanjay>)
> > <dab> If you had such an implementation and then generated
a
> > componentType
> > from it, would it not look exactly as this proposal describes?
</dab>
> >
> > Question: Why in the world do you need to generate a componentType
for
> > this use case of 'directly deploying a fully configured
> implementation'?
> > I thought you wanted to directly deploy a fully configured
> > implementation because pointy brackets may hurt and bleed, right?
So
> > just go ahead and deploy the fully configured implementation.
Why
> bother
> > about generating a componentType (which would have pointy brackets)?
> >
> > -- Sanjay
> >
> > > -----Original Message-----
> > > From: David Booz [mailto:booz@us.ibm.com]
> > > Sent: Wednesday, Mar 12, 2008 20:26 PM
> > > To: sca-assembly@lists.oasis-open.org
> > > Subject: RE: [sca-assembly] ISSUE 5: Component type allows
to
> > > specify wire targets on references: PROPOSAL
> > >
> > > some quick answers while Mike is sleeping.....<dab>
like this </dab>
> > >
> > > Dave Booz
> > > STSM, SCA and WebSphere Architecture
> > > Co-Chair OASIS SCA-Policy TC
> > > "Distributed objects first, then world hunger"
> > > Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> > > e-mail:booz@us.ibm.com
> > > http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
> > >
> > >
> > >
> > >
> > > "Patil,
Sanjay"
> > >
> > > <sanjay.patil@sap
> > >
> > > .com>
> > > To
> > >
"Mike Edwards"
> > >
> > > 03/12/2008
05:43
> > > <mike_edwards@uk.ibm.com>, "OASIS
> > > PM
Assembly"
> > >
> > >
> > > <sca-assembly@lists.oasis-open.org>
> > >
> > > cc
> > >
> > >
> > >
> > > Subject
> > >
RE: [sca-assembly]
> > > ISSUE 5:
> > >
Component type allows
> > > to specify
> > >
wire targets on
> > > references:
> > >
PROPOSAL
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > comments/questions inline ...
> > >
> > > From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
> > > Sent: Wednesday, Mar 12, 2008 4:42 AM
> > > To: OASIS Assembly
> > > Subject: RE: [sca-assembly] ISSUE 5: Component type
allows
> > > to specify wire
> > > targets on references: PROPOSAL
> > >
> > >
> > > Folks,
> > >
> > > I'm finding it very hard to understand the logic behind
the
> proposals
> > > below. They seem to complicate the SCA model
for no reason.
> > >
> > > The proposal that I favour I think is a very simple
one,
> > > that fits in well
> > > with the current structure of SCA and requires no
new or special
> > > constructs. Basically, the model I see is one
where an
> > > implementation has
> > > a componentType. The componentType represents
> > > the configurable aspects of the implementation - services,
> > > references,
> > > properties and the implementation itself (in the sense
that
> > > intents and policies can be configured on the implementation).
> > > <Sanjay>
> > > I think there is a distinction to be drawn between
the
> > > configuration of
> > > Services/References and that of Properties. The declaration
of
> > > Services/References by an implementation is in terms
of business
> > > interfaces (and intents, if necessary) and a
typical
> implementation
> > > developer would rather keep the code independent of
the
> > > binding/target
> > > used by the Services/References (isn't that one
of the main value
> > > propositions of SCA!). In other words, all the configurable
> > > aspects of
> > > Services/References are not within the purview of
the
> implementation
> > > developer. OTOH, an implementation developer must
understand
> > > the entire
> > > structure of Properties, the range of possible values
that may be
> > > specified by the users of that implementation, etc.
> > >
> > > With the above distinction in mind, it would seem
natural for
> > > implementations to provide defaults for Properties,
but
> > > providing defaults
> > > for bindings/targets for Services/References in the
> > > implementations would
> > > be meddling with other roles (e.g. Deployer).
> > > </Sanjay>
> > > <dab> In general, I agree very strongly with
your
> > > distinction. However,
> > > the proposal is specifically and explicitly setting
that
> > > aside to enable
> > > some use cases which are not part of the general usage.
> > > This is about
> > > enabling early adopters who are a) technically advanced
(and
> > > therefore can
> > > also see that they are trampling on the distinction
you are
> > > making) and b)
> > > are trying to dig in and get something running quickly.
> Dogmatically
> > > forcing them into the general case will inhibit adoption.
> > > I'm usually the
> > > one that cries "simplicity first" when we
start straying out
> > > of the 80%
> > > use cases. FWIW, I think this case is worth
enabling because it
> will
> > > foster adoption of the technology. </dab>
> > >
> > >
> > > I see it as being a very simple idea that the configurable
> > > aspects of an
> > > implementation may have default values for any of
those
> > > aspects.
> > > <Sanjay> I disagree with this generalization.
See my
> > > previous comment.
> > > </Sanjay>
> > >
> > > - That value can apply to a Property by the property
having
> > > some value
> > > defined by the implementation.
> > > - For a service, the default value may be a specific
binding and a
> > > relative URI
> > > - For a reference, the default value may include a
specific
> > > binding and/or
> > > a specific target for the reference, (some URI)
> > > <Sanjay> By configuring a Property of an implementation,
you
> > > are effecting
> > > certain behavior/update that is confined to that
> > > implementation. OTOH, by
> > > configuring a Reference with target/binding value,
you are
> providing
> > > details which the implementation does not care about.
</Sanjay>
> > > <dab> Agree, but this is about the implementor
being able to
> > > play all the
> > > roles in a quick and easy manner. This is not
about a clean
> > > implementation, </dab>
> > >
> > > When an implementation is used within a component,
then the
> > > component can
> > > decide to configure any or all of the configurable
> > > aspects of the implementation. This is true
whether or not there
> are
> > > default values for those aspects. The component
can get
> > > exactly what it wants, for properties, for references
and
> > > for services
> > > (other than any intents, of course, which cannot be
overridden).
> > >
> > > The neat thing about defaults, is that if the component
> > > writer is OK with
> > > the defaults present in the implementation, then it
cuts down
> > > the work required to configure the component - the
component
> > > can simply
> > > use the default values.
> > > <Sanjay> You still need to check if the component
writer is
> > > OK with the
> > > defaults. That is not such a neat thing IMO. The component
> > > writer now has
> > > to exercise extra caution in checking defaults for
aspects
> > > that he/she
> > > would not have expected.</Sanjay>
> > > <dab> It's the same person in this case. </dab>
> > >
> > > I see the "completely configured implementation"
as only an
> > > extreme case
> > > of these ideas - ie an implementation where all the
> > > configurable aspects have default values supplied,
so that,
> > > in effect *no*
> > > configuration is required from the using component
> > > in order for the component to work.
> > > <Sanjay> Don't you need to 'promote' the component
> > > Services/References in
> > > order to make them visible at the SCA Domain level?
<Sanjay>
> > > <dab> No, absolutely not....this is really an
argument for
> > > another day
> > > (and another thread) and I'll not go further here.
</dab>
> > >
> > > This has the happy side effect of allowing a particular
use
> > > case to work
> > > very neatly. This is the "zero effort deployment"
scenario,
> > > where an implementation artifact such as a Java class
or a
> > > PHP script can
> > > be given to a (suitable) runtime and that runtime
can
> > > instantiate the implementation as a domain-level component
> > > without the
> > > need for any further effort (ie no need to separately
> > > supply deployment metadata), since everything necessary
is
> > > defined in the
> > > implementation artifact. The runtime would still
> > > in SCA terms be creating a deployment time composite
for that new
> > > component, but its contents are "trivial"
in the sense that
> > > all that is required is a component element with a
name, using the
> > > supplied implementation.
> > > <Sanjay> As I said in my email below, the use
case of
> > > 'fully configured
> > > implementation' does not require specifying binding/target
> > > on References
> > > in the ComponentType. What you need is an ability
for
> > > implementations to
> > > include information that would otherwise be part of
> > > deployable composites,
> > > and this issue belongs to the C&I specifications,
IMO. </Sanjay>)
> > > <dab> If you had such an implementation and then generated
a
> > > componentType
> > > from it, would it not look exactly as this proposal describes?
> </dab>
> > >
> > > I note that no-one is required to build a runtime
that works
> > > this way. A
> > > runtime can insist on the deployment of contributions
> > > that do contain composites. On the other hand,
I'd prefer to see
> it
> > > possible to create a runtime that does not require
such
> > > metadata.
> > > <Sanjay> I disagree. Supporting your proposal
would at the
> > > minimum require
> > > that a compliant assembly design time tool be aware
of
> > > defaults in the
> > > implementations/ComponentType-side-files. </Sanjay>
> > > <dab> l think we could make those elements optional
> > > compliance points.
> > > </dab>
> > >
> > > Doing this in no way runs against the principles of
SCA -
> > > and requires no
> > > changes to the model either. If a using component
> > > wants to use the same "fully configured implementation"
in a
> > > new way, it
> > > is free to do so by configuring the implementation
in
> > > whatever way it chooses. Simply supply a composite
with a
> component
> > > containing the necessary configuration data.
> > > <Sanjay> I would personally favor a simple
model where by -
> > > a> when a
> > > 'fully configured implementation' is directly deployed,
its 'full
> > > configuration' is utilized as intended, b> when
a 'fully configured
> > > implementation' is used by a component (a corner
case), the
> > > deployment
> > > specific configuration coming from that implementation
is
> > > ignored (as it
> > > was really not intended for this case). </Sanjay>
> > > <dab> ah...a ray of light. This would make a
fully configued
> > > composite
> > > (which is an implementation) different from a fully
configured Java
> > > implementation. </dab>
> > >
> > > Yours, Mike.
> > >
> > > Strategist - Emerging Technologies, SCA & SDO.
> > > Co Chair OASIS SCA Assembly TC.
> > > IBM Hursley Park, Mail Point 146, Winchester, SO21
2JN,
> > > Great Britain.
> > > Phone & FAX: +44-1962-818014 Mobile:
+44-7802-467431
> > > Email: mike_edwards@uk.ibm.com
> > >
> > >
> > >
> > > "Patil, Sanjay"
> > >
> > > <sanjay.patil@sap.com>
> > >
> > >
> > >
> > >
> > > To
> > > 11/03/2008 18:50
Mike Edwards/UK/IBM@IBMGB,
> > > "OASIS
> > >
Assembly"
> > >
> > >
> > > <sca-assembly@lists.oasis-open.org>
> > >
> > > cc
> > >
> > >
> > >
> > > Subject
> > >
RE: [sca-assembly]
ISSUE 5:
> > > Component
> > >
type allows
to specify wire
> > > targets on
> > >
references:
PROPOSAL
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > I am guessing that the rationale behind the following
> > > proposal to close
> > > the Issue 5 with no-action is - to allow for direct
deployment of
> > > implementation artifacts without requiring creation
of any
> > > SCDL files,
> > > etc. Assuming that as the target use case ....
> > >
> > > I would like to note that supporting the above use
case does
> > > not depend
> > > upon inclusion of deployment specific configuration
(e.g.
> > > wire targets on
> > > references) in the ComponentType, since a simple solution
to
> > > meet the use
> > > case would be to embed the deployment specific configuration
> > > directly in
> > > the implementation artifacts. Now an interesting question
to
> > > answer would
> > > be - Is there a language-neutral SCA construct to
represent
> > > the deployment
> > > specific configuration embedded in the implementation
> > > artifacts? Here are
> > > some of the possible answers IMO -
> > >
> > > a> None - there is no need to separately represent
the embedded
> > > configuration data as an SCA construct, since the
goal of
> > > the use case is
> > > to avoid creation of any SCDL files, etc.
> > > b> Composite - Since the SCA model expects
that it is a
> > > Composite that
> > > gets deployed to an SCA domain, it logical follows
that the
> > > SCA construct
> > > to represent the deployment specific configuration
embedded in an
> > > implementation artifact would also be a Composite
(and not
> > > ComponentType)
> > >
> > > So if at all we wanted to have an SCA construct that
reflects the
> > > deployment specific configuration in a directly deployable
> > > implementation,
> > > we should focus on defining a mapping between a Composite
and the
> > > implementation. Mapping of deployment specific configuration
> > > embedded in
> > > implementation artifacts to ComponentType is not necessary,
> > > and if allowed
> > > for whatever reasons, there are potential downsides
as
> > > documented in the
> > > issue text [1].
> > >
> > > In essence, I propose that we resolve Issue-5 by adopting
> > > the proposal
> > > specified in the issue text, which says: Change the
schema
> > > so that wire
> > > targets cannot be specified.
> > >
> > > Thanks,
> > > Sanjay,
> > >
> > >
> > > [1] http://osoa.org/jira/browse/ASSEMBLY-5
> > >
> > > From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
> > > Sent: Tuesday, Feb 12, 2008 4:12 AM
> > > To: OASIS Assembly
> > > Subject: [sca-assembly] ISSUE 5: Component type allows
to
> > > specify wire
> > > targets on references: PROPOSAL
> > >
> > >
> > > Folks,
> > >
> > > PROPOSAL: Close Issue 5 with no action.
> > >
> > > This permits the component type of a component to
contain
> > > wire targets on
> > > references.
> > >
> > >
> > > Yours, Mike.
> > >
> > > Strategist - Emerging Technologies, SCA & SDO.
> > > Co Chair OASIS SCA Assembly TC.
> > > IBM Hursley Park, Mail Point 146, Winchester, SO21
2JN,
> > > Great Britain.
> > > Phone & FAX: +44-1962-818014 Mobile:
+44-7802-467431
> > > Email: mike_edwards@uk.ibm.com
> > >
> > >
> > >
> > >
> > >
> > > 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. You may a link to this group
and all
> > > your TCs in OASIS
> > > at:
> > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> > > oups.php
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS
TC that
> > generates this mail. You may a link to this group and 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]