I think IBM and MS actually did provide independent implementation
of many of the WS-*.

What do you think the 1950's assembler programmers would say
about todays Java programs ?

That they are way to complex and that the compiler & language
hiding the complexity is a bad thing ?

Whenever we invent a better tool, then someone else will invent
a more complex problem to apply it to.

Arne

I agree wholeheartedly - it's why we have jobs, after all - but OTOH it's hard
not to sympathize with the urge to leaner, more elegant code and protocols.

XML has its own elegance, considering for example that as a protocol it's
utterly semantically void, and certainly its costs.  Not every XML dialect
(what old-time SGMLers style "XML languages" and I (very) loosely call
"schemas") is equally well designed.  Unquestionably XML carries more bits per
message than most custom, certainly most binary protocols.

The hybrid approach mentioned upthread is very promising.  This posits a lean
protocol "inside" where one controlls the software, and XML (SOAP) as the
/lingua franca/ for "outside" communication.

It seems smart to balance the protocols like that, considering the overhead of
managing two approaches.  If an organization discovers later that the XML
approach buys advantages that even benefit the intranet, they could switch
over without too much trouble if they've designed their architecture right.

I argue the XML side not because it's always correct but to point up why it
serves a purpose.  As Arne points out, service-to-service communication and
other models of inter-system interaction have a complex world to handle in the
first place.

The good news is that most web-service toolkits do make it easier to put
together straightforward web-service applications.  At least IMHO.  Up to a
point.  I'm still working on figuring out the complex parts.

The real test of a toolkit is Hippocratic and utilitarian:
- Does it make my job harder?
  More accurately: In what ways does it make my job harder?
- (In what ways) does it make my job easier?

I didn't realise this (Doh!) Thanks for spurring me to go and have a
look. I downloaded JDK 6 Update 3.

Googling found
http://weblogs.java.net/blog/vivekp/archive/2006/12/webservices_in.html
which didn't work (the apt tool must have changed and is no longer needed)

Googling also found
http://java.sun.com/developer/technicalArticles/J2SE/jax_ws_2/
Which is netbeans oriented (I use Eclipse) but, in combination with
Vivek's article I managed to get a simple example working (see later).

So yes, JDK 6 has usable web-services capability built in at last!
From my very brief play with it, it seems comparable to that supplied
with Mono (C#). This is good as far as I am concerned.

What irritated me was actually that (until 6) there wasn't a *default*
WS toolkit included in the JDK. Choices are good, but we newbies like to
have a default toolkit we can immediately get started with, without
having to choose, download and install extras.

The WS edifice has become a bit like ISO OSI - there are many different
ways to achieve any task. The Java WS API has to be flexible enough to
cope with this. This leads to complexity that could otherwise have been
avoided.

For example:
  RPC/Encoded, Doc/Literal, Doc/Literal/Wrapped?
  Inclusive canonicalisation or exclusive?
  Standalone, Enveloping or Enveloped signatures?
  RSA or DSA?
  SHA1 or MD5?

Actually the whole canonicalisation step seems unecessary for most Web
Services - few apps forward the XML payload, transform the structure,
reorder the attributes arbitrarily, rename the namespaces and still need
to verify the signature at the end of that process. IIRC
canonicalization leaves whitespace unchanged, and that (at least line
endings) is the part I'd expect to be most likely to be affected by the
transport.

I sometimes wonder if a 'csvgen' tool to create CSVDL and a
corresponding 'csvdlimport' stubmaker would illustrate the pointlessness
of some of the complexity in SOAP/XML/HTTPS based web-services.

P.S. For anyone new to WS in Java 6, here's my slightly modified source
from the above references. Built & run using command line as shown in
comments.

------------------------- 8< ---------------------
package hello;

import javax.jws.WebService;
import javax.xml.ws.Endpoint;

/*
 * From http://java.sun.com/developer/technicalArticles/J2SE/jax_ws_2/
 *
 * > javac hello/CircleFunctions.java
 * > wsgen -cp . hello.CircleFunctions
 * > java hello/CircleFunctions
 *
 */

@WebService
public class CircleFunctions {
    public double getArea(double r) {
       return java.lang.Math.PI * (r * r);
    }
    public double getCircumference(double r) {
        return 2 * java.lang.Math.PI * r;
    }
    public static void main(String[] args) {
        Endpoint.publish("http://localhost:8080/"
            + "WebServiceExample/circlefunctions",
        new CircleFunctions());
    }
}
------------------------- 8< ---------------------
package client;
/*
 *
 * From http://java.sun.com/developer/technicalArticles/J2SE/jax_ws_2/
 *
 * Slightly adapted by RedGrittyBrick
 *
 * > wsimport -p client -keep \
 *     http://localhost:8080/WebServiceExample/circlefunctions?WSDL
 * > javac -cp . client/CircleClient.java
 * > java client/CircleClient
 * Result = 28.274333882308138
 * Done
 *
 */

class CircleClient {
    public static void main(String[] args) {
        try {
            double radius = 3.0;
            CircleFunctionsService service =
                    new CircleFunctionsService();
            CircleFunctions port = service.getCircleFunctionsPort();
            double result = port.getArea(radius);
            System.out.println("Result = "+result);
        } catch (Exception ex) {
            System.out.println("Exception ");
        }
        System.out.println("Done");
    }
}
------------------------- 8< ---------------------

I'm pretty sure that in C# you don't have this obscure "port" step. The
equivalent C# code is usually like this ...
    CircleFunctionsService service =
                    new CircleFunctionsService();
    double result = service.getArea(radius);
Java likes to be that bit more complicated :-)

P.P.S. Don't take this rant too seriously :-)