180 likes | 252 Views
Adapting Legacy Computational Software for XMSF. Elizabeth L. White and J. Mark Pullen Department of Computer Science and C3I Center George Mason University Fairfax, VA 22030 white@cs.gmu.edu; mpullen@gmu.edu. Overview. Background Web services, XML and SOAP
E N D
Adapting Legacy Computational Software for XMSF Elizabeth L. WhiteandJ. Mark Pullen Department of Computer Science and C3I Center George Mason University Fairfax, VA 22030 white@cs.gmu.edu; mpullen@gmu.edu
Overview • Background • Web services, XML and SOAP • From legacy code to web services • Experiments to date • Conclusions
Background - Big Picture • Web-based technologies applied within an extensible framework will enable a new generation of modeling & simulation (M&S) applications to emerge, develop and interoperate. • Support for operational tactical systems is a missing but essential requirement for such M&S applications frameworks. • The framework of Extensible Markup Language (XML)-based languages can provide a bridge between forthcoming M&S requirements and open/commercial web standards, while continuing to support existing M&S technologies. • Compatible and complementary technical approaches are now possible for model definition, simulation execution, network-based education, network scalability, and 2D/3D graphics views. • The Web approach for technology, software tools, content production and broad use provides best business cases from an enterprise-wide (i.e. world wide) perspective.
Background - Goals Enable use of legacy code in XMSF: • Approach should be easy to apply • Platform independence • Inexpensive or freely available tools
Web Services • Definition: a self-contained, self-describing unit of modularity for publishing and delivering XML-based digital services over the Internet. • natural extension of the concept of a resource • accept messages and return replies • all encoding in XML • peer-to-peer or client-server
Specifying Web Services • Externally visible behavior is described in terms of the syntax, semantics, and sequencing of messages exchanged between the service provider and its client • Described using an XML Schema vocabulary • Web Service interface description document specifies a contract between the service provider and its client.
Service Provider Service Consumer Bind Publish Query Service Registry Web Services Model
XML • Universal meta-language of the Web • Used for data, content, messaging, and computing to provide point-to-point integration in a platform-neutral way • Document structure, content and semantics defined by XML schema • Basis for a new generation of lightweight, XML-based, application-level protocols now emerging
Simple Object Access Protocol (SOAP) • XML-based, lightweight messaging protocol for exchange of typed information in decentralized, distributed environments • Enables interoperability among (existing) distributed applications running on disparate, heterogeneous platforms using a modest infrastructure • Guiding principles are simplicity and extensibility by modularity. • Does not define a programming model or require a specific network transport. • Simply consists of a modular packaging mechanism and a set of encoding rules.
SOAP Benefits • Provides a message format, type information and encoding mechanism • Allows platforms-independent information exchange information, irrespective object model or programming language • Packaging mechanism allows for expressing complex communication semantics ranging from RPC-style calls to general message passing (with or without queuing) • Encoding rules, define a data serialization format for exchanging application or platform-specific datatypes. • SOAP message (encoded as XML document) is a one-way transmission routed along a message path
From Legacy Code to Web Services • Approach centers on Java and a publicly available SOAP implementation • Service consumer sends and receives SOAP messages • Service provider has a Java front end that processes requests • Experimental implementations of FORTRAN and C++ services
Java-Based Web services Service Provider Service Consumer SOAP Messages Legacy Code
Source-to-Source Transformation • Option 1: reimplement the functionality in Java • automatically via source-to-source transformation techniques or by hand • resulting executable can be run on any architecture that supports Java • even if it does not have a compiler for the legacy language. • tried this first
Source-to-Source Transformation Problems • FORTRAN to Java tools exist • we used f2j • not completely automatable • data type and control flow limitations • Source code access limited or nonexistent • No good way to test the transformed code • legacy code provided no test cases • Potential performance problems • Java is an interpreted language
Java Wrappers for Legacy Code • Option 2: Java Native Interface (JNI) user creates Java wrappers to use the native code executable directly • C, C++ and FORTRAN • appears to be most automatable approach • results in a faster component • but it may not be portable • so, run the service on a platform that supports it • legacy code has already been tested and accepted • reduces the amount of testing required for the Service
Java Web Services • Transformation of Java component into a Web Service is a relatively painless process • Tools closely track the emerging standards for web-based interaction • Quite straightforward to use • developers to know only minimal XML and SOAP • We used Axis • third generation of Apache SOAP.
Cannon Example(Bourg, Physics for Game Developers, O’Reilly, 2001)
Conclusions • Transformation and Java wrappers are both viable tools • we had more success with wrapping legacy software transformations • preferred choice depends on availability of documentation and test procedures • Issues not addressed • economic tradeoffs • module size vs value of conversion • is the size and function worth the trouble? • registries and dynamic discovery/integration