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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

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


Subject: RE: [wsbpel] RE: Issue - 77 - Motion to require access to values not defined in portType


Satish,

Please let me know what you think of my message following the one below, where I reformulate the issue and show that the problem is there even if we only talk purely in terms of abstract interfaces.

Ugo

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Sunday, November 02, 2003 1:41 PM
> To: Ugo Corda; Ron Ten-Hove
> Cc: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] RE: Issue - 77 - Motion to require access to
> values not defined in portType
> 
> 
> Ugo,
>  
> I completely agree that very many real BPEL implementations 
> communicate using SOAP, and they will probably use MIME and 
> other packaging formats for some time as well.  I am 
> questioning the wisdom of going beyond interface 
> specifications to address all the possibilities.  As Yaron 
> pointed out many things in a message, headers, attachments, 
> etc may be optional stuff, and addressing the complexity of 
> figuring out meaningful access and usage modes for optional 
> and binding level data at the level of abstraction BPEL 
> targets does not seem like a good idea, especially for the 
> initial version of this standard.
>  
> Satish
> 
> ________________________________
> 
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> Sent: Sun 11/2/2003 10:33 AM
> To: Satish Thatte; Ron Ten-Hove
> Cc: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] RE: Issue - 77 - Motion to require 
> access to values not defined in portType
> 
> 
> 
> Satish,
> 
> Please let's be realistic here. Real BPEL implementations 
> deal with SOAP and SOAP headers. Whether we like it or not, 
> real BPEL implementations are able to process some SOAP 
> headers and not others. Ignoring the problem does not make it 
> go away, and it's like trying to hide behind a finger. I 
> believe the spec should say something about this, one way or another.
> 
> Ugo
> 
> > -----Original Message-----
> > From: Satish Thatte [mailto:satisht@microsoft.com]
> > Sent: Saturday, November 01, 2003 11:24 PM
> > To: Ugo Corda; Ron Ten-Hove
> > Cc: wsbpel@lists.oasis-open.org
> > Subject: RE: [wsbpel] RE: Issue - 77 - Motion to require access to
> > values not defined in portType
> >
> >
> > Ugo and Ron,
> > 
> > Where in BPEL do we even talk about SOAP, headers, body,
> > etc.?  We only talk about abstract message types.  And if we
> > are using WSDL 1.1 they may have multiple parts with
> > independent XML (or I suppose other) types.  In WSDL 2.0 they
> > may be pure XML types.  We know nothing about how they are
> > rendered in any wire format. 
> > 
> > My basic position is that we stick to message types as
> > presented in the web service interfaces a BPEL process
> > imports or exports.  Anything else opens a Pandora's box of
> > binding variability and complexity that we should not be 
> dealing with.
> > 
> > Satish
> >
> > ________________________________
> >
> > From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> > Sent: Sat 11/1/2003 11:24 AM
> > To: Ron Ten-Hove
> > Cc: wsbpel@lists.oasis-open.org
> > Subject: RE: [wsbpel] RE: Issue - 77 - Motion to require
> > access to values not defined in portType
> >
> >
> > Ron,
> > 
> > Good point. (The WSDL 1.1 example you are referring to is
> > Example 3 in sec. 3.1).
> > 
> > This, by the way, shows that the position that BPEL should
> > only deal with bodies is not even realized in the current
> > BPEL spec. In fact, all headers defined in a way similar to
> > the example mentioned above are perfectly accessible by BPEL.
> > It's only headers that are defined in a separate message that
> > are not accessible by BPEL - which is the original scope of
> > this Issue.
> > 
> > The only way to reconcile this inconsistency between headers
> > that BPEL can process and those that it cannot process would
> > be to say that headers specified in the same abstract message
> > as the body are "application" headers (which BPEL can see),
> > and those specified in a separate abstract message are QoS
> > headers (which BPEL cannot see). But I would challenge
> > anybody to find a single WS spec where such distinction is
> > clearly specified ...
> > 
> > Ugo
> >
> >       -----Original Message-----
> >       From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
> >       Sent: Saturday, November 01, 2003 10:41 AM
> >       To: Ugo Corda
> >       Cc: wsbpel@lists.oasis-open.org
> >       Subject: Re: [wsbpel] RE: Issue - 77 - Motion to
> > require access to values not defined in portType
> >      
> >      
> >       Ugo,
> >      
> >           See BP 1.0 R2712; this applies only to doc-literal
> > encodings, but I believe that will be the most common case in
> > the SOAP-flavoured version of the  BPEL universe. This
> > restricts us to one message part in the body; other parts
> > must be carried as headers. This is a fairly common practice
> > anyway; the message body, when extracted from the S:Envelope
> > and S:Body wrappers, constitutes a proper XML document (sans
> > the <?xml?> header or doc-type declarations), rather than a
> > fragment. IIRC, the WSDL 1.1 spec even includes an example of
> > how to do this.
> >      
> >       Cheers,
> >       -Ron
> >      
> >       (Sorry about the delayed reply; I was working from home
> > yesterday, and lost power for 12 hours. First rule of network
> > computing: failures happen; expect them!)
> >      
> >       Ugo Corda wrote:
> >      
> >
> >               Ron,
> >               
> >               Could you please clarify your point below about
> > BP 1.0 conformance? As far as I know, BP 1.0 is neutral in 
> this area.
> >               
> >               Ugo
> >
> >                       -----Original Message-----
> >                       From: Ron Ten-Hove
> > [mailto:Ronald.Ten-Hove@Sun.COM]
> >                       Sent: Friday, October 31, 2003 10:36 AM
> >                       To: Frank Leymann
> >                       Cc: wsbpel@lists.oasis-open.org
> >                       Subject: Re: [wsbpel] RE: Issue - 77 -
> > Motion to require access to values not defined in portType
> >                      
> >                      
> >                       Frank,
> >                      
> >                           Your points about the user of SOAP
> > headers are well taken. Just a few comments in response:
> >                      
> >
> >                       *       The use of composability via
> > SOAP header blocks is applicable at several levels in the
> > "stack." It is conceivable that business process-level
> > protocols may be supported by such mechanisms (some forms of
> > transactions are sneaking up on this). Could this eventually
> > require BPEL "awareness" of header blocks in support of 
> > higher-level protocols?
> >                              
> >                       *       Also, a message doesn't
> > necessarily have a single payload. This is commonly "worked
> > around" in SOAP/WSDL by placing the extra payloads into
> > header blocks, especially if conformance to BP 1.0 is desired.
> >                       *       While we, as a technically
> > sophisticated group would not abuse SOAP/WSDL in unnatural
> > ways, there are plenty of people devising web services today
> > that have no such sensibilities. Are we, the BPEL TC, to
> > stick to the "high road" and refuse to treat with such
> > abominations, or take the "low road" and get a bit dirty in
> > process (no pun intended). Will this substantially affect
> > adoption of BPEL?
> >                              
> >
> >                       Regards,
> >                       -Ron
> >                      
> >                       Frank Leymann wrote:
> >                      
> >
> >                               Yaron (or do you prefer
> > "Yoland" in the meantime?   ;-)),
> >                              
> >                               the scope of the problem you
> > describe is generic, not coupled to BPEL at
> >                               all. Thus, the BPEL TC
> > shouldn't attempt at all to solve that problem. This
> >                               includes defining new
> > mechanisms to declare optional headers, teach people
> >                               how to specify appropriate WSDL etc..
> >                              
> >                               The fundamental importance of
> > SOAP headers is to provide for composability
> >                               of Web service mechanisms at
> > the message level.  So, headers are about
> >                               folding in "QoS" aspects like
> > security, reliability, addressability,
> >                               transactionality etc etc.  It
> > is the SOAP body that is intended to carry
> >                               the "real" application payload.
> > I  personally don't think that application
> >                               programmers should take care
> > about headers (i.e. QoS-like stuff), but take
> >                               care only of the body. The
> > "environment" should take care about headers,
> >                               i.e. QoS-like stuff.
> >                              
> >                               Regards,
> >                               Frank
> >                              
> >                               -------------------
> >                               Prof. Dr. Frank Leymann,
> > Distinguished Engineer
> >                               IBM Software Group
> >                               Member, IBM Academy of Technology
> >                              
> >                               Phone 1:  +49-7031-16 39 98
> >                               Phone 2:  +49-7056-96 50 67
> >                               Mobile:  +49-172-731 5858
> >                               --------------------
> >                              
> >                              
> >                              
> >                              
> >                              
> >                               Please respond to
> > <ygoland@bea.com> <mailto:ygoland@bea.com>
> >                              
> >                               To:    Frank
> > Leymann/Germany/IBM@IBMDE, <wsbpel@lists.oasis-open.org>
> > <mailto:wsbpel@lists.oasis-open.org>
> >                               cc:
> >                               Subject:    RE: [wsbpel] RE: 
> > Issue - 77 - Motion to require access to
> >                                      values not defined in portType
> >                              
> >                              
> >                               I'm unsure how one
> > differentiates between middleware payload and endpoint
> >                               payload. For example, there are
> > many good reasons why an endpoint would
> >                               want
> >                               to be able to access a SOAP
> > header containing digital signature or
> >                               correlation information. So I
> > don't think we can ever say that it's o.k.
> >                               not
> >                               to be able to get to the SOAP headers.
> >                              
> >                               It has been suggested that
> > perhaps we could tell people to write enhanced
> >                               WSDL definitions that contain
> > headers that are present at the SOAP level
> >                               but
> >                               weren't defined in the original WSDL.
> >                              
> >                               Unfortunately this isn't a
> > workable solution in a case where the SOAP
> >                               header
> >                               is itself optional. For
> > example, one could have an operation that MAY be
> >                               digital signed which means that
> > in some cases you will have a digital
> >                               signature header and in other
> > cases you wouldn't. WSDL 1.1 is incapable of
> >                               expressing the concept of
> > 'optional' headers.
> >                              
> >                               I think the easiest way to get
> > around this problem would be for the group
> >                               to
> >                               introduce a new attribute for
> > use with WSDL that would specify when a
> >                               message part is optional both
> > for incoming and outgoing messages. The
> >                               normative behavior would then
> > become that you would have to take the
> >                               original WSDL, which doesn't
> > mention the optional headers, mark it up to
> >                               include those headers (i.e. the
> > previously suggested 'enhanced' WSDL) and
> >                               then mark those headers as optional.
> >                              
> >                               If a message is received
> > without the optional part then that part would be
> >                               left as uninitialized in the
> > message variable and accessing that part of
> >                               the
> >                               message variable would throw a
> > fault. We would have to introduce a function
> >                               to allow one to test if a part
> > is uninitialized.
> >                              
> >                               If a message is sent whose
> > definition contains an optional part then if the
> >                               part is never assigned to,
> > that's fine, it just means that the part won't
> >                               appear in the outgoing message.
> >                              
> >                               The main downside I see to this
> > proposal is that if someone sends you a
> >                               message with content you just
> > weren't expecting (For example, an
> >                               intermediary throws in a SOAP
> > header that is made up) then you can't get to
> >                               it. But the only use case I can
> > see for wanting access to that information
> >                               is for logging purposes and I'm
> > not sure that is a compelling enough use
> >                               case to worry about this in V1.
> >                              
> >                               But I believe it is important
> > that one be able to both send and receive
> >                               optional message parts (e.g.
> > optional SOAP headers) so some change to the
> >                               BPEL standard seems called for.
> >                              
> >                                            Just an opening thought,
> >                              
> >                                                        Yaron
> >                              
> >                              
> >                                
> >
> >                                       -----Original Message-----
> >                                       From: Frank Leymann
> > [mailto:LEY1@de.ibm.com]
> >                                       Sent: Friday, October
> > 24, 2003 6:47 AM
> >                                       To: 
> wsbpel@lists.oasis-open.org
> >                                       Subject: RE: [wsbpel]
> > RE: Issue - 77 - Motion to require access to
> >                                       values not defined in portType
> >                                      
> >                                      
> >                                      
> >                                       The WSDL 1.2/2.0 group
> > is currently considering to remove headers from
> >                                       messages at all, and
> > replacing this by appropriate applications of
> >                                       "policies".  I read
> > this as another indicator that application data is
> >                                       assumed to be part of
> > the message body, and that headers should carry
> >                                       "middleware payload"
> > (indicated by appropriate "policies").
> >                                      
> >                                       Regards,
> >                                       Frank
> >                                      
> >                                       -------------------
> >                                       Prof. Dr. Frank
> > Leymann, Distinguished Engineer
> >                                       IBM Software Group
> >                                       Member, IBM Academy of
> > Technology
> >                                      
> >                                       Phone 1:  +49-7031-16 39 98
> >                                       Phone 2:  +49-7056-96 50 67
> >                                       Mobile:  +49-172-731 5858
> >                                       --------------------
> >                                      
> >                                      
> >                                      
> >                                      
> >                                      
> >                                       To:    Frank
> > Leymann/Germany/IBM@IBMDE, <wsbpel@lists.oasis-open.org>
> > <mailto:wsbpel@lists.oasis-open.org>
> >                                       cc:
> >                                       Subject:    RE:
> > [wsbpel] RE:  Issue - 77 - Motion to require access to
> >                                              values not
> > defined in portType
> >                                      
> >                                      
> >                                       I'm still not clear
> > whether it's expected that bpel users
> >                                       will sometimes
> >                                       have to construct
> >                                       bpel-convenient wsdl
> > for web-services that already have wsdl
> >                                       defintions
> >                                       but which don't give
> >                                       the required
> > accessiblity/granularity in the existing wsdl. The wsdl,
> >                                       with some accompanying
> >                                       free text description
> > of what the parameters are, might have been good
> >                                       enough for implementation
> >                                       of client and service
> > by hand, but now bpel wants a standard
> >                                       expression
> >                                       of some of that free text.
> >                                       Or would such wsdl
> > reworking be regarded as a Bad Thing ? it's
> >                                       conceptually a refinement,
> >                                       though whether it would
> > be visibly such in the two wsdl
> >                                       descriptions I'm
> >                                       not sure).
> >                                      
> >                                       If the bpel user is
> > expected to have such a trick in his mind (and
> >                                       perhaps his tools), would an
> >                                       alternative solution to
> > the underlying problem here be say if the
> >                                       abstract wsdl doesn't give you
> >                                       the access you want,
> > then write one that does. The bindings are then
> >                                       more explicit, but still below
> >                                       the woodwork from the
> > bpel position.
> >                                      
> >                                       Peter
> >                                      
> >                                      
> >                                      
> >                                          
> >
> >                                       -----Original Message-----
> >                                       From: Frank Leymann
> > [mailto:LEY1@de.ibm.com]
> >                                       Sent: 23 October 2003 11:57
> >                                       To: 
> wsbpel@lists.oasis-open.org
> >                                       Subject: Re: [wsbpel]
> > RE: Issue - 77 - Motion to require
> >                                       access to values not
> > defined in portType
> >                                      
> >                                      
> >                                      
> >                                       I wholeheartedly
> > support Satish's position!
> >                                      
> >                                       Regards,
> >                                       Frank
> >                                      
> >                                       -------------------
> >                                       Prof. Dr. Frank
> > Leymann, Distinguished Engineer
> >                                       IBM Software Group
> >                                       Member, IBM Academy of
> > Technology
> >                                      
> >                                       Phone 1:  +49-7031-16 39 98
> >                                       Phone 2:  +49-7056-96 50 67
> >                                       Mobile:  +49-172-731 5858
> >                                       --------------------
> >                                      
> >                                      
> >                                      
> >                                      
> >                                      
> >                                       To:   
> > <ygoland@bea.com> <mailto:ygoland@bea.com> , "Furniss, Peter"
> >                                      
> > <Peter.Furniss@choreology.com> 
> <mailto:Peter.Furniss@choreology.com> ,
> >                                             
> > <wsbpel@lists.oasis-open.org> <mailto:wsbpel@lists.oasis-open.org>
> >                                       cc:
> >                                       Subject:    [wsbpel]
> > RE:  Issue - 77 - Motion to require
> >                                       access to values
> >                                              not defined in portType
> >                                      
> >                                      
> >                                       I was simply making the
> > point that BPEL is deliberately
> >                                       agnostic about
> > bindings, thus allowing deployment
> >                                       flexibility.  Process
> > models that are meant to capture the
> >                                       essence of business
> > process logic in a portable way should
> >                                       not become dependent on
> > deployment descriptors, which is at
> >                                       least the intent of the
> > binding element of WSDL 1.1 service
> >                                       descriptions.  The fact
> > that the intent may be imperfectly
> >                                       realized is not a
> > reason to throw the principle out.
> >                                      
> >                                      
> >                                       From: Yaron Goland
> > [mailto:ygoland@bea.com]
> >                                       Sent: Wednesday,
> > October 22, 2003 3:27 PM
> >                                       To: 'Furniss, Peter';
> > wsbpel@lists.oasis-open.org; Satish Thatte
> >                                       Subject: Issue - 77 -
> > Motion to require access to values not
> >                                       defined in portType
> >                                      
> >                                       In a previous mail in
> > this thread Satish Thatte said:
> >                                      
> >                                      
> >                                       We must assume that the
> > design of a portType is done
> >                                       properly, i.e., the
> > "application level" data required to
> >                                       process a message in a
> > business process is part of the
> >                                       definition of each
> > message. If this assumption is violated
> >                                       there is not much we can do.
> >                                      
> >                                      
> >                                       Section 3.7 of the WSDL
> > 1.1 states " It is not necessary to
> >                                       exhaustively list all
> > headers that appear in the SOAP
> >                                       Envelope using
> > soap:header. " This means that even a portType
> >                                       which has been done
> > 'properly' may not necessarily have
> >                                       messages for every
> > header that may appear in the SOAP
> >                                       envelope received over
> > the wire. Given that even WSDL 1.1
> >                                       recognizes that one can
> > reasonably receive SOAP headers that
> >                                       weren't defined in the
> > portType it would seem reasonable for
> >                                       BPEL to provide a
> > mechanism to access such values.
> >                                      
> >                                      
> >                                       I would therefore
> > propose that we put forward a motion that
> >                                       requires the group to
> > define a mechanism that will enable
> >                                       access to the full
> > contents of a WSDL described message as
> >                                       transmitted over the
> > wire including contents not specifically
> >                                       defined in the portType
> > definition.
> >                                      
> >                                      
> >                                           Yaron
> >                                       -----Original Message-----
> >                                       From: Furniss, Peter
> > [mailto:Peter.Furniss@choreology.com]
> >                                       Sent: Tuesday, October
> > 21, 2003 5:14 PM
> >                                       To: 
> wsbpel@lists.oasis-open.org
> >                                       Subject: [wsbpel]
> > Reannouncement - Issue - 77 - BPEL cannot
> >                                       handle some SOAP header
> > bindings Due to a mistake on my part,
> >                                       this issue was
> > erroneously announced as number 78. It is
> >                                       really number 77 and is
> > in the issues list with that number.
> >                                       Here it is again with a
> > hand-edit of the number.
> >                                      
> >                                       This issue has already
> > had considerable discussion as
> >                                       "Possible new issue
> > ...", which I've grandfathered into the
> >                                       links list - please use
> > an Issue - 77 - subject line on
> >                                       further discussion messages.
> >                                      
> >                                       Peter
> >                                        -----Original Message-----
> >                                        From: Furniss, Peter
> >                                        Sent: 21 October 2003 21:36
> >                                        To: 
> wsbpel@lists.oasis-open.org
> >                                        Subject: [wsbpel]
> > Issue - 78 - BPEL cannot handle some SOAP
> >                                       header  bindings
> >                                      
> >                                      
> >                                        This issue has been
> > added to the wsbpel issue list. The
> >                                       issues list is  posted
> > as a Technical Committee document to
> >                                       the OASIS WSBPEL TC
> > pages on a  regular basis. The current
> >                                       edition, as a TC
> > document, is the most recent  document with
> >                                       the title in the
> > "Issues" folder of the WSBPEL TC document
> >                                       list - the next posting
> > will include this issue. The list
> >                                       editor's working  copy,
> > which will normally include an issue
> >                                       when it is announced,
> > is  available at this constant URL.
> >                                      
> >                                      
> >                                        Issue - 77   - BPEL
> > cannot handle some SOAP header bindings
> >                                        Status: open
> >                                        Date added: 21 Oct 2003
> >                                        Submitter: Ugo Corda
> >                                        Date submitted: 21 
> October 2003
> >                                        Description: Let's
> > suppose we have the following WSDL file:
> >                                       <message name="In">
> >                                            <part
> > name="InPart" element="InElement"/>
> >                                        </message>
> >                                      
> >                                      
> >                                      
> >                                      
> >                                      
> >                                      
> >                                      
> >                                      
> >                                        <message name="Header">
> >                                      
> >                                      
> >                                            <part
> > name="HeaderPart" element="HeaderElement"/>
> >                                      
> >                                      
> >                                        </message>
> >                                      
> >                                      
> >                                      
> >                                      
> >                                      
> >                                      
> >                                      
> >                                      
> >                                        <portType name="myPortType">
> >                                      
> >                                      
> >                                            <operation name="op1">
> >                                      
> >                                      
> >                                                <input message="In"/>
> >                                      
> >                                      
> >                                            </operation>
> >                                      
> >                                      
> >                                        </portType>
> >                                      
> >                                      
> >                                      
> >                                      
> >                                      
> >                                      
> >                                      
> >                                      
> >                                        <binding
> > type="myPortType" ... >
> >                                      
> >                                      
> >                                            <soap:binding ..../>
> >                                      
> >                                      
> >                                            <operation name="op1">
> >                                      
> >                                      
> >                                                <input>
> >                                      
> >                                      
> >                                                    <soap:body
> > parts="InPart" ...>
> >                                      
> >                                      
> >                                                   
> > <soap:header message="Header" part="HeaderPart" .../>
> >                                      
> >                                      
> >                                                </input>
> >                                      
> >                                      
> >                                            </operation>
> >                                      
> >                                      
> >                                        </binding>
> >                                        In this example, the
> > abstract operation "op1" refers to
> >                                       message "In", but  the
> > binding brings in an additional second
> >                                       message, "Header", for
> > the  concrete operation.
> >                                      
> >                                      
> >                                        It seems that BPEL
> > would not be able to process the "Header"
> >                                       information  in any
> > way. For instance, a "receive" operation
> >                                       would only be able to 
> > specify one inputVariable, which would
> >                                       be associated with the
> > "In" message  and not the "Header"
> >                                       message. In other
> > words, the "Header" message would  carry
> >                                       information to the
> > "receive" operation that BPEL would have
> >                                       no  access to.
> >                                      
> >                                      
> >                                        If this is the case,
> > new Web services defined with BPEL in
> >                                       mind could  easily
> > modify this scenario by defining both body
> >                                       and header as being
> > part  of a single message, but legacy Web
> >                                       services might be out
> > of reach for  BPEL.
> >                                        Links: Ugo Corda, 20
> > Oct 2003     Frank Leymann, 21 Oct
> >                                            
> >
> >                                       2003     Ugo
> >                                          
> >
> >                                        Corda, 21 Oct 2003    
> > Satish Thatte, 21 Oct 2003     Peter
> >                                       Furniss, 21
> >                                        Oct 2003     Ugo
> > Corda, 21 Oct 2003     Satish Thatte, 21
> >                                       Oct 2003     Ugo
> >                                        Corda, 21 Oct 2003    
> > Satish Thatte, 21 Oct 2003     Ugo
> >                                       Corda, 21 Oct
> >                                        2003
> >                                        Changes: 21 Oct 2003 -
> > new issue
> >                                      
> >                                      
> >                                      
> >                                        To comment on this
> > issue, please follow-up to this
> >                                       announcement on the 
> > wsbpel@lists.oasis-open.org list
> >                                       (replying to this
> > message should  automatically send your
> >                                       message to that list),
> > or ensure the subject line  as you
> >                                       send it starts "Issue -
> > 78 - [anything]" or is a reply to
> >                                       such a  message.
> >                                      
> >                                      
> >                                        To add a new issue,
> > see the issues procedures document (but
> >                                       the address  for new
> > issue submission is the sender of this
> >                                       announcement).
> >                                      
> >                                      
> >                                        To unsubscribe from
> > this mailing list (and be removed from
> >                                       the roster of  the
> > OASIS TC), go to
> >                                      
> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> >                                            
> >
> >                                       ave_workgroup.php
> >                                        . To unsubscribe from
> > this mailing list (and be removed from
> >                                       the roster
> >                                       of  the OASIS TC), go to
> >                                      
> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> >                                          
> >
> >                               ave_workgr
> >                               oup.php
> >                                .
> >                              
> >                              
> >                              
> >                              
> >                              
> >                               To unsubscribe from this
> > mailing list (and be removed from the roster of
> >                               the OASIS TC), go to
> >                              
> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> ave_workgr
>                                 oup.php.
>                                
>                                
>                                 To unsubscribe from this 
> mailing list (and be removed from the roster of
>                                 the OASIS TC), go to
>                                 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
ave_workgroup
                                .
                                php
                                .
                               
                               
                               
                               
                               
                               
                               
                                To unsubscribe from this mailing list (and be removed from the roster of
                                the
                                OASIS TC), go to
                                http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup
                                .
                                php.
                               
                               
                               
                                To unsubscribe from this mailing list (and be removed from the roster of
                                the OASIS TC), go to
                                http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php
                                .
                               
                               
                               
                               
                               
                               
                               
                                To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
                               
                                 





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