[Soaplab2-dev] description for the dashboard
Brought to you by:
marsenger
|
From: Mahmut U. <ul...@eb...> - 2006-05-25 14:51:50
|
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.
|