MMM - Middleware for Method Management on the WWW

In:   WEB ENGINEERING'99.

The MMM platform constitutes an infrastructure for managing the deployment and use of distributed application services on the WWW. MMM propagates a paradigm that enables the leasing of software components, as opposed to the classical software licensing model. Applications reside on the software provider's platforms, but are managed through the MMM infrastructure. Users interact with the application services through the standard Internet browser, not requiring any additional software. The MMM user interface offers the user a virtual file space, application service composition functions, execution support, and visualization features. The MMM platform integrates complementing web technologies and database technology, such as HTML, XML, MetaHTML, and ODBC in its implementation. In this paper we give an overview of the MMM architecture and discuss its primary features.

1. Introduction

The World Wide Web, a distributed hypermedia information system on the Internet, demonstrates successfully how current technology can support the sharing of information among widely dispersed groups of users. It not only has brought millions of new users to the Internet, but it also has made it easier and indeed desirable to publish and widely disseminate documents of all kinds.

The MMM - Middleware for Method Management project investigates the question whether the distributed authoring and distribution of software components can be supported in a similar manner. Moreover, MMM aims at exploring whether a new software deployment and licensing model - component leasing together with a payment-per-transaction business model constitutes a feasible alternative to the current "all-or-nothing" software licensing model for software utilization and distribution over the WWW.

The MMM paradigm contributes an infrastructure that manages applications for deployment and use over the WWW. Application providers are able to register their services which are managed by the MMM infrastructure, but run on the supplier's hardware platform. Application components and user actions are closely monitored by the infrastructure and therefore allow for a software leasing model to be enforced. Registration of services (i.e. applications) can occur any time and the system does not need to be re-started or otherwise interrupted.

For complex applications that are used "infrequently", such as weekly portfolio tracking, tax return calculation, geo-marketing, or mathematical software use a leasing model is especially attractive. This is because the cost-of-ownership of such packages is rather high compared to the return gained from using them. Moreover, the user is freed from the burden of software installation and maintenance, but rather interacts with the most up to date version of the software.

The MMM platform implements a distributed computing environment with Web-browsers providing the user interface to registered application components world wide.

This poses the following challenges:

• Encapsulation of distributed computational services :
  

  The MMM infrastructure offers a limited number of services that provide a core set of functionality, such as user registration, user data management, common data transformations, and integrates some application services locally. The majority of services, however, are provided by the interacting users themselves (i.e., by participating institutions).
  
  This raises issues relating to the description of service interfaces, data formats for the exchange and use of computational resources, and protocols to link third party components into the MMM middleware.

• Incorporation of heterogeneous data sources :
  

  MMM aims at providing a great deal of flexibility to enable the seamless and transparent incorporation of many common data sources, such as various commercial database interfaces, ftp--sites, web--sites, and manual data entry.
  
  This raises issues relating to data representation, format transformation, interfacing to a large number of communication protocols, and support for a variety of database access protocols.
  
  Requested data sets can be very large, therefore a highly optimized scheme for transferring the data set to the computing resource is absolutely crucial. Furthermore, some data providers may not allow their data to be freely distributed, but merely allow computations on the data to take place. A sophisticated security and execution scheme is needed to manage such constraints.

• Method management :
  

  The management of methods from distributed and heterogeneous application providers requires the careful maintenance of meta-data about the individual methods. It must be possible to chain several methods originating from different providers. Moreover, it must be possible to view, edit, and search for methods accessible online.

Incorporation of methods and data is made possible through the use of XML (eXtended Markup Language) and RDBMS (Relation Database Management System) technology. Users fill out forms generated from DTD (Document Type Definition) specification in order to describe method and data objects.

To this end, MMM connects users to services which provide interoperable access to mathematical computing servers distributed on the Internet to test and verify the above motivated software leasing model in a controlled setting.

This paper aims at discussing how the above challenges are met within the MMM architecture. In the next section we give an overview of the MMM architecture with emphasize on the above issues. We continue with a discussion of the MMM user interface and we end by presenting some open problems.

2. Middleware

The MMM Middleware consists of the following components: Execution environment, service engine registry and server engines, an object model, and an open protocol linking the components.

MMM imposes a simple object model on the user. The object model is the basis for all system interaction and functionality, such as method and data entry, data base population, communication among system components, and communication with external application services.

All entities managed by MMM belong to one of the following classes: data set objects (DSO), method session objects (MSO), method plan objects (MPO). These are the primary abstractions around which the infrastructure is built. DSO encapsulate meta-data about the data sets that are used in computations, such as format, type, location, size, source, and provider, among others. Access restrictions, a notion similar to the UNIX file permissions are also encoded in the DSO and designate who may access the data through which methods. MSO encapsulate methods and provide similar meta-data. MPO constitute descriptions of execution chains of methods and abstractions for results returned from method executions.

