Information Technology Reference
In-Depth Information
directly related to the gateway framework development, they should also provide
user support, including the evaluation of feature requests and further developing the
gateway framework according to the new functionality requirements. Developing
an SG framework requires very deep understanding of the underlying infrastruc-
tures and the required web technologies. Therefore, to develop an SG framework
the developer community should invest in a long-running and constant learning
process, which is very costly. As a result, there are only very few SG frameworks,
and the number of gateway framework developers is also very low.
The main task of the SG instance developers is either to customize an existing
SG framework for their user community, i.e., to extend the SG framework with new
application-speci
c interfaces, or to develop the SG instance from scratch. In the
former
—
and recommended
—
case SG instance developers can concentrate on the
application domain-speci
c features of their SG. In the latter case, they need to
learn all those aspects of the underlying DCI middleware and web technologies that
are needed for the SG framework developers. As a result, they usually create the SG
instance much more slowly and with more efforts than those SG instance devel-
opers who choose the customization development method. The number of SG
instance developers is about an order of magnitude larger than the number of SG
framework developers, but in the ideal case, the difference would be even two
orders of magnitude. In the case of the WS-PGRADE/gUSE framework we get
close to this ideal case, since the framework has been adapted by more than 90
different communities who develop SG instances based on the framework. The WS-
PGRADE/gUSE framework helps this customization process by providing a special
API called Application Speci
c Module (ASM) API by which existing work
ows
can easily be embedded in application speci
c portlets (see details in Chap.
3
).
Once the SG frameworks or SG instances are developed, they should be set up
and operated. Here the role of
gateway operators
comes into play. They should be
able to deploy, con
gure, run, and maintain the gateway service for the user
communities. For these purposes, good gateways provide complete and up-to-date
documentation, installation and con
guration wizards, user management support
interfaces, etc. These can be developed in a generic way within an SG framework
and just be used (and maybe adapted) by SG instances.
Once the SG frameworks or SG instances are set up and operating, they are
ready for use. We must distinguish two user categories:
end-users
and
application
developers
. In fact, they need different front-ends. The application developers
develop DCI applications, for example, new work
ows, which are used by the end-
users. The application developers are typically IT people or scientists (chemists,
etc.) with good understanding of the underlying IT technology. They should have
relatively detailed information on the underlying DCIs, while this information could
partially or completely be hidden from the end-users. Therefore, the SG frameworks
are primarily targeted to the application developers, and the SG instances are
typically designed for the end-users. Of course, this typical usage does not exclude
the possibility that some SG frameworks can be used by end-users and SG instances
can provide front-ends necessary for DCI application development. However, a
good practice is the clear separation and support of these two user types, and WS-
Search WWH ::
Custom Search