Decoupling of low-level and high-level MEP

Arkin, your idea here is very interesting to me.  I try to use an example 
to confirm my understanding ...

Business-level MEP
===============
- Submit PO
- A one-way message (no response is expected at the business level)

MEP SubmitPO {
         role: buyer, seller (implements PO-HandlerPT)
         sequence {
                 buyer invoke seller (operation = submitPO, portType = 
PO-HandlerPT)
         }
}

PortType PO-HandlerPT {
         Operation submitPO {
                 Input: (PO)
         }
}

However, since the PO must be send reliably (ie, it has certain QOS 
requirement).  Therefore, at the implementation level, this "business-layer 
MEP" is build on the RM MEP

Infrastructure-level MEP
==================

MEP RM {
     role: sender (implements RM-SenderPT), receiver (implements RM-ReceiverPT)
     sequence {
         while (no Ack received) {
             sender invoke receiver (operation = sendMessage, portType = 
RM-ReceiverPT)
             switch {
                 case1: {
                     receiver invoke sender (operation = sendAck, portType 
= RM-SenderPT)
                 }
                 case2: {
                     timeout
                 }
             }
         }
     }
}

PortType RM-ReceiverPT {
         Operation sendMessage {
                 Input: (Message, Ack-CallbackAddress)
         }
}

PortType RM-SenderPT {
         Operation sendAck {
                 Input: (Ack)
         }
}

Here is what happens at runtime ...

1) The buyer engage in the SubmitPO MEP when it follows the choreography 
definition and invoke the "submitPO" operation.
2) There is separate QOS requirement specified by the buyer (maybe 
communicate out of band) that the operation must be done reliably.
3) The binding layer (this is what you call the "protocol handler", 
consider it to be the client stub of the POHandlerPT) decides to use the RM 
services.  So it invoke the "sendMessage" operation of the RM-ReceiverPT 
instead (the client stub may encapsulate the business SOAP message inside 
the RM SOAP message).
4) The implementation of sendMessage (at receiver side, which you call the 
"protocol handler") invoke the sendAck operation of the sender side.  At 
the same time, it also invoke the "submitPO" operation of the receiver side.

The key point here is that the binding between the business-level-MEP and 
RM-MEP is captured "somewhere else" (what you call "out-of-band"), so that 
they can essentially decoupled with each other.  This "decoupling" 
introduce tremendously reusability and flexibility and still retain simplicity.

Do I accurately rephrase what you mean ?

Rgds, Ricky