The overall architecture of the MMM Middleware is depicted in Figure 1.

The execution environment (EE) is responsible for the execution of methods. It schedules the method plans trying to maximally utilize the available computing resources. The EE incorporates several optimizations for minimizing data movement among computing resources and maximizing throughput. It knows about the available resources and performs load balancing. The EE receives as input a method plan object and returns a plan object as output. The output MPO describes the result of the computation. It specifies location of result data, computation time, possible error conditions, and the like. The execution environment interfaces with an application service through a service engine. It uses the service engine registry to obtain location details of the SE driving the application service.

The service engine registry (SER) is used to register and de-register application services and to maintain resource and availability information (e.g., location, network parameters, machine specifications, etc.). The registry also maintains an up to date mapping of application services to service locations and resource characteristica. It thus provides vital information for the EE, which regularly queries the SER for this information to derive plan scheduling decisions.

The SER also serves to decouple the EE from the service engines (i.e., the application services) and allows for dynamic extensibility of the system. Application servers may be added at system run time without loss of operation and become immediately available as services.

By frequently updating its resource list the SER provides simple load balancing functionality that helps to distribute the computational load over the available services, ensuring that no one service engine is overburdened. The service engine encapsulate application services linking them into the MMM middleware. Service engines are responsible for converting data between the internal MMM format and the format required by the underlying application, retrieving data from remote sources, invoking the requested method on the application, and passing result information back to the MMM middleware. Note that "result information" can either be the result of the computation or a reference to the result of the computation, depending on the mode of invocation (cf discussion on application-level protocols below).

We use XML to impose the classical object oriented model on the middleware, with XML DTDs declaring the object classes and XML-documents defining the object instances. The structure of all objects MSOs, DSOs, and MPOs in MMM are defined through XML DTDs. This permits the generation of all kind of support tools for the manipulation of object instances, such as HTML-forms for data entry and browsing, database records for storage, and transport records for communication. A XML document instantiates a MMM object (i.e., provides its attributes).

Interfaces between SE and application are defined through XML documents for similar reasons. A single XML-"document" is required to configure a new application server. The document (application wrapper) defines how parameters are passed to the application, whether or not the application is used in batch- or interactive-mode, what execution permissions need to be set to access its services, and the like.

Each component in the MMM architecture is designed to be independent of implementation language and location within the distributed computing environment (i.e., the Web). Components can be configured to dynamically alter their information on other components. Components can be duplicated on the Web to increase availability.

Method plan objects describe the relation between multiple methods and the data required to execute them. A plan is fully defined through a XML DTD. A particular plan instantiation is a XML-document. Examples of XML DTDs defining MSOs DSOs MPOs and corresponding instantiations can be found on the MMM-Web sites.

Three kinds of application-level protocols have to be distinguished in the MMM middleware: inter-component communication, demand driven data access (a.k.a. MMM-TP - MMM-Transport Protocol), and database access protocols.

The protocol linking the Middleware components is a three stage sendmail-like protocol: logging in to a component, placing a request with a component, and transmission of the data required for the request. Results are, either returned immediately, or the addressed component re-establishes the connection initiating the transmission of the result data. This later modus of operation is applied if the requested computation takes a considerable amount of time to complete.

The MMM TP protocol permits service engines to retrieve data from the system database through our MetaHTML enabled web server. The protocol has been developed as an extension of HTTP for several reasons: (1) Fast, direct, and highly optimized database access. (2) Demand driven data retrieval, i.e., data is only actually retrieved where and when it is needed for computations. For all other cases referrencial information and meta-data is manipulated (i.e., MSOs, DSOs). (3) Need for fine-grained access control mechanisms beyond what is currently available for HTTP.

For MMM TP we define an new type of URL: mmmtp which allows retrieval of data and objects from the MMM database. The form of this URL is:

mmmtp://<host>:<port>/data/location/<user name>

Notice that the user name must be appended to the URL definition. For example to retrieve the file /guest/MatrixData as user foobar from the MMM Database:

mmmtp://meta-mmm.wiwi.hu-berlin.de:80/guest/MatrixData/foobar

Common URIs such as http and ftp are also supported. We aim at supporting the OMG IIOP protocol (URI iiop) in the future to enable direct communication with CORBA-compliant applications system.

For database access we rely entirely on the ODBC support provided by our primary development language - MetaHtml. We currently use the mSQL database from Hughes Technology as underlying DBMS. Due to the strict use of the ODBC interface to access the database the underlying DBMS technology may be substituted at any project stage.

3. User Interface and user-system interaction

