soaplab-two-dev — New Generation of Soaplab

[Soaplab2-dev] Re: Soaplab-two-dev digest, Vol 1 #3 - 1 msg

[Jon I. <ji...@eb...>]

Hi Mahmut

That sounds good to me, very ambitious though !

I've a few (probably naive) questions -

What shape would the "Java implementation of the service" take, is this essentially a
piece of Java code that wraps (calls) a given service ?

What (in basic terms) is the "Soaplab build.xml file" ?

Would EMBOSS (for example) be a "service group" ?

What is the "service container" in the deplyoment component ?

If an administrator deployed an archive file by copying the archive file to the Axis2
services repository, or by using the Axis2 administration tools, would these services
later be visible to the "service explorer" component ?



It's more obvious to me now how the dashboard and acdtools / JACD fit together. The
Service Editor and JACD-GUI have common ground, but I face an easier proposition
because JACD-GUI only need support what can be defined in an ACD file / by the XML-ACD
schema, whereas the service editor needs (presumably) to handle stuff outside that
scope / in an extended schema.

Both might need to handle dependencies between options of the type, "The value of option X
depends on the the value of option Y" - not easy, perhaps we could help each other with that
part?

Last thought is that it might be sensible if the XML schema used by SOAPLAB (or indeed
any interface to EMBOSS) was managed as an extension to the (more basic) ACD-XML schema.

Cheers

Jon


> Send Soaplab-two-dev mailing list submissions to
> 	soa...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/soaplab-two-dev
> or, via email, send a message with subject or body 'help' to
> 	soa...@li...
>
> You can reach the person managing the list at
> 	soa...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Soaplab-two-dev digest..."
>
>
> Today's Topics:
>
>    1. description for the dashboard (Mahmut Uludag)
>
> --__--__--
>
> Message: 1
> From: Mahmut Uludag <ul...@eb...>
> To: soa...@li...
> Cc: Jon Ison <ji...@eb...>, aj...@eb..., pm...@eb...,
>    shaun <sh...@eb...>
> Date: Thu, 25 May 2006 15:51:33 +0100
> Subject: [Soaplab2-dev] description for the dashboard
>
> Hi,
>
> I have prepared the following description for the Soaplab dashboard
> based on the discussions in a meeting we had last week with Martin and
> Alan.
>
> Based on an email communication with Martin, I assumed that Soaplab2
> will be using the latest version of Axis (Axis2).
>
> Please send your comments.
>
> Regards,
> Mahmut
>
>
> -- Soaplab Dashboard --
> Soaplab dashboard will be a web based administration tool for the next
> release of Soaplab (Soaplab2). It will provide web interfaces to create
> and deploy new Soaplab services, as well as interfaces to explore and
> use existing services.
>
> The dashboard will be developed using the JSP and Java Servlet
> technologies and by following the MVC design pattern. (It would be
> possible to use an MVC framework such as Spring MVC framework to make
> the implementation more maintainable and easily extensible. However, the
> dashboard will probably be a small web application with 5-10 different
> pages, and experts of the field do not suggest the use of such
> frameworks for small applications.) We will use JSPs to generate the
> presentation layer and servlets as the controllers that will be in
> charge of the request processing and the creation of any beans or
> objects used by the JSPs, as well as deciding which JSP page to forward
> the request to.
>
>
> The dashboard will include the following basic components.
>
>       * Service editor, for defining new services (possibly for
>         modifying existing services as well) and for preparing
>         deployable service archive files for Axis2.
>
>       * Deployment component, for hot-deployment of Soaplab service
>         archive files.
>
>       * Service explorer, for exploring services on a given Soaplab
>         server.
>
> -- Service Editor
> This component will present users an HTML form that can be used to
> provide the definition of a new service. When the form is submitted, the
> dashboard Servlet will generate the files required by Axis2 and will
> then pack them in a Web Service archive. The archive basically includes
> the Services.xml file and the Java implementation of the service. For
> this purpose we plan to use Ant API to call tasks defined in the Soaplab
> build.xml file which will eventually use Soaplab2, acdtools (new
> development) and Axis2 libraries. It will also be possible to append,
> replace and delete services in an existing Web Service archive file.
>
>
> The information to be provided using the form will basically include the
> following.
>
>       * Name of the service
>
>       * Service group
>
>       * Description of inputs and outputs (the form should be dynamic
>         such that any number of inputs/outputs should be definable)
>
>       * Name of the executable if the service is a Applab service
>
>       * URL if the service is a Gowlab service
>
>       * Locations of scripts (BeanShell, Perl) or class files that
>         implements the service or XSL files used by the service.
>
>       * Other information
>
>
>
> -- Deployment component
> An issue regarding the deployment of current Soaplab services, it
> requires restarting the service container because of the deployment
> model used by Axis 1.x. However, Axis2 detects the presence of the Web
> Service archives in the repository directory and loads the archive
> automatically. This 'hot deployment' feature can potentially improve
> usability of the deployment component as the Soaplab administrator will
> not need to restart the server after deploying a Web Service archive
> file. If a Web Service archive file is to be deployed to the same server
> where dashboard is running then the deployment component should be able
> to deploy the Web Service Archive. Otherwise administrators can deploy a
> Web Service archive file by simply copying the archive file to their
> Axis2 services repository or they can use the Axis2 web administration
> tool.
>
> One issue regarding the Soaplab service archive files; it would be wise
> to have the Soaplab library and other libraries used by Soaplab, in the
> shared libraries directory of the Axis2 repository rather than in the
> service archive file.
>
>
> -- Service explorer
> This component will basically be used for exploring and calling Soaplab
> services. Given a Soaplab endpoint, users should be able to see the list
> of available services and their descriptions. After selecting a service,
> this component should allow users to enter service input data and start
> a service call, wait for a result, and display results. When logged in
> using an administrator account, administrators should be able to see an
> overview of the Soaplab server, such as the number of active users, and
> the status of Soaplab service calls, etc.
>
>
>
>
>
> --__--__--
>
> _______________________________________________
> Soaplab-two-dev mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplab-two-dev
>
>
> End of Soaplab-two-dev Digest
>

