acm-header
Sign In

Communications of the ACM

Developing and integrating enterprise components and services

Applying Model-Integrated Computing to Component Middleware and Enterprise Applications



  • Horizontal infrastructure services, such as request brokers;
  • Vertical models of domain concepts, such as common semantics for higher-level reusable component services; and
  • Connector mechanisms between components, such as remote method invocations or message passing.

Examples of COTS component middleware include the Common Object Request Broker Architecture (CORBA) (www.omg.org), Java 2 Enterprise Edition (J2EE) (java.sun.com/j2ee), and emerging Web Services middleware, such as .NET (www.microsoft.com/net/ default.asp) and ONE (wwws.sun.com/software/ sunone/index.html), based on XML (www.w3c.org/ XML) and SOAP (www.w3c.org/2000/xp/Group). Despite advances in the ubiquity and quality of component middleware, however, developers of enterprise applications still face the challenges described here.

Proliferation of Middleware Technologies. Large-scale, long-lived enterprise applications require component middleware platforms to work with heterogeneous platforms and languages, interface with legacy code written in different languages, and interoperate with multiple technologies from many suppliers. However, COTS component middleware technologies do not yet provide complete end-to-end solutions that support enterprise application development in diverse environments.

Satisfying Multiple Quality-of-Service Requirements Simultaneously. An increasing number of enterprise applications, such as high-volume e-commerce systems and automated stock-trading systems, have stringent quality-of-service (QoS) demands, such as efficiency, scalability, dependability, and security, that must be satisfied simultaneously and that cross-cut multiple layers and require end-to-end enforcement. Conventional implementations of component middleware cannot enforce complex QoS requirements of enterprise applications effectively, however, since they were designed for applications with less-stringent requirements.

Accidental Complexities in Assembling Components. To reduce life cycle costs and time-to-market, application developers are attempting to assemble and deploy enterprise applications by selecting the right set of compatible COTS components, which in itself is a daunting task. The problem is further exacerbated by the existence of myriad strategies for configuring and deploying the underlying component middleware. Application developers therefore spend non-trivial amounts of time debugging problems associated with the selection of incompatible strategies and components.

A promising way to address the preceding challenges is to apply Model-Integrated Computing (MIC) technologies [11]. MIC is a paradigm for expressing application functionality and QoS requirements at higher levels of abstraction than is possible with programming languages such as Visual Basic, Java, C++, or C#. In the context of enterprise applications, MIC tools can be applied to analyze different—but interdependent—characteristics of system behavior, such as scalability, safety, and security. Tool-specific model interpreters translate the information specified by models into the input format expected by analysis tools. These tools check whether the requested behavior and properties are feasible given the constraints.

MIC tools can also be used to synthesize platform-specific code customized for specific component middleware and enterprise application properties, such as isolation levels of a transaction, recovery strategies to handle various runtime failures, and authentication and authorization strategies modeled at a higher level of abstraction. Understanding how to integrate MIC and component middleware is essential to resolve the configuration, management, and deployment challenges of enterprise applications that have been described.




  • They attempted to generate entire applications, including the infrastructure and the application logic, which often led to inefficient, bloated code that was difficult to optimize, validate, evolve, or integrate with legacy code.
  • Due to the lack of sophisticated domain-specific languages and associated modeling tools, it was difficult to achieve round-trip engineering (moving back and forth seamlessly between model representations and the synthesized code).
  • Since CASE tools and modeling languages dealt primarily with a restricted set of platforms (such as mainframes) and legacy programming languages (such as COBOL), they did not adapt well to the distributed computing paradigm that arose from advances in PC and Internet technology, as well as newer OO programming languages, such as Java, C++, and C#.

The preceding limitations of MIC and component middleware can be overcome by integrating them as follows:

  • Combining MIC with component middleware helps to overcome problems with earlier-generation CASE tools since it does not require the modeling tools to generate all the code. Instead, large portions of applications can be composed from reusable, prevalidated middleware components, as shown in Figure 2.
  • Combining MIC and component middleware helps address environments where business procedures and rules change at a rapid pace, by synthesizing and assembling newer extended components that conform to new business rules.
  • Combining component middleware with MIC helps to make middleware more flexible and robust by automating the configuration of many QoS-critical aspects, such as concurrency, distribution, transactions, security, and dependability. Moreover, MIC-synthesized code can help bridge the interoperability and portability problems between different middleware for which standard solutions do not yet exist.
  • Combining component middleware with MIC helps to model the interfaces among components in terms of standard middleware, rather than language-specific features or proprietary APIs.
  • Changes to the underlying middleware or language mapping for one or many of the components modeled can be handled easily as long as they interoperate with other components. Interfacing with other components can be modeled as constraints that are validated by model checkers.

