SOCKET

The Bad Easy

On first meeting Web services and WSDLs, the concepts of rpc-style and document-style services are confusing. The problem stems from the fact that there are two completely different considerations that are described using the same terminology, the implementation of the Web service itself and the structure of the soap content in the WSDL document.

The important facet is the programming model that the consumer and producer use to process their soap messages, not the style of the WSDL. This is where the real distinction between rpc-style and document-style services lies. Since the fundamental aim of SOCKET is to create consumer software for Web services from a WSDL it is essential that we know all the variations that services can throw at us so that we can proceed as far as possible in the process of setting up the consumer side of the service. For very simple services, SOCKET will be able to provide a one-step turnkey process for creating a client. For more complex rpc services and document-style services, SOCKET will probably provide a handler interface wrapped around the XML message which can then be implemented for a complete construction of the functionality of the service.

If we are using the Axis (JAX-RPC) programs Java2WSDL and WSDL2Java, or their equivalents in our language of choice, then we're probably doing rpc. And, bad news, rpc is bad. It's bad for interoperability. If Java shall speak only unto Java, and C# shall speak only to C# and Python shall speak only to Python, then we'd be OK, but then what'd be the point of Web services? It's when Java tries to talk to RosieLea, or when Python wrestles with Anaconda, that the rpc difficulties emerge, essentially through the minefield of mismatched datatypes, and also in the so-called XML-OO impedance mismatch.

So what is the document style? In a document-style Web service, you simply send the soap message to the producer and say, Look, we've talked about this, and we bashed out our schema, take the message and do what you want with it. The producer does this and sends a soap document back. There you are, consumer, we talked about this and we bashed out our schema, take the reply and do what you want with it. Using this style, I suspect that SAAJ 1.2 soap elements, which implement DOM, feeding into an XSLT/XPath engine will be the most important protocol, rather than using some tool-generated language-specific API. This will become clearer in the near future. So how is this better than rpc? Well, hopefully the problem spots have been identified and can be catered for. One field might be a date. The producers can say - look, this field is a date, but - hey - we might feed it in as a null value (nillable = true in the schema) - so watch out for this. In the rpc service, the null date might feed straight into an api that hasn't got null date types - it might go in as a zero...with hilarious consequences (I take this particular example from a Ted Neward interview on The Server Side).

So rpc is bad, and document is good. Document is also good from a related angle - message-oriented middleware and the Humptyhump Humpty Bus. I might say more about this at a later date - I usually do.

The bad news is that for simple services rpc is easier - all tool based, and taken directly from the WSDL operations and messages. With a bit of luck, for simple rpc-style services you are saved the problems that necessarily exist if an XML document has to be developed to implement complex service functionality. Having said this, even simple rpc-style services will have semantic problems, albeit of a different kind, in the absence of good annotations or documentation. Please input gas pressure. Surely - in Pascals, bars, torrs, atmospheres, psi...? Missions to Mars have perished on such semantic asteroids, and so will many a badly-drawn Web service.

So, there are rpc-style and document-style Web services. Either style can be employed using rpc-style or document-style WSDL documents. The WSDL styles are normally referred to as rpc-literal and doc(ument)-literal. So, if we can have an RPC-style Web Service (RWS) and a Document-style Web Service (DWS), there are 4 immediate possibilities: rpc-literal and doc-literal RWS; and rpc-literal and doc-literal DWS (I suppose we ought to give document-wrapped literal a namecheck, too, which makes it easier for tools to handle RWS with doc-style WSDLs).

SOCKET has started orff with the bad easy stuff, a natural place to start: rpc-literal RWS.

Posted at 10:16AM Apr 12, 2006 by Brian Peter Clark in General  | 

8080 restored

mea culpa stop silly ass stop permalink problem fixed stop utf-8 not configured properly stop arriving istanbul wed stop

Posted at 12:53PM Apr 11, 2006 by Brian Peter Clark in General  | 

Broken Links - RSS Feed Exporter Omits Port Number

212 characters for message stop cetis elrond links to individual blog items broken stop rss exporter omits port 8080 in permalinks stop access to blog via web site stop those puzzling at style ? the first 212 characters are visible in the aggregator stopp

Posted at 04:29PM Apr 08, 2006 by Brian Peter Clark in General  | 

WSDL2Java

Some brief notes from Atif on using the WSDL2Java program.

You'll find the Axis WSDL-to-Java tool in "org.apache.axis.wsdl.WSDL2Java". The basic invocation form looks like this:

$> java -cp %AXISCLASSPATH% org.apache.axis.wsdl.WSDL2Java (WSDL-file-URL)

For example lets say we have a web service running at the following address:
http://localhost:8080/samples/services/Version
THEN we would invoke Axis WSDL-to-Java tool like THIS:
$> java -cp %AXISCLASSPATH% org.apache.axis.wsdl.WSDL2Java http://localhost:8080/samples/services/Version?wsdl

This will create java classes in the current directory.

LETS say we want the ouput of Axis WSDL-to-Java tool to go into certain directory THEN you need to use the -o option.
e.g. $> java -cp %AXISCLASSPATH% org.apache.axis.wsdl.WSDL2Java http://localhost:8080/samples/services/Version?wsdl -oC:\test

