Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.adass.org/adass/proceedings/adass02/P2-5/
Дата изменения: Thu Mar 13 02:28:49 2003
Дата индексирования: Tue Oct 2 04:04:38 2012
Кодировка:
Поисковые слова: п п п п п п п п п п п п п п п п п п п п
|
Next: A Collaborative Extension to the Solar Web Tool
Up: Web Services and Publications
Previous: Manuscript Preparation, Submission and Features of the Electronic IBVS
Table of Contents -
Subject Index -
Author Index -
Search -
PS reprint -
PDF reprint
Taylor, M., Platon, R., Chipperfield, A., Draper, P., McIlwrath, B., & Giaretta, D. 2003, in ASP Conf. Ser., Vol. 295 Astronomical Data Analysis Software and Systems XII, eds. H. E. Payne, R. I. Jedrzejewski, & R. N.
Hook (San Francisco: ASP), 325
Web Services and Their Use in Starlink Software
Mark Taylor, Roy Platon, Alan Chipperfield, Peter Draper, Brian McIlwrath, David Giaretta
Starlink Project, UK
Abstract:
Web Services are gaining great popularity in the Grid community,
and with good reason. The Starlink project is adopting Web Services
as the method of interapplication communication. This is being done
natively in new Java-based applications while older applications are
being wrapped to provide Web Service interfaces. We are in this way
providing interoperability between the generations of software in a
heterogeneous, distributed manner and allowing the software to be usable
in a distributed environment such as the GRID.
Starlink applications have until now used a dedicated messaging system.
This gives a closely coupled command interface to applications.
In addition, data is accessed via the NDF data access layer. Figure 1
illustrates the overall architecture of a typical application.
As part of a new phase of developments we are starting to use Web Services
as our messaging system. This not only bases our work on Open Standards,
allowing us greater opportunities for interoperability, but also gives
us access to a variety of tools. It allows us to work naturally in a
distributed environment, and in particular positions the applications
to play a natural role in the Virtual Observatory.
The new architecture, shown in Figure 2, must allow us to work
transparently with old as well as new applications. Clients communicate
with a server (for example a TOMCAT/AXIS or embedded server) via SOAP
messages, usually over HTTP. The server then redirects the messages
to either a JNI interface for a non-Java application, OR to a native
Java application.
Figure 1:
Starlink classic application architecture.
|
Data access is via the network enabled NDF data access layer for the
older, non-Java applications and via the new HDX layer (Giaretta et
al. 2003) for the pure-Java application. Data access could include
appropriate authentication and authorisation, for example using
GLOBUS-type certificates and fitting in to the
Open Grid Services Architecture
(OGSA).
Figure 2:
New application architecture.
|
When defining interfaces to existing applications a number of
options are available. These are not mutually exclusive, but too
many interfaces can cause maintenance problems. The simplest
choices include (a) complete command lines as a single string and
(b) making each parameter separately available. Option (a) is
simpler but less easy to use and to validate. However it may
provide an easier transition for pipeline processing systems such
as ORAC-DR.
Option (b) on the other hand is better suited to an application
which is being run effectively interactively with user input.
Based on our investigations at the time of writing, a number of problems and advantages have been identified. Problems:
- Robustness: if the server and application are part of the same JVM then a fatal
exception in the latter can kill the former.
- Interactivity: the loss of close coupling between the command interface and the
application makes interactive work difficult.
- Interface definitions: any plans for replacing ``classic applications" by pure Java
ones will require the older interfaces to be supported, although they can be
extended. Web Service interfaces to non-Java applications should therefore be
chosen carefully.
- Error handling: requires special care.
- Image display: While display via X is possible, it is an extra complication.
Advantages:
- Distributable: tasks can be distributed to appropriate servers for
example co-located with the data or to use available CPU power.
- Replaceable components: applications can be transparently replaced, as long as
the interfaces are replaced by single or multiple new components.
- Available infrastructure software: UDDI servers to advertise information, SOAP servers.
- Compatibility with GRID: OGSA is built on Web Services. Publishing
astronomical applications as Web Services is the first step in making these
available via OGSA.
- Flexible command interface implementation: SOAP-enabled clients can be
produced in a variety of languages using easily available support
libraries, e.g., Java, Perl, Python, etc.
Use of Web Services as a new messaging system will allow Starlink
applications increased flexibility. Old and new applications will be
able to interoperate easily and the software will be suitable to use in
the Virtual Observatory.
References
Giaretta, D., Taylor, M., Draper, P., Gray, N., &
McIlwrath, B. 2003, this volume, 221
© Copyright 2003 Astronomical Society of the Pacific, 390 Ashton Avenue, San Francisco, California 94112, USA
Next: A Collaborative Extension to the Solar Web Tool
Up: Web Services and Publications
Previous: Manuscript Preparation, Submission and Features of the Electronic IBVS
Table of Contents -
Subject Index -
Author Index -
Search -
PS reprint -
PDF reprint