Adapting Legacy Computational Software for XMSF

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

Adapting Legacy Computational Software for XMSF