Re: data transport
Arne VajhQj wrote:
RedGrittyBrick wrote:
Arne VajhQj wrote:
Web services has somehow gotten the reputation of being complex
in the Java world.
Not very justified in my opinion.
My irritation with Web-services in Java is from implementing JSE
clients not JEE servers. For this the developer toolset seems much
more complex.
Is it ?
You give your IDE the URL of the WSDL, it generates a stub class
and you call that.
JBuilder, Eclipse, Visual Studio etc..
* There isn't a set of web-service classes for clients included in JSE
1.6 (AFAIK).
I thought WS client support was in 1.6 as well.
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.
* Hence you have to evaluate and select a toolkit to use. I found this
non trivial. Axis, XFire/CXF, ...
We like Java because we have choices.
We hate Java because we have choices.
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.
* As soon as you want to use something like WS-Security with PKCS12
files, I find things get more complex for the developer. WSS4J, ...
True.
But I do not consider it surprisingly that doing complex stuff becomes
complex.
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.
Part of the problem with CSV (say) is having both ends agree on the
implicit meaning of the columns. The tagnames in XML should overcome
that issue but in practice they do not. Inserting a new column in CSV
requires that both ends definition be updated. Inserting a new element
in XML also, in practice, seems to require that both ends are given an
updated XSD, WSDL or other definition and rebuilt. XML ought to be
more self explanatory than CSV (or JSON) but in practice it is equally
useless without an external definition in XSD or some other form.
For CSV you need to modify the code.
For XML you just need to rebuild (whicg regenerates the stub).
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 :-)