Re: Web Services integration [was: Cocoon Form binding and validation ]

[Ivelin Ivanov <iv...@iname.com>]

This message targets primarily Cocoon, but I sincerely hope that there are
Axis developers
out there who will find it enticing.

Since the majority of the work on the Cocoon form handling problem is
complete,
while waiting on all stakeholders to come to an agreement for a common API,
I've decided to look one step ahead into Cocoon's future and start a
parallel discussion.

Many of us agree how critical for Cocoon's successful future is its
integration with Web
Services .



These are the topics I'll cover:
====================================
I. Can we learn from .NET Web Services

II. (Cocoon + Axis) = the DOT in .net

III. 3 Saturdays should do.
====================================




                                         -o-


I. Can we learn from .NET Web Services
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I am not particularly thrilled to have found what I am about to share,
but it is in Apache's best interest to adopt good ideas, invariant of their
origin.

While seeking for answer to the integration problem, I've got inspiration
from .NET's ability to autogenerate web service consumers (specificly HTML),
so that they can
be easily tested with a browser through simple GET and POST of HTML forms.
I will use as a reference a publicly available web site implemented with
.NET.
http://www.soapengine.com/lucin/salcentral/cidea.asmx?op=GetTopIdeas
Further in this message I will refer to the content of this site.

As you're aware, there are different protocols that the web clients can
employ to communicate with Web Services: HTTP GET, HTTP POST, and SOAP.
For WS starters, I recommend this article:
http://www.oreillynet.com/pub/a/dotnet/excerpt/netessentials2_6/index3.html

Let's look at the message format of a POST and a SOAP call for a
service published on the site in question. The service name is GetTopIdeas.


POST:
======

REQUEST:
---------------

POST /lucin/salcentral/cidea.asmx/GetTopIdeas HTTP/1.1
Host: www.soapengine.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length

UserID=string&Password=string&HTMLFormat=string


------
The request is no different than any other browser initiated
POST request.


RESPONSE:
----------------
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<DataSet xmlns="http://www.soapengine.com/lucin/salcentral/cidea.asmx">
  <schema
xmlns="http://www.w3.org/2001/XMLSchema">schema</schema>xml</DataSet>


------
The response however is in XML format !
We'll get back to this later.



SOAP:
======

REQUEST:
--------------
POST /lucin/salcentral/cidea.asmx HTTP/1.1
Host: www.soapengine.com
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction:
"http://www.soapengine.com/lucin/salcentral/cidea.asmx/GetTopIdeas"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <TopIdeas
xmlns="http://www.soapengine.com/lucin/salcentral/cidea.asmx">
      <UserID>long</UserID>
      <Password>string</Password>
      <HTMLFormat>boolean</HTMLFormat>
    </TopIdeas>
  </soap:Body>
</soap:Envelope>

-----
Quite standard SOAP request


RESPONSE:
---------------

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetTopIdeasResponse
xmlns="http://www.soapengine.com/lucin/salcentral/cidea.asmx">
      <GetTopIdeasResult>
        <xsd:schema>schema</xsd:schema>xml</GetTopIdeasResult>
    </GetTopIdeasResponse>
  </soap:Body>
</soap:Envelope>

------
A typical SOAP response.

What is interesting though about this reponse is that its body content is
exactly the same as the body content of the POST response (and the GET
response). This is nice. The application handling the reponse should be
happy.
It can be easily morphed into HTML, invariant of the request format.


The natural questions that follows is:
Could all three types of requests GET, POST, SOAP to GetTopIdeas be handled
by the same method ?

Well, .NET's answer is no. For each different binding there needs to be a
custom .NET method.
The one handling SOAP will look like
GetTopIdeas ( TopIdeas )
, the GET and POST will be handled by
GetTopIdeas( UserId, Password, HTMLFormat )
. In the SOAP case binding XML to TopIdeas object is automatic, in the POST
case however, the method handles binding by itself and then probably calls
in the SOAP version. That's annoying.

