On 15/12/06, Paul Downey <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
>
>  On 15 Dec 2006, at 13:20, Steve Jones wrote:
>  > http://www.w3.org/TR/2003/WD-wsdl20-patterns-20031110/#asynch-out-in
>  >
>  > Basically you can now specify an async message exchange in the WSDL.
>
>  Nope. That was renamed to Out-Optional-In, hasn't been implemented
>  by anyone, and is a "feature at risk":
>  """
>
>  Definition of the Robust In-Only, In-Optional-Out, Out-Only, Robust
>  Out-Only, Out-In, Out-Optional-In message exchange pattern (in
>  section 2.3 Message Exchange Patterns): the Working Group is
>  intending to remove those definitions from the specification if it
>  does not have evidence of their use
>
>  """
>
>  (Status section:)
>
>  http://www.w3.org/TR/2006/CR-wsdl20-adjuncts-20060327/
>
>  Maybe you could cite an interoperable method of describing a service
>  which sometimes sends a response as 200, and sometimes sends 202 and
>  later calls back using WS-Addressing. Or how to interoperably
>  describe MQSeries (or JMS) in WSDL 1.1 or 2.0, or how to describe a
>  MEP which the request is HTTP and the response is Email?

Bloody hell this is worse than I thought, you know when you read
something and link two bits together?  You are spot on but....

https://jax-ws.dev.java.net/jax-ws-20-fcs/docs/asynch.html
http://www.netbeans.org/kb/55/websvc-jax-ws-asynch.html
https://jax-ws.dev.java.net/jax-ws-21-ea1/docs/asynch.html

I'd stupidly thought that they were using the WSDL 2.0 approach, my
bad.  This really is horrific, I'd thought it was bad enough when it
was a WSDL 2.0 (my bad) approach, now its a Java specific extension...
uuurrrgggghhhh.

Or am I being thick again?

>
>  > > When do you think WSDL 2.0 is going to have an impact on developers?
>  >
>  > Given that JAX-WS is in JavaSE 6 and JavaEE 5 and supports WSDL 2.0
>  > then I'd say pretty much now.
>
>  Nope. WSDL 2.0 is still in CR, Canon and Axis2 have implementations
>  with variants in Woden and from WSO2:
>
>  http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/
>  Dashboard.html
>
>  AFAIK Sun doesn't have a WSDL 2.0 implementation, and if one were to
>  be shipped in JavaEE 5, it would be out of date by the time WSDL 2.0
>  becomes a W3C Recommendation.

Nope spot on, but they do have async and callbacks.  I'd just been
sloppy in my research.
Apologies.


>
>  > > [snip]
>  > > Let's take this email thread: in a year's time I might cite you
>  > again and either copy
>  > > the text and send it inside another ephemeral message (WS-*)
>  > > or point you at the stable URI for the archive (REST).
>  >
>  > The later IS NOT REST as used for computer->computer communications.
>  > You are talking about how to serve a web page up into a browser. I've
>  > done that, done it lots of times, and never ONCE in all that time did
>  > I build the system using "REST" principles.
>
>  You didn't need to build anything to have a RESTful  interaction, how
>  powerful is that ;-)

Not very?  Claiming that something is REST when it patently isn't
doesn't advance the case.

>
>  The analogy is between messaging and resource orientation. With
>  transport independent messaging you're doomed to cut and paste. With
>  resources you're much more able to refer to stuff.

Eh?  Why?

>
>  Here's another analogy - our local cinema used to put up a screen
>  when you clicked "BUY TICKETS" saying it could
>  take a couple of minutes for the order to go through and not to press
>  refresh. Of course sometimes it timed out
>  and through and I often had to ring them/ my credit card company up
>  to kill the possible duplicate transaction.
>
>  The recently changed it to return immediately with a page linking the
>  order status, which I could refresh and see the status of my order. I
>  can go back to it, possibly even now.
>
>  That's rock-solid reliability all without waiting for WS-RX to bake.

So the REST "reliable" solution is polling?  Does this guarentee that
the original message arrived as sent (no it doesn't).  Does polling
increase the demand on the server? Yes it does.  Does polling require
you to put the logic into the client and have the client in charge of
the overall interaction?  Yes it does.

I'm not even sure that REST is that.


>
>  > I'd say its more medium than exceptionally poor these days, doing
>  > RMI/COM bridging was poor and the first CORBA interop attemps were
>  > exceptionally poor. I built my first commerciall Java/MS web facing
>  > WS implementation in 2001, it wasn't too bad and the ones these days
>  > are better.
>
>  Crumbs, that's so not my experience. But it's possible I've had to
>  deal with more complex schemas, teetering up the stack specs and
>  variety of customers than you. It seems "best viewed in Java
>  and .NET" is good enough for many SOAPsters.

I don't know, I find the OTA schemas relatively complex and some of
the goverment ones are a bit of a pain (to say the least).

>
>  --
>  http://blog.whatfettle.com
>
>                    

Reply via email to