Applying Model-Integrated Computing to Component Middleware and Enterprise Applications

Aniruddha Gokhale Douglas C. Schmidt Balachandran Natarajan, Nanbor Wang g [email protected] [email protected] fbala, nanbor @cs.wustl.edu

Institute for Software Dept. of Electrical Dept. of Computer Science Integrated Systems and Computer Engineering Vanderbilt University University of California Washington University P O Box 36, Peabody 616E Engineering Tower One Brookings Drive Nashville, TN 37203 Irvine, CA 92697 St. Louis, MO 63130

Keywords: Middleware, Model-Integrated Computing, Vertical models of domain concepts, such as common Model Driven Architectures, Architectural and CORBA Com- semantics for higher-level reusable component services, ponent Model and

Connector mechanisms between components,suchasre- 1 Introduction mote method invocations or message passing. Examples of COTS component middleware include the The term enterprise application applies to a large class of Common Object Request Broker Architecture (CORBA) applications that perform important business functions, such (www.omg.org), Java 2 Enterprise Edition (J2EE) (java. as planning enterprise resource usage, automating key busi- sun.com/j2ee), and emerging web services middleware, ness functions, and managing supply chains and customer re- such as .NET (www.microsoft.com/net/default. lationships. Examples of enterprise applications include air- asp) and ONE (wwws.sun.com/software/sunone/ line reservation systems, bank asset management systems, and index.html), based on XML (www.w3c.org/XML)and just-in-time inventory control systems. These types of appli- SOAP (www.w3c.org/2000/xp/Group/). cations constitute the majority of worldwide information tech- Despite advances in the ubiquity and quality of component nology (IT) investment and staffing, with annual expenditures middleware, however, developers of enterprise applications expected to exceed $7.3 billion US dollars by 2004 and with still face the following challenges: millions of IT professionals employed. Proliferation of middleware technologies. Large-scale, Enterprise applications historically ran on mainframes and long-lived enterprise applications require component middle- were developed using custom built in-house applications and ware platforms to work with heterogeneous platforms and proprietary systems, such as HighExPlus, BancsConnect, languages, interface with legacy code written in different and EX. Due to deregulation, time-to-market pressures, and languages, and interoperate with multiple technologies from stiff global competition for human and economic resources, many suppliers. However, COTS component middleware however, enterprise applications increasingly run on servers technologies do not yet provide complete end-to-end solutions and PC’s and are developed using commercial-off-the-shelf that support enterprise application development in diverse en- (COTS) component middleware. Component middleware environments. capsulates specific services or sets of services to provide Satisfying multiple quality of service requirements simul- reusable building blocks that can be composed to develop en- taneously. An increasing number of enterprise applications, terprise applications more rapidly and robustly than those built such as high-volume e-commerce systems and automated entirely from scratch. In particular, component middleware stock trading systems, have stringent quality of service (QoS) offers enterprise application developers the following reusable demands, such as efficiency, scalability, dependability, and se- capabilities: curity, that must be satisfied simultaneously and that cross-cut

Horizontal infrastructure services, such as request bro- multiple layers and require end-to-end enforcement. Conven- kers tional implementations of component middleware cannot en-

1 force complex QoS requirements of enterprise applications ef- Various technologies, such as OSF’s Distributed Com- fectively, however, since they were designed for applications puting Environment (DCE) (www.opengroup.org/dce), with less stringent requirements. IBM’sMQSeries(www-3.ibm.com/software/ts/ Accidental complexities in assembling components. To mqseries/), and CORBA, emerged over the past two reduce lifecycle costs and time-to-market, application devel- decades to alleviate complexities associated with developing opers are attempting to assemble and deploy enterprise appli- software for enterprise applications. Their successes have cations by selecting the right set of compatible COTS compo- added the middleware paradigm to the familiar operating sys- nents, which in itself is a daunting task. The problem is further tem, programming language, networking, and database of- exacerbated by the existence of myriad strategies for config- ferings used by previous generations of software develop- uring and deploying the underlying component middleware. ers. By decoupling application-specific functionality and logic Application developers therefore spend non-trivial amounts of from the accidental complexities inherent in the infrastruc- time debugging problems associated with the selection of in- ture, middleware enables application developers to concen- compatible strategies and components. trate on programming application-specific functionality, rather A promising way to address the challenges described above than wrestling repeatedly with lower-level infrastructure chal- is to apply Model-Integrated Computing (MIC) technolo- lenges. gies [1]. MIC is a paradigm for expressing application func- Limitations with object-oriented middleware. The Object tionality and QoS requirements at higher levels of abstraction Management Architecture (OMA) in the CORBA 2.x speci- than is possible with programming languages like Visual Ba- fications [3] defines an object-oriented middleware standard sic, Java, C++, or C#. In the context of enterprise applications, for building portable distributed applications. The CORBA MIC tools can be applied to 2.x specification focuses on interfaces, which are contracts 1. Analyze different—but interdependent—characteristics between clients and servers that define how clients view and of system behavior, such as scalability, safety, and se- access object services provided by a server. These objects can curity. Tool-specific model interpreters translate the in- be distributed or collocated throughout a network. Although formation specified by models into the input format ex- this model has certain virtues, such as location transparency, it pected by analysis tools. These tools check whether the has the following limitations [4]:

