A Multidatabase Platform to Support. Prototyping Environments. Omar Boucelma, Jean-Claude Franchitti, and Roger King.

Transcription

1 A Multidatabase Platform to Support Prototyping Environments Omar Boucelma, Jean-Claude Franchitti, and Roger King Department of Computer Science University of Colorado at Boulder Campus Box 430 Boulder, Colorado April 11, 1994 ARPA-ProtoTech Quarterly Report, # Abstract The ProtoTech program aims to supply software developers with a general purpose prototyping environment. This environment must provide particular persistence services, services that may be imported from various ARPA Persistent Object Base platforms. However, importing these services imposes serious interoperability problems at various levels of semantics. We are developing a multidatabase interoperability platform, Amalgame, that will allow ProtoTech tools to access the future POB infrastructure. This material is based on work sponsored by the Advanced Research Projects Agency under Grant Numbers N J The content of the information does not necessarily reect the position or the policy of the U.S. Government, and no ocial endorsement should be inferred. 1

2 1 Introduction The ARPA-POB program [Wie92] has isolated a certain number of requirements for a persistent object base (POB). As a consequence of these requirements, a POB must support a wide variety of languages, it also must \provide a consistent layer of persistent object services over all facilities served by the operating system" [Wie92]. Hence a POB must evolve as technology will evolve, in providing the integration of existing legacy applications. To provide a demonstrable POB infrastructure, ARPA is supporting a certain number of projects. Each project is focusing on an interesting part of the persistence problem. For instance, the TI-OOOB system [WBT92] aims to fulll the openness and the seamlessness requirements, the Brown Object Store Systems [ZL92] focuses on distribution, and the SHORE system [CWF + 94] will provide a high-performance and scalable POB for the Mach system. We believe that a suitable combination of the POB systems with commercial products will cover most of the persistence needs identied in the ARPA ProtoTech program. However, these combination poses serious interoperability problems at various levels and granularities of semantics. These problems are hardly studied, and some standards for dening interoperability support mechanisms [Cat93, OMG91] are emerging. To validate the proposed solutions, there is a need for experimentation in various application domains. There is also a need for testing the global or individual eectiveness of the various proposed methodologies. To fulll these needs, and to provide the interoperation of various ARPA persistence platforms, we are currently developing a multidatabase interoperability toolkit called Amalgame [FK93b, FK93a, Fra93]. Although Amalgame is intended as a general purpose heterogeneous application integration toolkit, we initially limited the scope of our research to supporting the incremental integration of heterogeneous database applications. These applications are software systems which are pieced together from existing database application components. In previous experiments, we discovered that Amalgame's integration mechanisms were well adapted to the composition of multidatabase applications. To better support this particular domain, we developed specic extensible support modules to assist the integration of various database systems. In particular, communication, programming language integration, and persistence modules were built into the Amalgame extensible support library. To start our Amalgame experiments within the ProtoTech program, we focused on providing persistence to prototyping languages. The ProtoTech program is one of the ARPA programs that provides an excellent framework for studying interoperability. In addition the prototyping tools integration imposes challenging requirements for multidatabase support. Indeed, objects created during the development process are variable sized, complex, heterogeneous structures. These structures are highly inter-related, with logical connections that span many individual database systems. These objects must be maintained in a consistent state while being shared by dierent tools and being accessed by multiple users. We describe in this paper the design of two Amalgame persistence experiments in the context of the ProtoTech program. We also discuss future work we intend to pursue in the context of the design and the development of a common prototyping infrastructure. 2

3 2 The Amalgame Persistence Experiments This section outlines two suggested experiments. The rst experiment demonstrates the use of Amalgame to quickly develop a persistence layer for the Grin prototyping language [Tea92]. The second experiment denes an Amalgame persistence programmable service module which can be used to add persistence to a programming language 2.1 An Amalgame Generated Persistence Layer for Grin Grin already supports persistence via an interface to PLinda 1 [AS92]. Therefore, our intent is to generate a exible alternative to the existing solution. In particular, our layer will provide the added benet of supporting a selectable set of underlying POBs. Our persistence layer could easily be tailored to support other applications, written in dierent languages. This last feature is particularly useful. Indeed, prototyping languages which do not currently implement persistence could make direct use of the Amalgame generated layer. Figure 1 below illustrates the proposed modications to the existing Grin PLindabased persistence layer. In this gure, we use dashes to outline the PLinda interface components. To implement the proposed solution, we use Amalgame and its persistence module to generate a PAM and an Amalgame generated server which emulates the interface of the existing PLinda-based server. Griffin program Amalgame Environment Amalgame Persistent Layer Persistent Linda TIOODB Griffin Physical Storage Figure 1: Grin Persistence Layer Specifying the proposed PAM interface using Amalgame is straightforward. Indeed, we simply use the low-level persistence interface to PLinda specied by the Grin team and 1 "Persistent Linda" 3