The MMM user interface (UI) is entirely based on Internet browser technology using a combination of HTML, XML, and MetaHTML. MetaHTML is a server side interpreted language for the generation of dynamic HTML pages. Amongst its features is the maintaining of user session state information, seamless access to server side applications, and fast ODBC database accesses. The MMM UI needs to support viewing, browsing, searching, entering, editing, and modification capabilities for all objects represented in MMM. Another crucial issue important to the MMM UI design is simplicity, both in terms of navigation and in terms of usability.

For the user the UI must provide a desktop environment for managing method and data objects. This includes composition of method plans, selection of input parameters, execution support, and result notification functions. Moreover, for method providers the MMM UI must provide bulk method entry functions that allow easy and quick check-in of computational methods. For the MMM infrastructure administrator the UI must provide administration tools for managing and monitoring user actions.

Browsing the MMM database and Method space is made clearer by assigning each user a Virtual File Space. This view maps a flat RDBMS table space into a file and directory hierarchy combined with Unix user permissions on each file and directory. These permissions are enforced by the web server and users are able to restrict areas of their file space from being viewed by other users.

Representation of this Virtual File Space can be chosen by the user from: a Unix ls-like, Windows File Explorer, or an icons representation. And operations can be performed on each item contained in the user space. Specific operations adapt themselves according to the type of object under consideration.

The MMM UI must also adapt to modifications to the object description, and identifying difference in presentation of the objects. Using XML allows us to solve these problems. Defining a generic display mechanism for all XML defined objects allows MMM to display, potentially, any object which uses XML for its description. In designing the user interface, we aimed to provide a flexible, easy to access, and easy to understand interface. Flexible because as our needs changed, we did not want to rebuild the entire entry system, instead one document would be used to define the entry, viewing, editing and storing of methods and data objects. Easy to access because we did not want to require users to install specialized software or even upgrade their existing software. Easy to understand so that we did not need to provide on-site support.

Users of MMM should find the system as easy to use as online shopping: find the item of interest, view the details of that item and use that item. In the case of MMM the item is a Method or Data object.

4. Related Work

SMART [Abel, 1997] present an Internet marketplace model with emphasis on spatial data processing. SMART was developed as tool for use by the government to assist in county planning tasks and to simplify related administrative tasks. We are not aware of it being available to the general Internet community for use, or any attempts of making it available as a commercial internet service. With MMM we are more aiming at a generic Middleware that supports all kinds of applications.

Bhargava and Tettelbach [Bhargava and Tettelbach, 1998] implemented a waste disposal planner for the Monterey Area by combining geographic data with data about the types of waste and prices. Providers of waste disposal services can register their location and prices online. Users may employ the service for look-up or for the computation of an optimal disposal strategy. The system is stand-alone serving the application of waste disposal only. All computation is done at a central server site. Our approach differs in that we offer a distributed computing environment.

The Argonne National Laboratories' NEOS service, [Czyzyk et al.,1997] provides access to optimization software, for use by researchers world wide. Olsen and Associates, a Swiss company operates a commercial decision support service on the World Wide Web. The site features a complete set of models, libraries, and support for financial market customers. In these two cases, a single institution is responsible to set up all resources, including the server-side infrastructure, the integration of the computational packages at the server, and the client-side user interface. A parameterizable set of algorithms is provided that solves a specific task on a single site. Resource diversity and heterogeneity can thus be largely avoided, the primary point of attack of our infrastructure.

A proposals for an electronic commerce approach for a Decision Support Service has been presented by Jeusfeld and Bui [Jeusfeld and Bui, 1995] (cf. DecisionNet project [Ba et al, 1995].

This paper introduced an infrastructure that implements a software component leasing model. We gave an overview of the infrastructure architecture, motivated its deployment, and discussed user interface issues.

MMM constitutes a Middleware that integrates complementing web technologies. Much of the functionality provided by the Middleware is available in current industrial strength Middleware platforms, such as CORBA. However, the key problem faced in using CORBA is the unavailability of mechanisms to support the kind of web technology we are using at the client side. CORBA is entirely unsuited for this kind of processing. However, for the integration of application components CORBA offers several advantages. In the future we aim at combining these technologies.

User interface to the MMM system is also a further area of research. As there exists no paradigm for the design and implementation of UIs which relate to retrieving and combining Methods and Data, further investigation is required to define such a paradigm.

Investigation of the most favorable paradigm for E-Commerce and Micro-Payments. Possible strategies include pay-per-execution or pay-per-execution-time. Further investigation of these issues are inter-related with the issues of software component leasing model and whether this model is the best model for the MMM System.

The MMM platform, as described is fully implemented and accessible on our www site: http://meta-mmm.wiwi.hu-berlin.de.

S. Ba, R. Kalakota, and A.B. Whinston.   Executable documents as the basis for DSS.   In T. X. Bui, (editor), Proceedings of the Third International Society for Decision Support Systems Conference, Vol. II}, pages 373--381.

Acknowledgements