requested behavior and properties are feasible given the Lack of functional boundaries. The CORBA 2.x ob- constraints. ject model treats all interfaces as client/server contracts. 2. Synthesize platform-specific code that is customized for This object model, however, does not provide sufficient specific component middleware and enterprise applica- mechanisms to prevent tight coupling among collabo- tion properties, such as isolation levels of a transaction, rating object implementations. For example, object im- recovery strategies to handle various runtime failures, and plementations that depend on other objects need to dis- authentication and authorization strategies modeled at a cover and connect to these objects explicitly. To construct higher level of abstraction. large-scale enterprise applications, therefore, application Understanding how to integrate MIC and component mid- developers need to program the connections among in- dleware is essential to resolve the configuration, manage- terdependent services, which can yield brittle and non- ment, and deployment challenges of enterprise applications reusable implementations.

described above. The remainder of this paper presents an Lack of generic application servers. CORBA 2.x does overview of component middleware and Model-Integrated not specify a generic application server framework to Computing and then describes how combining the best el- perform common “bookkeeping” work, including initial- ements of these two technologies can address the key chal- izing the broker and its QoS policies, providing com- lenges associated with developing enterprise applications. mon services (such as a transaction service), and managing the runtime environment of components. Although CORBA 2.x standardized the interactions between ob- 2 Overview of Component Middleware ject implementations and object request brokers (ORBs), server developers are still responsible for determining Middleware capabilities. Middleware is reusable software how object implementations are installed in an ORB and that resides between the applications and the underlying oper- the interaction between the ORB and object implementa- ating systems, network protocol stacks, and hardware [2]. Its tions. The lack of a generic application server standard primary role is to bridge the gap between application programs has yielded tightly coupled, ad-hoc application server and the lower-level hardware and software infrastructure to co- implementations, which increase the complexity of soft- ordinate how parts of applications are connected and how they ware upgrades and reduce the reusability and ﬂexibility interoperate. of CORBA-based applications.

2 Integrated System Promising solution ! component middleware. In the past Model Constraints several years, component middleware [5] has emerged to address the limitations with object-oriented middleware outlined above. Component middleware addresses these issues by cre- Model ating a virtual boundary around application components with Interpreter & Integrate & Executable Code Generate specifications well-deﬁned interfaces and composing and executing compo- Synthesizer nents in generic application servers. Popular COTS component middleware platforms being used for enterprise applications today include the CORBA Component Model [6], J2EE, Platform- Application specific and emerging web services middleware, such as .NET and Code Synthesize Code ONE, that are based on XML and SOAP. Generator