Figure 3 illustrates six points at which MIC can be integrated into component middleware architectures. We describe each of these six integration points here; numbers correspond to the numbered areas in Figure 3.

1. Configuring and deploying application services end-to-end. Developing large-scale enterprise applications requires application developers to handle a variety of configuration and deployment challenges. These are: locating the appropriate existing services; partitioning and distributing business processes; and provisioning the QoS required for each service that comprises an application end-to-end.

It is a daunting task to identify and deploy all these capabilities into an efficient, correct, and scalable end-to-end application configuration. For example, to maintain correctness and efficiency, services may change or migrate when the business requirements change. Careful analysis is therefore required to partition collaborating services on distributed nodes so the information can be processed efficiently, dependably, and securely.

Integrating MIC and component middleware to deploy application services end-to-end can help application developers configure the right set of services into the right part of an application in the correct way. MIC analysis tools can help determine the appropriate partitioning of functionality that should be deployed into various application servers throughout a network. For example, tools like ArcStyler, objectiF, case/4/0, and Dezign for Databases allow application developers to express their end-to-end application architecture graphically.

2. Composing components into application servers. Integrating MIC with component middleware provides capabilities that help application developers to compose components into application servers by:

  • Selecting a set of suitable, semantically compatible components from reuse repositories.
  • Specifying the functionality required by new components to isolate the details of business systems that operate in environments where business processes change periodically and/or interface with third-party software associated with external information systems.
  • Determining the interconnections and interactions between components in metadata.
  • Packaging the selected components and metadata into an assembly that can be deployed into the application server.

CASE tools such as objectIf and ArcStyler provide visual tools for composing application servers.

3. Configuring application component containers. Application components use containers to interact with the application servers in which they are configured. Containers provide many policies that enterprise applications can use to fine-tune underlying component middleware behavior, such as its security, transactional, and QoS. Since enterprise applications consist of many interacting components, their containers must be configured with consistent and compatible policies.

Due to the number of policies and the intricate interactions among them, it is tedious and error-prone for an application to manually specify and maintain its component policies and semantic compatibility with policies of other components. MIC tools can help automate the validation and configuration of these container policies by allowing system designers to specify the required system properties as a set of models. Other MIC tools can then analyze the models and generate the necessary policies and ensure their consistency.

4. Synthesizing application component implementations. Developing enterprise applications today involves programming new components that add application-specific functionality. Likewise, new components must be programmed to interact with external information systems, such as supplier-ordering systems that are not internal to the application. Since these components involve substantial knowledge of application domain concepts, such as government regulations, business rules, organizational structure, and legacy systems, it would be ideal if they could be developed in conjunction with end users or business domain experts, rather than programmed manually in isolation by software developers.

The shift toward high-level design languages and modeling tools is creating an opportunity for increased automation in generating and integrating application components. The goal is to bridge the gap between specification and implementation via sophisticated aspect weavers [4] and generator tools that can synthesize platform-specific code customized for specific application properties, such as resilience to denial-of-service attacks, robust behavior under heavy load, and good performance for normal load.

5. Synthesizing middleware-specific configurations. The infrastructure middleware technologies used by component middleware provide a wide range of policies and options to configure and tune their behavior. For example, CORBA ORBs often provide the following options and tuning parameters: various types of transports, protocols, and levels of fault tolerance; middleware initialization options; efficiency of (de)marshaling event parameters; efficiency of demultiplexing incoming method calls; threading models and thread priority settings; and buffer sizes, flow control, and buffer overflow handling.

Certain combinations of the options provided by the middleware may be semantically incompatible when used to achieve multiple QoS properties. Advanced metaprogramming techniques, such as reflection [5] and aspect-oriented programming [4], are being developed to configure middleware options so they can be tailored for particular use cases.

6. Synthesizing middleware implementations. MIC can also be integrated with component middleware by using MIC tools to generate custom middleware implementations. This is a more aggressive use of modeling and synthesis than that described in integration point 5 since it affects middleware implementations rather than their configurations. Application integrators could use these capabilities to generate highly customized implementations of component middleware so that it only includes the features actually needed for a particular application and is carefully fine-tuned to the characteristics of particular programming languages, operating systems, and networks.







 


 

No entries found