WSGUI: Dynamic WSDL integration

[Josef Spillner <js...@inf.tu-dresden.de>]

Hello,

during the last few weeks I've looked into ways of accessing a web service 
(via its WSDL) for dynamic creation of GUI elements for both input, output 
and navigation.
My goal is to bring this functionality to the world of portals and to the 
desktop.

An example (web):
By accessing the Google Search API WSDL, the portlet guides me to the offered 
operations (doSearch, doTranslate), and after selecting one of these a HTML 
form is offered. After filling out the form, a SOAP call sends the data to 
google, and writes back the results to the portlet.

Another example (desktop):
Groupware servers offer WSDL APIs which might change over time. In order to 
not having to recompile the access to them from let's say a mail or 
calendaring application, the dynamic WSDL integration would take the changes 
into account and present a slightly modified dialog to the user.

So far so good - I've got working examples for both areas, but there are many 
open questions.

1. Which markup to use?
It is not a secret that WSDL are absolutely unsuitable for direct 
visualisation. With variable names like foo1 or order_id, they scare away 
more users than they would like. There was the WSUI effort to address this, 
however this turned into WSCM, then WSIA, then ... faded away.
Another (research) work was WSGUI, which has advanced quite a bit but is also 
far from perfect. My work builds upon WSGUI, by extending it where necessary 
and cutting out the parts which are not needed right now (but might prove 
useful in a later stage).

2. How to address complex navigation and conversation?
Usually, web services consist of single shots (request and result), but some 
require sequential, partially conditional execution. There's WSCL, but this 
is deemed unsufficient by some, and I also haven't seen it used widely in the 
wild. From a portlet writer POV, it is not ideal that the whole webpage 
reloads after each step. But I guess this is a minor issue for now.

3. Jetspeed integration.
I've recently converted my work to JSR-168, so it will work with any portal, 
including Fusion. It would however be nice to have it included in Jetspeed in 
the future, as this is what I use for work. (Ideally, with a working WSRP and 
a not-dead-yet portlet-opensrc.sf.net, this would be less of an issue, but 
well.)
The main question here would not be about licencing or CVS/SVN access, but 
about defining standards. As mentioned above, WSUI-like standards have been 
defined by well-known organisations and companies, however:
* no OSS implementation is available (correct me if I'm wrong!)
* they're not usable for desktop integration
* even the web integration is somewhat clumsy, with some including whole HTML 
chunks and not considering i18n by means of browser language

My personal feeling is that one should simply step forward with a small, 
suitable standard and implementation. If anybody is interested in 
collaboration, please speak up. I hope to finalise the portlet soon, and 
would like to gather ideas and suggestions.

Josef

-- 
Tous ces gens qui confondent informatique et bureautique, carte et territoire,
interface et programme, boutons colorés et facilité...
- S. Blondeel

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org