4 create a corresponding Amalgame component which encapsulates the existing interface. In the following, we give a concise explanation of the various steps required to implement our experiment using Amalgame. We then show commented Amalgame scripts to further illustrate the implementation process. Step 1 The PAM interface is specied using the Amalgame Specication Language (ASL). The ASL allows the denition of a PAM interface component within Amalgame. To do so, we rst dene an Amalgame environment which acts as a container for the PAM encapsulated component. The corresponding ASL script portion is shown in Figure Create a new Amalgame environment for the PLinda components -- Specify remote environment name Attach Environment PLINDA ENVIRONMENT -- Specify remote environment specifics With "UNAME:SunOS-4.1.2","USL:Eiffel" -- Specify Amalgame environment name To A PLINDA Figure 2: Creating an Amalgame Environment Step 2 We then specify an Amalgame component which will contain the PAM encapsulated interface. The corresponding ASL script portion is illustrated in Figure Specify an encapsulated Amalgame component which will communicate with the remote -- PLinda application to support read object requests given the persistent id of -- an object and the persistent id of the persistent collection where it is stored. Encapsulate From PLINDA ENVIRONMENT -- Specify as Amalgame sub-component type Type Is "SUBCOMPONENT" -- Specify Amalgame environment name In A PLINDA -- Specify Amalgame component name As LIBRARY.READ VALUE OBJECT Figure 3: Dening an Amalgame Encapsulated Component 4

5 Step 3 Figure 4 illustrates the actual encapsulation of the "read value object" function dened in the original PLinda interface. We use Eiel to code the PAM interface encapsulation. Eiel is the only Underlying Support Language (USL) currently supported by Amalgame. Low-levels Eiel libraries are provided by Amalgame to interface the various passive services required to support our application. Examples of such passive services are the Amalgame RPC software bus and persistence module. Figure 4 illustrates the practical use of these Amalgame services in the context of our Grin experiment. In particular, we use the Amalgame RPC service to generate a serverized component. Also, in our example we use TI OOODB for physical storage and concurrency control. However, any of the underlying stores currently supported by the Amalgame persistence module could be used as an alternative. Finally, Figure 4 illustrates various support methods for implementing the server component instantiation (create method) and the server main processing loop (execute method). To use our Amalgame generated persistence server, Grin programs requests are sent to the PAM server instead of the PLinda server. Storage requests are interpreted by our encapsulated PAM interface and directed to TI OOODB. To conclude the presentation of this rst experiment, we point out the benets and drawbacks of its suggested approach. First, the use of Amalgame and its persistence module reduce implementation costs. Second, the approach provides a seamless interface to a selectable set of underlying POBs (including the Unix le system). Third, the approach allows other languages or applications to reuse and possibly customize the Amalgame generated persistence layer. However, a drawback of the proposed approach is that it does not allow Grin application designers to control persistence from within the Grin language itself. Instead, the approach suggested in this rst experiment acts at the low-level persistence interface to PLinda originally outlined by the Grin team. As a result, the approach does not allow persistence model or underlying store selection directly from the application code. An second approach which alleviates this limitation is discussed in the next section. 5

