Francis, I was referring to the WSDL/SOAP extension definitions of RPC-style and Document-style, which is a very specific definition. The WSDL soap:binding extension (http://www.w3.org/TR/wsdl#_soap:binding) has a required attribute of style, which can specify style="document" or style="rpc". This attribute refers to the message structure used in the input and output SOAP messages for this particular SOAP service. As I described in a previous message, the difference between "rpc" style and "document" style is simply a matter of formatting (whether or not the payload is wrapped in an element that specifies a method name), and it really has nothing to do with the synchrony or asynchrony of the business process.
What you are describing below is what's known as choreography (or sometimes orchestration)-- what set of messages do we need to exchange, in what sequence, and within what time parameters to execute a business transactions. In SOAP/WSDL terminology, we would specify this choreographed message exchange in terms of the WSDL portTypes that must be invoked in a specific sequence. See the WSCI specification (http://www.w3.org/TR/wsci) for an example of how one might do this. The complete choreography is most likely performed asynchronously, but the individual message exchanges may in fact execute synchronously. In your example, you start by sending a PO message and you expect an ACK/NAK response. This individual message exchange is synchronous. The POA response is a separate message exchange (at least from SOAP's point of view). As I described earlier, in SOAP you could send that first PO message using either rpc or document style. Document style: <env:Body> <m:purchaseOrder xmlns:m="someURI"> ... </m:purchaseOrder> </env:Body> RPC style: <env:Body> <m:placeOrder xmlns:m="someURI"> <m:purchaseOrder> ... </m:purchaseOrder> </m:placeOrder> </env:Body> The only difference between these two messages is whether or not the PO element is wrapped in a method name element. The method name gives the SOAP server a hint as to how to route the message. The method name doesn't necessarily correspond to a specific method invocation on a specific object. If you don't specify the method name in the message, you can supply a hint in the SOAPAction header (assuming that you're using HTTP transport). If you don't supply a hint, then the SOAP server has to determine the proper routing based on the URI the message was sent to or perhaps based on the message type (which may involve additional processing). Let me reiterate: although there is basically no difference between rpc and document, there is a significant difference between "encoded" versus "literal" encodingStyles, which is specified in the WSDL soap:body extension (http://www.w3.org/TR/wsdl#_soap:body). By convention, most "rpc" style messages use the SOAP Section 5 encoding style (encodingStyle="http://schemas.xmlsoap.org/soap/encoding";), and most document style messages use literal encoding style (encodingStyle="literal"). But there's no reason why you can't use literal encoding with rpc style messages. Literal makes it much easier to perform message validation or XSLT transformation. Best regards, Anne > -----Original Message----- > From: pFrancis X [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, November 26, 2002 11:02 PM > To: [EMAIL PROTECTED] > Subject: RE: Document style web services > > > Let's take a standard purchase order scenario. > > If I send a PO message as the payload, using > ebXML-TRP, I can receive tne ACK/NAK on the same > socket. A subsequent message within the time to > perform as defined by my orchestration will have the > POA payload response. I now have a request / response > taking place across a time boundary (but still within > my time to perform as defined by my BP). > > The same thing applies if I have an EDI 850 PO using > an EDIINT/AS2 transport. > > Additionally, HTTP is not the only protocol for moving > payloads, TRPs also have specified support for SMTP > such as EDIINT/AS1 or ebXML. SMTP cannot support > synchronous business processes. > > All the production business process that I've seen so > far, when using messaging, do it asynchronously. > > The one thing that I see is that our definitions of > sync/async may be different. By sync, I see it more > as defined by RPC mechanisms (ala RMI) and async as > closer to messaging (ala JMS). > > francis > > --- Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > > Document style web services are not inherently > > asynchronous. The synchronous > > nature of a Web service is determined by the message > > exchange pattern > > described in the WSDL Operation. If the service is > > defined as having an > > input and output message, then it is a > > request/response service (inherently > > synchronous). If it is defined as having only an > > input message, then it is a > > one-way message (inherently asynchronous). > > > > Anne > > > > > -----Original Message----- > > > From: Francis Ho -- Enterprise Architecture > > [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, November 26, 2002 12:07 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: Document style web services > > > > > > > > > Document style web services is inherently > > asynchronous. Most of > > > modern TRP/MS's > > > such as EDIINT and RosettaNet (RNIF) use > > document-style services. > > > It was found > > > to be more a bit more scalable and flexible in > > dealing with > > > legacy systems. > > > This is especially true as many of the legacy > > systems for order > > > processing were > > > batch oriented. > > > > > > francis > > > > > > > > ===== > -- > The best thing about standards is that > there are so many to choose from. > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com >