> >Resent-Date: Fri, 18 Jul 2003 17:11:12 -0400 (EDT)
> >Date: Fri, 18 Jul 2003 14:10:53 -0700
> >From: Assaf Arkin <arkin@intalio.com>
> >Organization: Intalio
> >User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4)
> >Gecko/20030624
> >X-Accept-Language: en-us, en, he
> >To: "Burdett, David" <david.burdett@commerceone.com>
> >CC: Frank McCabe <frankmccabe@mac.com>,
> >         Martin Chapman <martin.chapman@oracle.com>,
> >         Steve Ross-Talbot <steve@enigmatec.net>,
> >         "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>,
> >         public-ws-chor@w3.org
> >Subject: Re: Grounding Choreographies (the atoms) - WAS Simple
> >Choreograph   y   composition suggestion
> >X-Archived-At: http://www.w3.org/mid/3F18625D.8060408@intalio.com
> >Resent-From: public-ws-chor@w3.org
> >X-Mailing-List: <public-ws-chor@w3.org> archive/latest/1303
> >X-Loop: public-ws-chor@w3.org
> >Sender: public-ws-chor-request@w3.org
> >Resent-Sender: public-ws-chor-request@w3.org
> >List-Id: <public-ws-chor.w3.org>
> >List-Help: <http://www.w3.org/Mail/>
> >List-Unsubscribe:
><mailto:public-ws-chor-request@w3.org?subject=unsubscribe>
> >
> >
> >Burdett, David wrote:
> >
> >>Assaf
> >>
> >>I agree that we need to agree on terminology, e.g. roles vs agents, I
> >>have no strong views on which is better.
> >>
> >>I also like the idea of using WSDL interfaces, however I can see some
> >>issues, for example: 1. Both the RM specs use SOAP to send their
> >>acknowledgement messages and retries. So, for example, if you had a
> >>WSDL definition that defined a PO as input and generated a PO Response
>
> >>as output, then how would the other RM messages be defined in the
> >>WSDL?
> >Out-of-band.
> >
> >You have one WSDL interface covering the operation you are trying to
> >perform. The PO request and PO response. That's the input to the
>service
> >and the output from the service.
> >
> >You have another WSDL interface covering the ack/resend/etc. That one
> >is
> >defined by the RM protocol. It is implemented by the RM Service. The RM
>
> >Service is used in combination with the PO service, but as an
>out-of-band
> >interaction that is used only if a particular protocol is chosen.
> >
> > From the pespective of the application you send a PO request and
> > receive
> > a PO response. The recevier's protocol handler recognizes the RM
>protocol
> > and uses the RM Service's endpoint to send back and ack.
> >
> >This has three obvious benefits:
> >
> >1. You define the RM interface exactly once. You don't need to define
> >specific operations, messages, etc each time you use RM. More
>reusability.
> >
> >2. You can decide if/when/which RM protocol to use without having to
> >change the interface definition. The protocol selection is carried in
>the
> >message.
> >
> >3. You can combine many different protocols in that way.
> >
> >Now, for just using RM it's possible to come up with some MEP that
> >would
> >be generally efficient. But the out-of-band model has more efficiency.
>For
> >example, if could ack multiple messages together, or request multiple
> >resends together. If you try to combine RM + coordination + security
> >context, your MEP would be hairy to define. But in this model you can
> >easily turn these protocol features on & off without having to create
>all
> >the possible MEPs.
> >
> >>2. If you then wanted to layer an MEP on top of this which included
> >>additional "signal" messages where each signal message was also sent
> >>using RM protocols then how would these be included in the WSDL?
> >Because you're making the protocol signals orthogonal to the actual
> >WSDL
> >interface, you let the protocol handler make the appropriate decisions
> >which signals to make. This allows it not only support ack/resend
>(easy),
> >but also to couple that with multiple-message acks, is-alive pings,
>flow
> >control, combining/splitting messages, etc.
> >
> >And you can combine any number of protocols like that. The RM would
> >typically be used for the duration of a single operation, while a
> >coordination protocol would involve multiple operations. Establishing a
>
> >security context (single sign-on) would do both since the context may
>last
> >longer than one operation, but may expire and be re-established before
>all
> >operations are completed.
> >
> >So that scheme seems to be the most efficient one in my opinion, and
> >also
> >allows for proper layering of different protocols (business and
>technical).
> >
> >arkin
> >
> >>3. How would you provide support for 1 and 2 above in WSDL in a way
> >>which allowed a single basic definition of the "business"
> >>choreography, e.g. you send a PO and get a PO response back, even
> >>though you could get variations in the actual signals and RM protocol
> >>used as well as the physical message format used?
> >>
> >>I'm not saying it can't be done, I just don't know how.
> >>
> >>Regards
> >>
> >>David
> >>
> >>-----Original Message-----
> >>From: Assaf Arkin [mailto:arkin@intalio.com]
> >>Sent: Friday, July 18, 2003 1:14 PM
> >>To: Burdett, David
> >>Cc: Frank McCabe; Martin Chapman; Steve Ross-Talbot; Champion, Mike;
> >>public-ws-chor@w3.org
> >>Subject: Re: Grounding Choreographies (the atoms) - WAS Simple
> >>Choreograph y composition suggestion
> >>
> >>
> >>It all boils down to terminology. I'm not suggesting any, just
> >>pointing
> >>out a problem.
> >>
> >>If we say "roles" and the WSA says "agents" then there's a mismatch.
> >>If
> >>the WSA defines an architecture in terms of agents interacting, but a
> >>choreography can't involve agents (that would be an orchestration)
>then
> >>we might have a problem there. We need to raise this and work out a
> >>terminology that is consistent across the board.
> >>
> >>So going back to Frank's original e-mail, either I didn't understand
> >>what
> >>was said, or we need to better align the usage of terminology between
>the
> >>two groups.
> >>
> >>
> >>As for what the interaction is, I much prefer if we talk in terms of
> >>WSDL
> >>interfaces. Then we won't have to go down into the details of HTTP,
> >>ack/resend, etc. When you express everything in terms of WSDL
>interface
> >>you are talking about these roles/agents interacting with each other.
>The
> >>protocol may end up using HTTP, it may include additional signals for
>RM,
> >>out-of-band signals for coordination, establish security context,
>whatever.
> >>
> >>Since this is already taken care of by other specifications that you
> >>can
> >>plug-in, I would much prefer to focus solely on use of WSDL
>interfaces.
> >>
> >>arkin
> >>
> >>Burdett, David wrote:
> >>
> >>
> >>
> >>>Assaf
> >>>
> >>>My take is that strictly speaking, a choreography is "A definition of
>
> >>>the sequence and conditions in which a set of interactions occur
> >>>between two roles".
> >>>
> >>>Where *interactions* include both individual (e.g. HTTP) messages as
> >>>well
> >>>
> >>as
> >>
> >>
> >>>higher level concepts such as a single "reliably delivered message"
> >>>which actually requires several HTTP message to implement, or at a
> >>>even higher level, concepts such as a "Request for Quote". Also roles
>
> >>>can include, at a low level, general concepts such as a "sender" and
> >>>"receiver" which could be appropriate when defining the choreography
> >>>associated with a RM protocol, or such business level concepts such
> >>>as "buyer" and "seller" when defining a business level
> >>>protocol/choreography.
> >>>
> >>>In both cases roles defined in the choreography are abstract and need
>
> >>>to be mapped to the physical instances which will often, but needn't
> >>>be - as Martin mentioned, web services. If we say that Choreographies
>
> >>>*always* have to be *between* web services then it precludes the
> >>>choreography being used by something that is not a web service, which
>
> >>>I don't think we want to do.
> >>>
> >>>My $0.02c.
> >>>
> >>>David
> >>>
> >>>
> >>>
> >
> >
> >--
> >"Those who can, do; those who can't, make screenshots"
> >
> >----------------------------------------------------------------------
> >Assaf Arkin                                          arkin@intalio.com
> >Intalio Inc.                                           www.intalio.com
> >The Business Process Management Company                 (650) 577 4700
> >
> >
> >This message is intended only for the use of the Addressee and may
> >contain information that is PRIVILEGED and CONFIDENTIAL. If you are not
>
> >the intended recipient, dissemination of this communication is
> >prohibited. If you have received this communication in error, please
> >erase all copies of the message and its attachments and notify us
> >immediately.
> >
> >

Received on Sunday, 20 July 2003 13:54:02 UTC