6 -- Specify PAM interface component using Eiffel as a USL With Specication -> -- USL specification for encapsulated component starts inherit -- We use the Amalgame Q module to implement this server APC RPC SERVER, ADR RPC dene -- Since the inherited APC RPC SERVER class defers the implementation of the -- execute method, execute needs to be tailored to the requirements of our server execute feature -- The Amalgame ENVIRONMENT class provides a seamless interface to multiple POBs. env: POB ENV; -- Underlying POB interface object Create is do -- Setup underlying POB and initialize Q server to accept env.set pob name("tiooodb"); -- Name store server.initialize; end; (...) -- The read value object function requests an object value given the persistent, -- object id and the persistent id of the collection where it is stored read value object(process Id: do Transaction Id: PCollection Id: PValue Id: result buffer: env.set pob type(pob); INTEGER, TRANSACTION ID TYPE, COLLECTION ID TYPE, VALUE ID TYPE, env.open(pcollection Id); (...) STRING) is -- Select proper store result buffer:= env.retrieve(pvalue Id); (...) env.close; end; -- read value object (...) -- The execute method is called from the generic low-level server component -- generated by Amalgame.The execute method decodes the result buffer and returns -- either an error, or an array of bytes corresponding to the requested -- object value and an integer corresponding to the value length. execute is local (...) result buffer: do (...) end; -- execute STRING; <- -- end of USL specification for Encapsulate construct Figure 4: Specifying an Amalgame Encapsulation 6

7 2.2 A Platform for a Flexible and Scalable Persistent System Our previous experiment focused on using the Amalgame persistence module as a passive service. Using this approach, we implemented an alternative way of supporting orthogonal persistence in the Grin prototyping language. Obviously, this rst approach cannot be used to add persistence support to a non-persistent language. However, the intent of this second section is to show how Amalgame can be used, in a limited scope, to address this more general problem. Adding persistence to a programming language is a complex task which leads to several open questions: (i) What is the most suitable persistence model for that language?, (ii) How to implement a particular model in that language without impacting the process of building applications, or aecting the run-time eciency of resulting programs?, (iii) What underlying persistent stores are more suited for a given language?, (iv) How to access multiple persistent stores (simultaneously)?, and (v) How could selection of the underlying store be made transparent to the user? Of course, these are only the most important questions and lots of other issues would require careful evaluation. It is beyond the scope of this section to answer all of these questions. However, our research in the area of persistence support has allowed us to answer some of them. For instance, the Amalgame persistence module supplies a seamless interface to various persistent stores, and it supplies generation of tailorable PAMs. To some extent, the current Amalgame persistence approach does provide answers to questions (iv), (v), and (iii). Question (i) is neither an Amalgame goal, nor a trivial task: hence it will not be covered in the following. To limit the scope of our discussion, we focus on showing how Amalgame can be used to provide an acceptable answer to question (ii). Our proposed solution relies on dening an Amalgame programmable service to support the process of adding persistence to various languages. We briey explain and illustrate the use of an Amalgame programmable service to add persistence to a given language L. Actually, if L is a given Amalgame USL, it is already treated by Amalgame as a programmable service. A component which has been encapsulated using L as a USL is be compiled at packaging time according to the process dened in an associated extension component. Extension components associated to programmable language services usually amount to simple compile scripts. The above described model, currently supported in Amalgame, can be extended to support persistence extensions to a given language L. Let us assume that a persistent version of the language L, say LP, includes additional constructs for specifying a persistence model, or an underlying persistent store. Figure 5 below provides illustrative code fragments written in pseudo code for L and LP. We assume that LP supports the keyword "persistent" to specify objects which should be made persistent. LP also supports the keyword "use" to specify a selected underlying store. To dene LP as a Amalgame programmable service, we associate an extension component to LP which corresponds to a precompiler script. The LP precompiler translates the persistent source code written in LP into source code written in L. The resulting source code written in L performs calls to a PAM interface generated by the LP precompiler. In order to generate this PAM interface, the LP precompiler uses the Amalgame persistence 7