[Soaplab2-dev] description for the dashboard

[Mahmut U. <ul...@eb...>]

Hi,

I have prepared the following description for the Soaplab dashboard
based on the discussions in a meeting we had last week with Martin and
Alan.

Based on an email communication with Martin, I assumed that Soaplab2
will be using the latest version of Axis (Axis2).

Please send your comments.

Regards,
Mahmut


-- Soaplab Dashboard --
Soaplab dashboard will be a web based administration tool for the next
release of Soaplab (Soaplab2). It will provide web interfaces to create
and deploy new Soaplab services, as well as interfaces to explore and
use existing services.

The dashboard will be developed using the JSP and Java Servlet
technologies and by following the MVC design pattern. (It would be
possible to use an MVC framework such as Spring MVC framework to make
the implementation more maintainable and easily extensible. However, the
dashboard will probably be a small web application with 5-10 different
pages, and experts of the field do not suggest the use of such
frameworks for small applications.) We will use JSPs to generate the
presentation layer and servlets as the controllers that will be in
charge of the request processing and the creation of any beans or
objects used by the JSPs, as well as deciding which JSP page to forward
the request to.


The dashboard will include the following basic components.

      * Service editor, for defining new services (possibly for
        modifying existing services as well) and for preparing
        deployable service archive files for Axis2.
        
      * Deployment component, for hot-deployment of Soaplab service
        archive files.
        
      * Service explorer, for exploring services on a given Soaplab
        server.
        
-- Service Editor
This component will present users an HTML form that can be used to
provide the definition of a new service. When the form is submitted, the
dashboard Servlet will generate the files required by Axis2 and will
then pack them in a Web Service archive. The archive basically includes
the Services.xml file and the Java implementation of the service. For
this purpose we plan to use Ant API to call tasks defined in the Soaplab
build.xml file which will eventually use Soaplab2, acdtools (new
development) and Axis2 libraries. It will also be possible to append,
replace and delete services in an existing Web Service archive file.