Figure 1: The Model-Integrated Computing Process 3 Overview of Model-Integrated Com- puting ments in the context of the specified constraints. Another set of tools then translates models into executable specifications Model-Integrated Computing (MIC) [1] is a development that capture the platform behavior, constraints, and interactions with the environment. These executable specifications paradigm that systematically applies domain-specific modeling languages to engineer computing systems ranging from in turn can be used to synthesize application software. small-scale real-time embedded systems to large-scale enterprise applications. MIC provides rich, domain-specific model- 4 Combining Model-Integrated Com- ing environments, including model analysis and model-based program synthesis tools [7]. In the MIC paradigm, applica- puting with Component Middleware tion developers model an integrated, end-to-end view of the entire application, including the interdependencies of its com- As described in the previous two sections, MIC and compo- ponents. Rather than focusing on a single, custom application, nent middleware have evolved independently from different therefore, MIC models capture the essence of a class of ap- perspectives. Although these two paradigms have achieved plications. MIC also allows the modeling languages and envi- good success independently, each has the following limita- ronments themselves to be modeled by so-called meta-models, tions: which help to synthesize domain-specific modeling languages Complexity due to heterogeneity. Conventional compo- that can capture the nuances of domains they are designed to nent middleware is developed using separate tools and in- model. terfaces written and optimized manually for each middle- Various technologies, such as Computer-Aided Software ware specification, such as CORBA, J2EE, and .NET, and Engineering (CASE) and related OOA/OOD approaches by for each target deployment, such as the various OS, network, Yourdon and others, have evolved into sophisticated tools, and hardware configurations. Developing, assembling, vali- such as objectiF and in-Step from MicroTool and Paradigm dating, and evolving all this middleware manually is costly, Plus, VISION,andCOOL from Computer Associates. This time-consuming, tedious, and error-prone, particularly for run- class of products has evolved over the past two decades to alle- time platform variations and complex application use-cases. viate complexities associated with developing software for en- This problem is getting worse as more middleware, target terprise applications. Their successes have added the Model- platforms, and complex enterprise applications continue to Integrated Computing paradigm to the familiar programming emerge. languages and language processing tool offerings used by pre- Lack of sophisticated modeling tools. Previous efforts at vious generations of software developers. Popular examples model-based development and code synthesis attempted by of MIC being used today include the Generic Modeling Envi- CASE tools generally failed to deliver on their potential for ronment (GME) [7] and Ptolemy [8] (which are used primarily the following reasons [10]:

in the real-time and embedded domain) and UML/XML tools They attempted to generate entire applications, including based on the OMG Model Driven Architecture (MDA) [9] the infrastructure and the application logic, which often (used primarily in the business domain thus far). lead to inefﬁcient, bloated code that was hard to optimize, As shown in Figure 1, MIC uses a set of tools to analyze the validate, evolve, or integrate with legacy code.

interdependent features of the system captured in a model and Due to the lack of sophisticated domain-speciﬁc lan- determine the feasibility of supporting different QoS require- guages and associated modeling tools, it was hard to

3 Integrated System State/Country Chicago San Jose Point-of-Sale Model Constraints Data IT Department Processing Center Centers Market Model Analysis Interpreter & Integrate & Executable Central Team Code Generate specifications Data Synthesizer Store 1 Client Component Component Middleware Bus Select Assembly/ Repository Platform Component Components Code Repository Generator Compose 2 Deploy Online synthesize & Component assemble Ordering Assembly Server Middleware System Development specific Component Middleware Assembly Specific Code Business Deployment Logic & Configuration 4 Figure 2: Combining Model-Integrated Computing and Metadata Component Middleware Order Deployment Processing ASP & Component Component achieve round-trip engineering, i.e., moving back and Configuration Mechanism 3 forth seamlessly between model representations and the Containers Containers synthesized code. Middleware Middleware Framework Since CASE tools and modeling languages dealt primar- Configuration Metadata 5 ily with a restricted set of platforms (such as mainframes) Application Server 6 and legacy programming languages (such as COBOL) they did not adapt well to the distributed computing 1 Configuring and deploying an application services end-to-end paradigm that arose from advances in PC and Internet 2 Composing components into application server components technology and newer object-oriented programming languages, such as Java, C++, and C#. 3 Configuring application component containers 4 Synthesizing application component implementations The limitations with Model-Integrated Computing and component middleware outlined above can largely be overcome by 5 Synthesizing middleware-specific configurations integrating them as follows: 6 Synthesizing middleware implementations

Combining MIC with component middleware helps to overcome problems with earlier-generation CASE tools Figure 3: Integration Points for Model-Integrated Comput- since it does not require the modeling tools to generate ing and Component Middleware all the code. Instead, large portions of applications can be composed from reusable, prevalidated middleware com-

Combining component middleware with MIC helps to ponents, as shown in Figure 2. model the interfaces among various components in terms Combining MIC and component middleware helps ad- of standard middleware, rather than language-speciﬁc dress environments where business procedures and rules features or proprietary APIs. change at rapid pace, by synthesizing and assembling

Changes to the underlying middleware or language map- newer extended components that conform to new busi- ping for one or many of the components modeled can ness rules. be handled easily as long as they interoperate with other Combining component middleware with MIC helps to components. Interfacing with other components can be make middleware more ﬂexible and robust by automating modeled as constraints that are validated by model check- the conﬁguration of many QoS-critical aspects, such as ers. concurrency, distribution, transactions, security, and dependability. Moreover, MIC-synthesized code can help Figure 3 illustrates six points at which Model-Integrated bridge the interoperability and portability problems be- Computing can be integrated into component middleware ar- tween different middleware for which standard solutions chitectures. We describe each of these six integration points do not yet exist. below:

4 1. Conﬁguring and deploying application services end-to- Due to the number of policies and the intricate interactions end. Developing large-scale enterprise applications requires among them, it is tedious and error-prone for an application to application developers to handle a variety of conﬁguration and manually specify and maintain its component policies and se- deployment challenges, such as mantic compatibility with policies of other components. MIC

Locating the appropriate existing services tools can help automate the validation and conﬁguration of

Partitioning and distributing business processes and these container policies by allowing system designers to spec-

Provisioning the QoS required for each service that com- ify the required system properties as a set of models. Other prises an application end-to-end. MIC tools can then analyze the models and generate the nec- It is a daunting task to identify and deploy all these capabilities essary policies and ensure their consistency. into an efficient, correct, and scalable end-to-end application 4. Synthesizing application component implementations. configuration. For example, to maintain correctness and ef- Developing enterprise applications today involves program- ficiency, services may change or migrate when the business ming new components that add application-specific function- requirements change. Careful analysis is therefore required ality. Likewise, new components must be programmed to in- to partition collaborating services on distributed nodes so the teract with external information systems, such as supplier or- information can be processed efficiently, dependably, and se- dering systems, that are not internal to the application. Since curely. these components involve substantial knowledge of applica- Integrating MIC and component middleware to deploy ap- tion domain concepts, such as government regulations, busi- plication services end-to-end can help application developers ness rules, organizational structure, and legacy systems, it configure the right set of services into the right part of an ap- would be ideal if they could be developed in conjunction with plication in the right way. MIC analysis tools can help deter- end-users or business domain experts, rather than programmed mine the appropriate partitioning of functionality that should manually in isolation by software developers. be deployed into various application servers throughout a net- The shift toward high-level design languages and modeling work. For example, tools like ArcStyler, objectiF, case/4/0 and tools is creating an opportunity for increased automation in Dezign for Databases allow application developers to express generating and integrating application components. The goal their end-to-end application architecture graphically. is to bridge the gap between specification and implementation 2. Composing components into application servers. Inte- via sophisticated aspect weavers [11] and generator tools that grating MIC with component middleware provides capabilities can synthesize platform-specific code customized for specific that help application developers to compose components into application properties, such as resilience to denial of service application servers by attacks, robust behavior under heavy load, and good perfor-

Selecting a set of suitable, semantically compatible com- mance for normal load. ponents from reuse repositories. 5. Synthesizing middleware-speciﬁc conﬁgurations. The

Specifying the functionality required by new components infrastructure middleware technologies used by component to isolate the details of business systems that (1) operate middleware provide a wide range of policies and options to in environments where business processes change peri- conﬁgure and tune their behavior. For example, CORBA odically and/or (2) interface with third-party software as- ORBs often provide the following options and tuning parame- sociated with external information systems. ters:

Determining the interconnections and interactions be-

tween components in metadata. Various types of transports and protocols Packaging the selected components and metadata into an Various levels of fault tolerance

assembly that can be deployed into the application server. Middleware initialization options

CASE tools such as objectIf and ArcStyler provide visual tools Efficiency of (de)marshaling event parameters for composing application servers. Efficiency of demultiplexing incoming method calls 3. Configuring application component containers. Appli- Threading models and thread priority settings and cation components use containers to interact with the applica-

Buffer sizes, flow control, and buffer overflow handling tion servers in which they are configured. Containers provide many policies that enterprise applications can use to fine-tune Certain combinations of the options provided by the middle- underlying component middleware behavior, such as its secu- ware may be semantically incompatible when used to achieve rity, transactional, and quality of service properties. Since en- multiple QoS properties. terprise applications consist of many interacting components, Advanced meta-programming techniques, such as reflec- their containers must be configured with consistent and com- tion [12] and aspect-oriented programming [11], are being de- patible policies. veloped to configure middleware options so they can be tai- lored for particular use cases.