I believe we have a better answer for Cocoon/Axis though.




                                         -o-




II. (Cocoon + Axis) = the DOT in .net
~~~~~~~~~~~~~~~~~~~~~~~~~~


I'll start with Cocoon because it's role is obvious. It can handle those XML
responses with charm. Massage them and deliver to a plethora of client
applications.

Maybe some of these clients will know how to talk SOAP. Most of them though,
for the foreseable future, will only know how to submit a parameterized GET
or a form POST.

Axis moves quickly with its SOAP support. It has a sophisticated toolkit for
binding XML to complex JavaBeans .
However Axis developers seem to ignore binding for GET and POST requests.
Searching through Axis' samples in the CVS repository, I couldn't find a
POST service example which handles a multi-parameter request. Is there one ?
All the composite requests are SOAP based.

*Separating* POST and SOAP requests results in a huge gap between the
traditional Web UI and the Web Services realm.

Ok, I think this can change. And maybe easy.

Provided a WSDL description for the SOAP request body, Axis should be able
to generate ones for GET and POST, by enlisting all elements that would
appear in a XML request as (name, value) pairs, where name is the XPath
location of the XML element.

    <TopIdeas>
      <UserID>long</UserID>
      <Password>string</Password>
      <HTMLFormat>boolean</HTMLFormat>
    </TopIdeas>

Would become

part name=userID
part name=Password
part name=HTMLFormat

I guess by now you know what I am trying to get at.
Automated binding of HTTP GET & POST to JavaBeans through XPath is a solved
problem.

Why not leverage ?

http://prdownloads.sourceforge.net/freebuilder/CocoonForm_0-7-1.zip


Most applications use the default type mapping in Axis. It is based on
introspection, much like Castor and JAXB.
Mapping GET/POST requests is easy. The Axis servlet could  just call

FormBeanBinder.bind( request, javaBean)

before calling into the application method providing the service.
The javaBean would be created before the binding if it is request scoped or
used for the first time. Otherwise if the javaBean is available in the
session, it just needs to be obtained from it, before passed to bind().
This scenario isn't much different, from the one for a SOAP request.

In the rare case when custom type mapping is required, the request
parameters can be converted into a DOM document before handed to the
Deserializer.

????????????????????????????
* What is the point of all this? *
????????????????????????????

1) Application developers will have to write only one service method
satisfying both Web Services and Web UI needs.

2) The service method takes and returns JavaBeans, which enforces a very
clean cut between business logic and web interfaces: WS, HTML, WML, etc.

3) Web Services can be nicely plugged-in the Cocoon sitemap as either:
    a) WebServicesTransformer, which acts on the SAX stream flow and
modifies it.
        It'll take a src parameter pointing to the URL of the service.
    b) WebServicesGenerator (in addition to the existing one based on XSP),
which forwards the request to an Axis service, through its src attribute,
waits for the response and generates the initial SAX stream.

    Both of these components can be hooked to Axis behind the scenes.

Last but surely not least:

4) It'll be possible to autogenerate test pages for new web services.
    a) Test pages which can be manually tested are of help for lowering the
development cycle.
    b) In many cases, these test pages will turn into real UI pages. After
all, a lot of web services end up exposed in some sort of UI, or for that
matter many originate from pre-existing UIs.

So the goal is that developers can focus on the business logic of their
service implementation,
without sweating how to hook them with the sitemap and the presentation
layer.


                                         -o-



III. 3 Saturdays are enough to make this happen.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Most parts are available and wait to be put together.

If Cocoon and Axis communities decide to cooperate on this task, then I
believe 3 Saturdays are sufficient to make reality most of what was
mentioned here.

I can provide a prototype of HTTP GET/POST Deserializer for Axis.
Web Services Generator shouldn't be hard to do once Axis supports GET/POST
binding.
Web Services Transformer can be implemented immediately.


Thank you for reaching this line.


Pozdravi,

Ivelin











---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org