The information to be provided using the form will basically include the
following.

      * Name of the service
        
      * Service group
        
      * Description of inputs and outputs (the form should be dynamic
        such that any number of inputs/outputs should be definable)
        
      * Name of the executable if the service is a Applab service
        
      * URL if the service is a Gowlab service
        
      * Locations of scripts (BeanShell, Perl) or class files that
        implements the service or XSL files used by the service.
        
      * Other information
        


-- Deployment component
An issue regarding the deployment of current Soaplab services, it
requires restarting the service container because of the deployment
model used by Axis 1.x. However, Axis2 detects the presence of the Web
Service archives in the repository directory and loads the archive
automatically. This 'hot deployment' feature can potentially improve
usability of the deployment component as the Soaplab administrator will
not need to restart the server after deploying a Web Service archive
file. If a Web Service archive file is to be deployed to the same server
where dashboard is running then the deployment component should be able
to deploy the Web Service Archive. Otherwise administrators can deploy a
Web Service archive file by simply copying the archive file to their
Axis2 services repository or they can use the Axis2 web administration
tool.

One issue regarding the Soaplab service archive files; it would be wise
to have the Soaplab library and other libraries used by Soaplab, in the
shared libraries directory of the Axis2 repository rather than in the
service archive file.


-- Service explorer
This component will basically be used for exploring and calling Soaplab
services. Given a Soaplab endpoint, users should be able to see the list
of available services and their descriptions. After selecting a service,
this component should allow users to enter service input data and start
a service call, wait for a result, and display results. When logged in
using an administrator account, administrators should be able to see an
overview of the Soaplab server, such as the number of active users, and
the status of Soaplab service calls, etc.

[Soaplab2-dev] change in CVS at sourceforge

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

[ Sorry for cross-posting...]

Dear users,
   Last week, Sourceforge announced a change in their CVS
repositories. You need to CVS checkout again (or, if using Eclipse, to
change the host from cvs.sourceforge.net to
soaplab.cvs.sourceforge.net). This is what SourceForge suggests:

Summary of changes, effective 2006-05-12:
-----------------------------------------
1. Hostname for CVS service

Old: cvs.sourceforge.net
New: soaplab.cvs.sourceforge.net

cvs -d:pserver:ano...@cv...:/cvsroot/soaplab co soaplab

would be changed to

cvs -d:pserver:ano...@so...:/cvsroot/soaplab co
soaplab

(and similarly for the ssh access)

The same has to be applied to other Soaplab modules (at the moment there
is only one more there: acdtools).

   With regards,
   Martin


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

Re: [Soaplab2-dev] RE: [Soaplab-users] Soaplab 2

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

> I mean, with the CORBA applab layer in soaplab1 it was possible to
> call a *service* on machine A, while the actual *command* is run on
> machine B. This feature is lost, I guess ? If so, is there a way to
> mimick that ?
>
   Well, nothing is lost yet :-) And I am aware of the features that the
Tomcat/CORBA separation gave us. We may still have a plugin in soaplab2
that allows the same distributive feature (perhaps even written in
corba). I will keep this in mind.

   Cheers,
   Martin

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

[Soaplab2-dev] RE: [Soaplab-users] Soaplab 2

[Marc L. <Ma...@DE...>]

Hi Martin,

> * Remove internal dependencies on CORBA (AppLab part).
So, this means that when a command can only run on a certain machine B,
you have to install tomcat/axis and soaplab2 and wrap the command into a
soaplab2 service at that machine ?
I mean, with the CORBA applab layer in soaplab1 it was possible to call
a *service* on machine A, while the actual *command* is run on machine
B.
This feature is lost, I guess ? If so, is there a way to mimick that ?
Cheers,
Marc

[Soaplab2-dev] 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