[Soaplab-users] Soaplab 2

[Martin S. <se...@eb...>]

Hi,
   For some time, there have been talks about making a new generation of
Soaplab. Now, the time seems to be good for that. (Do not worry, the
current Soaplab will be still supported.)
   The new code will be in a separate CVS module (soaplab2). I have
created a new mailing list (soaplab-two-dev) for developing the new
soaplab. Please consider to subscribe to it here:
   http://lists.sourceforge.net/lists/listinfo/soaplab-two-dev

   Below are the main goals and plans for Soaplab2 (sorry for posting it
here - this will be hopefully the last post into this list about the
Soaplab2):

   With regards,
   Martin

The main goals of Soaplab2:
---------------------------

* Clearer architecture:

  - Core (representing by the full Soaplab API). Implement also parts
that were not implemented so far: iterator pattern (streaming) for
input/output, server-push notification.

  - Plug-ins defining individual "analysis providers"; major "analysis
providers" are command-line tools (what is done by AppLab in the
current Soaplab), web resource (current Gowlab), access to non-Soaplab
web services (e.g. interproscan at EBI). Another candidate is a plug-in
for accessing an underlying grid.

  - Plug-ins defining access protocols (how to call Soaplab from
clients). At the moment, the only protocol is SOAP/HTML, but at least
REST should be added.

* Remove internal dependencies on CORBA (AppLab part).

* Make it pure Java:

  - The Perl launcher (which is now between Soaplab and command-line
tools) should be replaced (possibly still keeping his "scripting"
character by using e.g. Java beanshell).

  - Replace the Perl ACD2XML converter by a Java convertor.

* "Soaplab Dashboard" 

  - A user interface (presumably web-based) allowing to create and
deploy new Soaplab services on-the-fly, including an ACD (or directly
XML) editor for Soaplab metadata.

  - It will need to create and implement a separate "Soaplab Admin
API".

* Better support for Soaplab WSDL (and better WSDL in the first place,
at least for the derived services). Based on work of Peter Ernst from
the German Cancer Research Center.

* Re-write: clean the code, fix old bugs, make it more maintainable.


-- 
Martin Senger
   email: mar...@gm...
   skype: martinsenger