implementation details... The SOAP and WSDL specs say that rpc/literal is valid. They also says that document/encoded is valid, although I've never seen anyone do so. The JAX-RPC spec says that rpc/literal must be supported, which I'm sure is why Axis supports it. It doesn't mention document/encoded.
The current draft of the WS-I Basic Profile includes rpc/literal. It disallows rpc/encoded. Anne > -----Original Message----- > From: Sasha Lerner [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 27, 2002 1:45 PM > To: [EMAIL PROTECTED] > Subject: Re: Document style web services > > > > On Wednesday, November 27, 2002, at 07:57 AM, Anne Thomas Manes wrote: > > > 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. > > Except neither BEA Workshop nor .Net wsdl tools allow you too use > "literal" with rpc style messages. > And those are the pushers of WS-I. Ironic then that Axis supports that > pairing. > and I was not very sucessfull deserializing array structure thats not > declared as "ArrayType" with those tools. > they clearly prefer soapencoded arrays when style is "rpc" > > > > > > 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 > >> > > >