5 6. Synthesizing middleware implementations. Model- We are developing a MIC toolsuite called CoSMIC Integrated Computing can also be integrated with component (deuce.doc.wustl.edu/CoSMIC), which extends the middleware by using MIC tools to generate custom middle- popular GME modeling and synthesis tools [7] to support the ware implementations. This is a more aggressive use of mod- development, assembly, and deployment of QoS-enabled en- eling and synthesis than integration point 5 described above terprise applications using component middleware. To ensure since it affects middleware implementations, rather than their these QoS requirements can be realized in the middleware conﬁgurations. Application integrators could use these ca- layer, we are also developing a QoS-aware CCM implemen- pabilities to generate highly customized implementations of tation called CIAO. CIAO allows MIC tools to specify these component middleware so that QoS requirements of components in the accompanying metadata.

It only includes the features actually needed for a particular application and

It is carefully fine-tuned to the characteristics of particu- References lar programming languages, operating systems, and net- [1] Janos Sztipanovits and Gabor Karsai, “Model-Integrated works. Computing,” IEEE Computer, vol. 30, no. 4, pp. 110–112, Apr. 1997. [2] Richard E. Schantz and Douglas C. Schmidt, “Middleware for Distributed Systems: Evolving the Common Structure for 5 Concluding Remarks Network-centric Applications,” in Encyclopedia of Software Engineering, John Marciniak and George Telecki, Eds. Wiley Due to tight coupling between software modules, conventional & Sons, New York, 2002. methods for building enterprise applications increase the time [3] Object Management Group, The Common Object Request and effort required to develop and evolve the software. More- Broker: Architecture and Specification, Revision 2.6, Dec. over, many application quality aspects, such as persistent data 2001. store, security, and management of run-time resources, cut [4] Nanbor Wang, Douglas C. Schmidt, and Carlos O’Ryan, “An Overview of the CORBA Component Model,” in across multiple layers, which also tightly couples application Component-Based Software Engineering, George Heineman software modules with the middleware infrastructure and its and Bill Councill, Eds. Addison-Wesley, Reading, associated housekeeping tasks. These tight couplings yield Massachusetts, 2000. brittle enterprise applications that are hard to reuse, maintain, [5] George T. Heineman and Bill T. Councill, Component-Based Software Engineering: Putting the Pieces Together, and evolve. Addison-Wesley, Reading, Massachusetts, 2001. Component middleware has emerged as a promising so- [6] Object Management Group, CORBA 3.0 New Components lution to many limitations with object-oriented application Chapters, OMG TC Document ptc/2001-11-03 edition, Nov. frameworks. This type of middleware consists of reusable 2001. software artifacts that can be distributed or collocated through- [7] Akos Ledeczi, Arpad Bakay, Miklos Maroti, Peter Volgysei, out a network. A proliferation of component middleware tech- Greg Nordstrom, Jonathan Sprinkle, and Gabor Karsai, “Composing Domain-Specific Design Environments,” IEEE nologies have emerged recently to address various require- Computer, pp. 44–51, Nov. 2001. ments of enterprise applications. These types of applications [8] J. T. Buck, S. Ha, E. A. Lee, and D. G. Messerschmitt, are increasingly being assembled from components belong- “Ptolemy: A Framework for Simulating and Prototyping ing to disparate middleware technologies, which increases the Heterogeneous Systems,” International Journal of Computer effort required to integrate and deploy semantically compati- Simulation, Special Issue on Simulation Software Development Component Development Strategies, vol. 4, Apr. 1994. ble and interoperable components across multiple middleware [9] Object Management Group, Model Driven Architecture platforms. Moreover, enterprise applications must increas- (MDA), OMG Document ormsc/2001-07-01 edition, July 2001. ingly support multiple simultaneous QoS properties, such as [10] Paul Allen, “Model Driven Architecture,” Component dependability, security, and scalability. Development Strategies, vol. 12, no. 1, Jan. 2002. This paper describes a solution to these problems that in- [11] Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris volves combining Model-Integrated Computing (MIC) with Maeda, Cristina Videira Lopes, Jean-Marc Loingtier, and John component middleware. This combination is important be- Irwin, “Aspect-Oriented Programming,” in Proceedings of the 11th European Conference on Object-Oriented Programming, cause it does not require the modeling tools to generate all June 1997. the code. Instead, large portions of applications can be [12] F. Kon, M. Roman, P. Liu, J. Mao, T Yamane, L. Magalhaes, reused and/or customized from existing middleware compo- and R. Campbell, “Monitoring, Security, and Dynamic nents. These middleware components handle many critical Configuration with the dynamicTAO Reflective ORB,” in Proceedings of the Middleware 2000 Conference.ACM/IFIP, QoS aspects, such as concurrency, distribution, transactions, Apr. 2000. security, and dependability.