By default WSDL-to-Java tool will put the ouput classess into packages WHICH mirror the targetNamespace in the web service WSDL.
To change this default YOU need to use the following option: -p
e.g. $> java -cp %AXISCLASSPATH% org.apache.axis.wsdl.WSDL2Java http://localhost:8080/samples/services/Version?wsdl -pws.version

Posted at 04:26PM Apr 06, 2006 by Brian Peter Clark in Misc technical  | 

Installing Axis client

Some brief notes from Atif on installing Axis client.

The following software was used when installing Axis client.
* Java SE 1.5
* Axis 1.3

1. unzip axis-bin-1_3.tar to directory C:\DevTool\axis-1_3

2. Set variable AXIS_HOME to C:\DevTool\axis-1_3

3. Add an XML parser, acquire the JAXP 1.1 XML compliant parser (i.e. xalan) to $AXIS_HOME\lib

4. set variable AXIS_LIB to %AXIS_HOME%\lib

5. set variable AXISCLASSPATH to:

%AXIS_LIB%\axis.jar;%AXIS_LIB%\commons-discovery-0.2.jar;
%AXIS_LIB%\commons-logging-1.0.4.jar;%AXIS_LIB%\jaxrpc.jar;%AXIS_LIB%\saaj.jar;
%AXIS_LIB%\log4j-1.2.8.jar;%AXIS_LIB%\xalan.jar;%AXIS_LIB%\wsdl4j-1.5.1.jar;
%AXIS_LIB%\axis-schema.jar

To use Axis client code on the command line, you can select AXISCLASSPATH when invoking Java by entering

java -cp %AXISCLASSPATH% ...

or

java -cp "$AXISCLASSPATH" ...

depending on the platform. You may omit the quotes if your CLASSPATH doesn't have spaces in it.

Posted at 04:24PM Apr 06, 2006 by Brian Peter Clark in Misc technical  | 

Operations - double trouble

Building Web Services with Java, Making sense of XML, SOAP, WSDL, and UDDI, (2nd Edition, 2005)by Steve Graham et many als, Sams Publishing.

This is a terrific book - well written with plenty of xml examples.

One little highlighted note in the WSDL chapter goes like this:

Note: When you're designing WSDL portTypes, you should be careful with the names of the portType's operations: They should all be different.

Perhaps they should, but need they be? Atif and I had recently been discussing this matter from the Java to WSDL point of view. The key to the affair is method overloading - two methods with the same name but differentiated by having different signatures. Since portType operations are the equivalent of method names, this would suggest that to accommodate method overloading one might suspect that operations names would not be required to be unique. Out came the WSDL 1.1 specs. Indeed, no stipulations are made about uniqueness of operation names in a WSDL document. Just to make sure, we ran a little test. A Java class with 2 methods with the same name - getTest() - but with different signatures were submitted to the Axis Java2WSDL utility. The relevant part of the resultant WSDL is given below.

<wsdl:portType name="Test">

<wsdl:operation name="getTest" parameterOrder="value">

<wsdl:input message="impl:getTestRequest"name="getTestRequest"/>

<wsdl:output message="impl:getTestResponse"name="getTestResponse" />

</wsdl:operation>

<wsdl:operation name="getTest" parameterOrder="value">

<wsdl:input message="impl:getTestRequest1" name="getTestRequest1" />

<wsdl:output message="impl:getTestResponse1" name="getTestResponse1" />

</wsdl:operation>

</wsdl:portType>

Sure enough, two operations with the same name. The message names, on the other hand, must be unique (as per the specs). These represent the method signatures. You wouldn't want two operations with the same names and the same messages. Again, clever little Axis has differentiated the messages eg getTestRequest and getTestRequest1.

As Atif would say: Job's a good'un.

Posted at 04:09PM Apr 06, 2006 by Brian Peter Clark in Web services  | 

SOCKET

This is the technical blog for SOCKET, a JISC ELF toolkit project.

The aim of the project is to assemble a toolkit that, given a WSDL file, will automatically generate consumer software for a Web service together with an interface that makes it available as a resource in a virtual learning environment.

Project Web site: http://www.agbooth.com/SOCKETBlog/www.socketelf.org_8080/eldg/socket/home.jsp

Project dates: 1 February 2006 - 31 July 2006.

Members of the project team belong to the e-Learning Development Group in the Faculty of Biological Sciences at the University of Leeds.

Professor Andrew G. Booth, Project Director

Dr Brian P. Clark, Project Manager

Atif Suleman, Principal Developer

Rob J. Garbutt, Developer

We are pleased to have the following consultants for the project.

Alistair Young (Guanxi Consultant) from the UHI Millennium Institute at Sabhal Mòr Ostaig, Isle of Skye. Alistair wrote the alternative implementation of the Shibboleth profile used in the Guanxi Identity Provider and Service Provider.

John Kleeman (Questionmark Consultant) is the Chairman of Questionmark Computing Limited, the vendors of Questionmark Perception.

Posted at 02:55PM Apr 06, 2006 by Brian Peter Clark in General  |