[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] Issue 94: Conversational services
On Dec 18, 2008, at 4:53 AM, Martin Chapman wrote:
> I think Simon's use case is a common one, where you shouldn't remove
> an item
> from a cart that hasn't been previously added.
Doesn't this interface capture that semantic?
@Conversational
public interface Cart {
void add(Item item);
void remove(String itemId) throws ItemNotFoundException;
@EndsConversation
void checkout() throws EmptyCartException;
}
Even callback ordering and sequencing could be implemented with
annotations. In Java 7, checks could be implemented to have the
container ensure the item is in the cart. However, I don't think we
should go there as it is the territory of choreography. The point I
guess I am trying to make is that the current mechanisms do well
covering the proverbial 80% of conversational use cases and they have
real value. For our applications, we have found SCA conversations more
than sufficient and they have managed to help us eliminate a
tremendous amount of extraneous code.
Do you have other specific use cases in mind that you believe fit into
the 80% realm that we could work through to see if they can be
accommodated?
> I thought we had got to the
> point of not conflating a service contract (permissible ordering of
> invocations) with the ability to get back to the "same" instance or
> state,
> which do seem to be orthogonal to each other.
>
In my conceptual model, instance routing (instance identity) and state
are separate concerns. State is what conversations are about, i.e. a
shared context between a client and a provider. A conversation is a
specialized stateful interaction, but not all stateful interactions
are conversational. For example, a composite scoped component is
stateful but it is not conversational as its state is available to any
client that invokes it. Instance identity is just an implementation
strategy. It may be used by a runtime to provide container-managed
behavior for a component implementation. The fact that a service
requires shared context to be maintained between a client and provider
is a characteristic of the contract between the two. If the client
"forgets" to propagate a conversational identifier, the service will
not work.
I do agree the service contract and instance identity are completely
orthogonal to one another. The current SCA conversational mechanisms
make this distinction. As I mentioned in my response to Simon, routing
back to the same instance has nothing to do with conversations per se.
The former may be a partial implementation strategy for the latter but
the two should not be conflated. A conversation is defined by shared
context, not preserving instance identity across operation
invocations. For example, a runtime may implement conversational
services with a singleton. In the Java programming model, the fact
that conversational services imply conversation-scoped implementations
means that instance identity is preserved in certain situations.
However, this will not always be the case. A runtime may passivate
instances of long-running conversations, in which case multiple
instances will service requests in the same conversation.
The current semantics do not tie the service contract to instance
identity. The begin, continue, and end conversation "markers" (the
first two are implicit) say nothing about instance creation. They do
say something about state and resources, though:
- begin: allocate any necessary stateful resources
- continue: make any previously allocated stateful resources available
to the current invocation context
- stateful resource may be released
I'm still a bit unclear on your position. Are you saying conversation
lifecycle is not part of the service contract on conceptual grounds or
are you asserting that it should not be on practical ones as the
semantics cannot be captured with current relevant technologies? At
different times you seem to be making both claims so I tried to
address each in the two responses above.
Jim
> Martin.
>
>> -----Original Message-----
>> From: Jim Marino [mailto:jim.marino@gmail.com]
>> Sent: 17 December 2008 20:08
>> To: Martin Chapman
>> Cc: 'Simon Nash'; 'OASIS Assembly'
>> Subject: Re: [sca-assembly] Issue 94: Conversational services
>>
>>
>> On Dec 17, 2008, at 11:11 AM, Martin Chapman wrote:
>>
>>> a) because in all but simple cases it's a notational challenge.
>>> I thought Simon was arguing for a) but I'll let him respond.
>>>
>> Could you list the common use cases that you believe can't be
>> addressed by the given semantics? My argument would be that unless
>> they fall into the "80 %" rule, then having basic functionality, even
>> if it does not address complex scenarios, is a good thing as it will
>> meet most people's needs. Having a clear set of use cases will help
>> us
>> decide if those cases are very common or not. Also, I would point out
>> that the existing semantics to my knowledge don't preclude more
>> complex semantics from being implemented either via an implementation
>> type or application code.
>>
>> Another way of looking at this is to ask, do you think the existing
>> semantics are not useful in common cases or inhibit the complex ones
>> from being realized using additional mechanisms?
>>
>> FWIW, the applications I have been involved in have some fairly
>> complex conversational services and the existing SCA mechanisms have
>> held up well in practice.
>>
>> Jim
>>
>>
>>
>>> Martin.
>>>
>>>> -----Original Message-----
>>>> From: Jim Marino [mailto:jim.marino@gmail.com]
>>>> Sent: 17 December 2008 17:59
>>>> To: Martin Chapman
>>>> Cc: 'Simon Nash'; 'OASIS Assembly'
>>>> Subject: Re: [sca-assembly] Issue 94: Conversational services
>>>>
>>>> Hi Martin,
>>>>
>>>> I'm a bit confused :-) One of the objections you raised with
>>>> respect
>>>> to conversational services seemed to be that service lifecycle
>>>> semantics could not be imputed from the service definition. But
>> here,
>>>> you state that you agree with Simon's conclusions. Is it:
>>>>
>>>> a) You don't believe start/continue/end are semantics that should
>>>> be
>>>> exposed to clients
>>>> b) You think that implementation state management semantics should
>>>> not
>>>> be exposed to clients but start/continue/end as service lifecycle
>>>> semantics should be made explicit to clients
>>>> c) Something else
>>>>
>>>> FWIW, my position is b.
>>>>
>>>> Jim
>>>>
>>>> (I plan on responding to Simon's post separately so as not to
>> confuse
>>>> the discussion)
>>>>
>>>> On Dec 17, 2008, at 9:39 AM, Martin Chapman wrote:
>>>>
>>>>> The add and remove can be parameterised, but since I do not
>> disagree
>>>>> with
>>>>> your conclusion this is academic :-)
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Simon Nash [mailto:oasis@cjnash.com]
>>>>>> Sent: 16 December 2008 23:10
>>>>>> To: 'OASIS Assembly'
>>>>>> Subject: Re: [sca-assembly] Issue 94: Conversational services
>>>>>>
>>>>>> As Jim has mentioned, I believe it is better to take the
>>>>>> operation
>>>>>> ordering choreography out of the interface definition and make it
>>>>>> the responsibility of the provider implementation to enforce.
>>>>>>
>>>>>> The reason for this is that there are some common cases that
>>>>>> can't
>>>>>> be enforced declaratively. For example, consider a "shopping
>> cart"
>>>>>> scenario with the following operations:
>>>>>> create() create a new empty shopping cart
>>>>>> add() add an item to the cart
>>>>>> remove() remove an item currently in the cart
>>>>>> checkout() purchase the items currently in the cart
>>>>>>
>>>>>> We can declaratively assert that create() must be called first,
>>>>>> followed by add(), optionally followed by some combination of
>>>>>> add() and remove() calls, followed by checkout(). We can't say
>>>>>> declaratively that when calling remove(), the item being removed
>>>>>> must already be in the cart. We can require an add() call before
>>>>>> a remove() call, but this add() call could have added a different
>>>>>> item from that being removed.
>>>>>>
>>>>>> There are many similar cases where declarative annotations are
>>>>>> not
>>>>>> sufficient for fully defining operation ordering constraints. If
>>>>>> we
>>>>>> are going to include a "conversation" or "stateful correlation"
>>>>>> mechanism in SCA, with begin/continue/end operation semantics
>>>>>> that
>>>>>> control the creation/retention/removal of implementation
>> instances,
>>>>>> I think these are best treated as part of the service
>>>>>> implementation
>>>>>> because they are closely coupled to the design of its business
>>>> logic.
>>>>>>
>>>>>> The interface needs to fully describe the semantics that the
>> client
>>>>>> must observe when using it, including not only the ordering of
>>>>>> calls
>>>>>> but also the parameters that may validly be passed on those calls
>>>>>> (as in the add/remove case described above). However, the
>>>> management
>>>>>> of implementation state by the service provider should not be
>>>> visible
>>>>>> to the client and therefore should not be part of the interface.
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>> Martin Chapman wrote:
>>>>>>> Probably getting a bit too indepth for an email discussion but
>>>>>>> I'll
>>>>>> add a
>>>>>>> couple of more comments.
>>>>>>>
>>>>>>> I think we both agree that when we annotate an interface we are
>>>>>> further
>>>>>>> defining the contract that interface offers. For a simple non-
>>>>>> bidirectional
>>>>>>> interface, the annotations can work, but as soon as we add in
>>>>>>> bi-
>>>>>> directional
>>>>>>> and multi-party we need more. In the bi-directional case, we may
>>>>>>> need
>>>>>>> annotations to say "if you invoke X, I will invoke y back",
>>>>>>> and a
>>>>>>> multi-party case something like "when x is invoked, I will
>>>>>>> invoke Z
>>>>>> on
>>>>>>> another party (as well as call you back with y!)". This
>>>>>>> becomes a
>>>>>> notational
>>>>>>> mess and IMHO is best left to other languages (which I believe
>>>>>>> we
>>>>>> already
>>>>>>> resolved).
>>>>>>>
>>>>>>> I think the prime use case is really in being able to make sure
>>>>>>> you
>>>>>> get back
>>>>>>> to the same instance, and this I see is orthogonal to the
>> contract
>>>>>> approach
>>>>>>> that details partial ordering of operations. Maybe we could
>>>>>>> explore
>>>>>> this
>>>>>>> approach instead.
>>>>>>>
>>>>>>> Martin.
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Jim Marino [mailto:jim.marino@gmail.com]
>>>>>>>> Sent: 12 December 2008 19:54
>>>>>>>> To: Martin Chapman
>>>>>>>> Cc: 'OASIS Assembly'
>>>>>>>> Subject: Re: [sca-assembly] Conversational services
>>>>>>>>
>>>>>>>> Hi Martin,
>>>>>>>>
>>>>>>>> Comments inline as usual...
>>>>>>>>
>>>>>>>> Jim
>>>>>>>>
>>>>>>>> On Dec 11, 2008, at 6:07 AM, Martin Chapman wrote:
>>>>>>>>
>>>>>>>>> Jim,
>>>>>>>>>
>>>>>>>>> My main concern lies with the simplistic concepts we have, and
>>>>>>>>> in
>>>>>> the
>>>>>>>>> annotations we have done for wsdl.
>>>>>>>>> We only have the "endsConversation" annotation, and I cannot
>>>>>>>>> tell
>>>>>> by
>>>>>>>>> looking
>>>>>>>>> at the wsdl what operation starts a conversation, or even if
>>>>>>>>> an
>>>>>>>>> operation is
>>>>>>>>> required to be in a conversation. In addition, I cannot call
>>>>>>>>> an
>>>>>>>>> operation
>>>>>>>>> with an "endsConversation" and allow the option of continuing
>>>>>>>>> the
>>>>>>>>> conversation, so we force an end/terminate/cancel operation to
>>>>>>>>> be
>>>>>>>>> explicitly
>>>>>>>>> defined. Only having the "endsConverstaion" annotation, and
>>>> having
>>>>>>>>> assumptions about the other operations in the same interface
>>>>>>>>> is
>>>>>>>>> why
>>>>>>>>> I say
>>>>>>>>> its half-baked. I'm sure it suits some simple use cases, but
>>>>>>>>> it
>>>>>>>>> doesn't
>>>>>>>>> solve the general case, and doesn't address the multi-party
>>>>>>>>> case.
>>>>>>>>>
>>>>>>>> It looks as if we agree that "conversations," "stateful
>>>>>> interactions,"
>>>>>>>> or whatever they are called are important for SCA (I will use
>>>>>>>> "conversations" to describe them). That's good. Also, I think
>>>>>>>> we
>>>>>>>> can
>>>>>>>> accommodate your concerns with some very minor additions to the
>>>>>>>> current conversational model. This is also good given the time
>>>>>>>> constraints we are under and the risks associated with
>> developing
>>>> a
>>>>>>>> completely new model for these types of interactions. It also
>>>>>>>> sounds
>>>>>>>> as if you agree with me that conversational lifecycle should be
>>>>>>>> reflected in the service contract. Others may have a different
>>>>>>>> opinion. For example, Simon has proposed in the context of the
>>>> Java
>>>>>>>> work group that conversational lifecycle may be an
>> implementation
>>>>>>>> detail. I think conversational lifecycle is part of the service
>>>>>>>> contract for the reasons you state above. Taking that position
>> as
>>>> a
>>>>>>>> starting point, I wanted to go into more detail about how I
>> think
>>>>>>>> we
>>>>>>>> can accommodate your concerns.
>>>>>>>>
>>>>>>>> At this point it would be good to outline the semantics of the
>>>>>>>> conversational lifecycle as it is currently laid out in the
>>>>>>>> specs:
>>>>>>>>
>>>>>>>> 1. All operations begin a conversation if none exits.
>>>>>>>> 2. If a conversation already exists, all operations continue
>>>>>>>> it.
>>>>>>>> 3. If an operation is marked with endsConversation, the
>>>>>>>> conversation
>>>>>>>> will be ended after the operation completes.
>>>>>>>> 4. If an operation is called after an endsConversation
>>>>>>>> operation
>>>>>>>> completes, a new conversation begins
>>>>>>>> 5. It is not possible for a conversational service to have a
>> non-
>>>>>>>> conversational operation.
>>>>>>>>
>>>>>>>> From this, I believe it is always possible to determine the
>>>> precise
>>>>>>>> conversational semantics of an operation on a conversational
>>>>>> service.
>>>>>>>> As you mentioned above, in some scenarios it is useful to
>>>> demarcate
>>>>>> an
>>>>>>>> operation that starts a conversation from one that continues
>>>>>>>> it. A
>>>>>>>> while back, we did have a for beginsConversation annotation.
>>>>>>>> Perhaps
>>>>>>>> we could reinstate it with the following broadly sketched
>>>>>>>> semantics:
>>>>>>>>
>>>>>>>> 1. Conversational services have three states: begin, continue,
>>>>>>>> and
>>>>>> end
>>>>>>>> 2. If a service contract has an operation marked with
>>>>>>>> beginsConversation, invocations of that method begin the
>>>>>> conversation
>>>>>>>> lifecycle. Clients must invoke an operation marked with
>>>>>>>> beginsConversation prior to other operations not marked with
>>>>>>>> beginsConversation.
>>>>>>>> 3. Multiple operations on a service contract may be marked with
>>>>>>>> beginsConversation.
>>>>>>>> 4. Methods not marked with beginsConversation or
>> endsConversation
>>>>>>>> continue the conversation lifecycle.
>>>>>>>> 5. It is an error to invoke the same beginsConversation method
>>>>>>>> twice
>>>>>>>> or multiple methods marked with beginsConversation without
>>>> invoking
>>>>>> an
>>>>>>>> operation marked with endsConversation
>>>>>>>> 6. If no operations are marked with beginsConversation, then
>>>>>>>> invocations on all operations will begin a conversation if one
>> is
>>>>>> not
>>>>>>>> started or continue an existing conversation
>>>>>>>>
>>>>>>>> One thing I don't quite understand is your statement that " I
>>>>>>>> cannot
>>>>>>>> call an operation with an "endsConversation" and allow the
>> option
>>>>>>>> of
>>>>>>>> continuing the conversation, so we force an end/terminate/
>>>>>>>> cancel
>>>>>>>> operation to be explicitly defined." Couldn't this be handled
>> by
>>>>>>>> existing mechanisms where an operation is not marked with
>>>>>>>> @EndsConversation but the service provider (if written in Java)
>>>>>>>> invokes Conversation.end()? Given this, I think for clarity it
>> is
>>>>>> best
>>>>>>>> to require a conversation to be ended if marked with
>>>>>> @EndsConversation
>>>>>>>> so the semantics are unambiguous. Is there a use case where
>>>>>>>> this
>>>>>> would
>>>>>>>> not be appropriate?
>>>>>>>>
>>>>>>>>
>>>>>>>>> There are two ways to do this properly IMHO:
>>>>>>>>>
>>>>>>>>> 1. extend the declarative style with begin, continue etc.
>>>> One can
>>>>>>>>> even envisage specifying the valid sequences of operation
>> calls.
>>>>>>>>> Work was
>>>>>>>>> done in the 80's on extended open predicate path expressions
>>>> which
>>>>>>>>> is one
>>>>>>>>> example of this approach:
>>>>>>>>> http://www.ansa.co.uk/ANSATech/93/Primary/10100002.pdf.
>>>>>>>>>
>>>>>>>> Thanks for the link but I think this type of approach is
>> probably
>>>>>> more
>>>>>>>> complex than is warranted and, as you mention below, is best
>>>>>>>> handled
>>>>>>>> by specialized implementation types.
>>>>>>>>
>>>>>>>>
>>>>>>>>> 2. The other way is the programmatic approach (not sure
>>>> this is
>>>>>>>> the
>>>>>>>>> right word). This is where there are no annotations on
>>>>>>>>> operations
>>>>>>>>> per say,
>>>>>>>>> but rather invocations are scoped on the client side with
>> begin/
>>>>>>>>> end
>>>>>>>>> markers,
>>>>>>>>> much like one would do when writing transactions - though of
>>>>>>>>> course
>>>>>>>>> the
>>>>>>>>> server has to be suitable enabled.
>>>>>>>>>
>>>>>>>> I think the dichotomy between declarative and programmatic is
>>>> often
>>>>>> a
>>>>>>>> false one. For example, activity-based approaches are often
>>>>>> considered
>>>>>>>> programmatic and an analogy is drawn to transactional behavior.
>>>>>>>> However, starting with JEE and arguably before that,
>>>>>>>> declarative
>>>>>>>> approaches to transaction management have largely supplanted
>>>>>>>> programmatic ones for most application use cases. Arguably the
>>>> idea
>>>>>> of
>>>>>>>> declarative transactions was one of the things EJB got right,
>>>>>>>> even
>>>>>> if
>>>>>>>> it got the specific semantics wrong.
>>>>>>>>
>>>>>>>> The current conversational model is declarative and we would do
>>>>>>>> well
>>>>>>>> to keep it that way for a number of reasons. One is to make
>>>>>>>> wiring
>>>>>>>> more fail-safe. For example, if conversation propagation were
>>>>>>>> programmatic, how could a wiring algorithm determine a binding
>>>>>>>> can
>>>>>> be
>>>>>>>> safely applied (i.e. it supports conversation propagation)
>>>> without
>>>>>>>> introspection of the implementation "code" (bytecode in the
>>>>>>>> case
>>>> of
>>>>>>>> JVM-based implementations)?
>>>>>>>>
>>>>>>>>
>>>>>>>>> Approach 1 doesn't solve the multi-party case though and one
>>>> could
>>>>>>>>> argue
>>>>>>>>> that you are getting into choreography territory.
>>>>>>>>> Approach 2 requires activity/coordination services and is
>>>> probably
>>>>>> a
>>>>>>>>> more
>>>>>>>>> general solution to the problem.
>>>>>>>>>
>>>>>>>> Could you elaborate what you are thinking and the use cases not
>>>>>>>> covered by existing mechanisms?
>>>>>>>>
>>>>>>>>> So this is what leads me to the conclusion that either we do
>> the
>>>>>> job
>>>>>>>>> fully
>>>>>>>>> and properly, or we remove the feature for this round of SCA.
>>>>>>>>>
>>>>>>>> I'd be interested to see if your concerns with the existing
>>>>>> mechanisms
>>>>>>>> are addressed by the above. If not, can you outline some
>> specific
>>>>>>>> application uses cases we could work through? Having some
>>>>>>>> actual
>>>>>>>> examples (potentially composites) would help us bring these
>>>>>>>> issues
>>>>>> to
>>>>>>>> the fore.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Jim
>>>>>>>>
>>>>>>>>> Martin.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Jim Marino [mailto:jim.marino@gmail.com]
>>>>>>>>>> Sent: 09 December 2008 17:35
>>>>>>>>>> To: OASIS Assembly
>>>>>>>>>> Subject: [sca-assembly] Conversational services
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Martin mentioned Oracle's experience with conversational
>>>> services
>>>>>>>> led
>>>>>>>>>> them to the conclusion that they were "half-baked" and too
>>>>>>>>>> complex
>>>>>>>> on
>>>>>>>>>> the Assembly call today. Unfortunately, time ran out before I
>>>>>> could
>>>>>>>>>> ask him to elaborate. From an end-user perspective,
>>>> conversations
>>>>>>>> are
>>>>>>>>>> a critical part of our applications. Without them, we will
>>>> likely
>>>>>> be
>>>>>>>>>> forced to adopt a proprietary approach (or potentially look
>>>>>>>>>> to
>>>>>>>>>> another
>>>>>>>>>> technology), which for obvious reasons we don't want to do.
>>>> Based
>>>>>> on
>>>>>>>>>> my discussions in the past with other end-users, I don't
>>>>>>>>>> think I
>>>>>> am
>>>>>>>>>> alone in my views.
>>>>>>>>>>
>>>>>>>>>> As some background, we are currently building several
>>>>>>>>>> European
>>>>>>>> inter-
>>>>>>>>>> bank payment and ATM processing systems which are in various
>>>>>> stages
>>>>>>>>>> of
>>>>>>>>>> production use. The size of these applications are quite
>>>>>>>>>> large
>>>>>> (over
>>>>>>>>>> 150 composites each) and the requirements challenging, but
>>>>>>>>>> due
>>>> to
>>>>>>>>>> SCA's ease-of-use, we were able to implement them
>>>>>>>>>> successfully
>>>>>> with
>>>>>>>>>> developers who had no prior SCA exposure and relatively
>> limited
>>>>>>>>>> experience with service-based architectures. In building
>>>>>>>>>> these
>>>>>>>>>> applications, conversational services allowed us to greatly
>>>>>> simplify
>>>>>>>>>> many previously complex tasks, such as large document
>>>>>>>>>> processing
>>>>>> and
>>>>>>>>>> managing JPA persistence contexts. From a cost and ongoing
>>>>>>>>>> maintenance
>>>>>>>>>> standpoint, conversational service support has allowed us to
>>>>>> remove
>>>>>>>>>> an
>>>>>>>>>> enormous amount of "boilerplate" code that existed in our
>>>>>>>>>> legacy
>>>>>>>>>> systems.
>>>>>>>>>>
>>>>>>>>>> We were able to support conversational services in our SCA
>>>>>>>>>> infrastructure in a relatively straightforward way. So far,
>>>> based
>>>>>> on
>>>>>>>>>> our application throughput requirements (processing 100
>> million
>>>>>>>>>> transactions in a three hour period), we have not encountered
>>>> any
>>>>>>>>>> performance issues related to conversations.
>>>>>>>>>>
>>>>>>>>>> I'm sure there are areas where they can be improved. For
>>>> example,
>>>>>>>>>> multi-party conversations is one, which we have implemented
>>>>>>>>>> as a
>>>>>>>>>> proprietary extension in our infrastructure. There is also
>>>>>>>>>> the
>>>>>>>>>> question of inter-operability, although I don't view that as
>>>>>>>>>> necessarily important at this stage given SCA runtimes from
>>>>>>>> different
>>>>>>>>>> vendors are not likely to interoperate (e.g. different vendor
>>>>>>>>>> runtimes
>>>>>>>>>> participating in the same domain) any time in the near
>>>>>>>>>> future.
>>>>>>>>>> However, before we remove such an important feature, I would
>>>> like
>>>>>> to
>>>>>>>>>> understand the specifics of why conversations are too complex
>>>>>>>>>> both
>>>>>>>> to
>>>>>>>>>> use and implement. Granted, there are areas in need of
>>>>>>>>>> further
>>>>>>>>>> specification and refinement, but I think that can be said of
>>>>>>>>>> many
>>>>>>>>>> SCA
>>>>>>>>>> features.
>>>>>>>>>>
>>>>>>>>>> Not to single people out, but Martin and Mike, you both made
>>>>>>>>>> these
>>>>>>>>>> claims on the call. Could you please elaborate with technical
>>>>>>>>>> details?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Jim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --------------------------------------------------------------
>> --
>>>> --
>>>>>> --
>>>>>>>> -
>>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------
>> --
>>>> -
>>>>>> 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
>>>
>>>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]