8 Language L item *p; p = new item; Language LP use "TIOOODB" persistent item *p; p = pnew item; Figure 5: Sample Persistence Extension to a Given Language module as a passive service as described in the rst section of this document. The generated PAM and its associated interface match the requirements originally specied using LP constructs. From a programming language standpoint, a PAM is a set of function calls that interpret persistent statements. Syntactically these statements depend on the model of persistence and the underlying language. For example, in the ODE system [AG89], persistent objects are referenced by pointers and allocated (and deallocated) in a manner similar to the transient objects. The syntax used in the LP code fragment in Figure 5 is compatible with the syntax proposed in the ODE system. At this stage the above described experiment is still under development. In particular, we are currently adding USL support to Amalgame. This support includes incremental language conversion tools which will be used to support the conversion between the L and LP languages as suggested above. Once these various extensions are operational, the Amalgame extensible architecture will provide an excellent environment for developing persistent systems. A particular class of such systems is referred to as Persistent Application Systems (PAS) in the database research community. PAS are characterized as providers of reliable persistence support, and cooperative work across various computers. A typical PAS uses various building blocks such as Graphical User Interfaces, DBMS, programming languages, integration and communication tools. 3 Future ProtoTech Developments In the last ProtoTech quarterly meeting [Gro94], the ProtoTech working groups isolated a certain number of research directions, and suggested a vision for the prototyping environment. To provide the ProtoTech community with an improved interoperablity platform, we intend to focus our research eort in the following directions: 1. Interoperability A prototyping environment requires support for heterogeneous components residing in a hub environment. This environment may use multiple underlying databases to store components specied in various hub languages. Applications resulting from the composition of such components involve type and execution models interoperability problems. These problems require further study and experimentation to help dene and validate upcoming interoperability standards 2. Algebra of compositions Using Amalgame, we have explored the construction of component-based applications. We took the approach of encapsulating software components in an objectoriented framework. This process is formally well understood as long as components 8

9 are viewed as static objects. However, software components interoperability requires an improved formal description when components are viewed as communicating objects at runtime. Existing related formal work such -calculus [Mil91] should be extended to help provide a better understanding of interoperability among heterogeneous software components. 3. Integrated testbed support As a result of our interoperability experiments, we realized the need for an integrated, extensible multidatabase platform to support prototyping and software engineering environments. In order to be used as a testbed for prototyping technology, such a platform should be tightly integrated with the hub environment. The platform should also provide an extensible set of services such as: language translation mechanisms, software buses, multidatabase support modules, packagers, etc. In addition, the platform should adhere to upcoming standards (OMG, ODMG, SQL-3, etc.), and should exploit commercial tools as much as possible References [AG89] [AS92] [Cat93] R. Agrawal and N. Gehani. Ode: The language and the data model. In Proceedings of the International Conference SIGMOD, Portland, Oregon, B. Anderson and D. Shasha. Persistent Linda: Linda + Transactions + Query Processing. Lecture Notes in Computer Science, 574, R.G.G. Cattell. The Object Database Standard: ODMG-93. Morgan Kaufmann, [CWF + 94] M. Carey, D. J. De Witt, M. Franklin, N. Hall, M. McAulie J. F. Naughton, and al. Shoring Up Persistent Applications. In Proceedings of the ACM SIG- MOD Conference, Minneapolis, May, 24{ ACM. [FK93a] [FK93b] [Fra93] J. C. Franchitti and R. King. A Language for Composing Heterogeneous, Persistent Applications. In Proceedings of the Workshop on Interoperability of Database Systems and Database Applications, Fribourg, Switzerland, October Springer-Verlag, LNCS.. J. C. Franchitti and R. King. Amalgame: A Tool for Creating Interoperating, Persistent, Heterogeneous Components. In Advanced Database Systems, pages 313{336. Springer-Verlag, LNCS #759, Nabil R. Adam and Bharat K. Bhargava (Eds.). J. C. Franchitti. Amalgame: An Extensible Toolkit for Composing Heterogeneous, Persistent Applications. PhD thesis, University of Colorado, Boulder, Department of Computer Science, University of Colorado, Boulder, CO 80309, [Gro94] The ProtoTech Working Groups. Minutes from the Prototech Environment Working Groups. In ProtoTech Workshop, Washington, DC,

10 [Mil91] R. Milner. The Ployadic -Calculus: a Tutorial. Technical report, Laboratory of Foundations for Computer Sciences, Department of Computer Science, University of Edinburgh, [OMG91] [Tea92] [WBT92] [Wie92] [ZL92] OMG. The Common Object Request Broker: Architecture and Specication. Technical Report , Revision 1.1, OMG, December Grin Team. GRIFFIN: Language Reference Manual. New York University, New York, NY 10012, October Version D. L. Wells, J. A. Blakeley, and G. W. Thompson. Architecture of an open object-oriented database system. Computer, 25(10):74{82, October G. Wiederhold. Objectives of the Persistent Object Base Program. In DARPA Software Technology Conference, pages 256{258, Los Angeles, CA, April, 28{ DARPA. S. B. Zdonik and D. E. Langworthy. The Brown Object Storage System. In DARPA Software Technology Conference, pages 275{276, Los Angeles, CA, April, 28{ DARPA. 10