Continue. .
CORBA component model: Part 1, evolving to component middleware (Component MiddleWare)
The CORBA Component Model, C / C Uses Journal February 2004
Douglas C. Schmidt and Steve Vinoski
CNDEVELOPERW (YSF_GZB@21cn.net)
Continue. .
Middleware evolution
The emergence and rapid development of the Internet began in the 1970s and brought out the demand for distributed applications. However, several years ago, these applications are difficult to develop due to lack of methods, tools and platforms. Today, a variety of technologies have been more than 20 years, which are used to mitigate the complexity of developing distributed applications and supported by providing advanced software infrastructure. In the early days, milestones include Internet protocols, based on messaging architecture, microconcord architecture, and Remote Procedure Call (RPC) models based on Interactive Communication, IPC). The next generation includes an OSF distributed computing environment (DCE), IBM's MQ series, CORBA, and DCOM. Recently, middleware technology has evolved to support distributed real-time and embedded applications (such as Real-Time Corba), as well as to provide a component model (such as CCM and J2EE), web-services (such as SOAP) And model drives middleware (such as Cosmic) and other higher levels of abstraction.
The achievements of the middleware technologies discussed above have been added in the previous generation of software developers commonly used operating systems, programming languages, networks, and database products. The function and logic of the special application are separated from the intrinsic complexity inherent from the distributed infrastructure. The middleware enables application developers to focus on the feature of special applications, rather than turning into the quagmires with infrastructure struggles.
A watershed incident in the past twentieth year is the emergence of intermediate parts of the Distributed Object Computing (DOC) in the late 1990s. The DOC middleware represents the distributed computing system and the combination of object-oriented design / programming two major IT fields. The technology of developing distributed systems is committed to integrated multiple computers as a unified computing resource. Likewise, development is committed to generning complexity by creating a reusable framework and components to install the success mode and software architecture. Therefore, the DOC middleware utilizes object-oriented techniques to effectively defectively disperse the reusable services and applications.
Object Management (OMA) defines advanced DOC middleware standards for building an easy distribution program in the CORBA 2.x specification. CORBA 2.x specification focuses on interfaces, essentially, interface (interface) establishes the client and server agreed, that is, how the client observes and access the service provided by the server. Despite advanced performance, Corba 2.x standards have the following limitations: 1, lack of functional boundary. CORBA 2.x object model puts all interfaces as a convention of Client / Server. However, this object model does not provide a standard assembly mechanism to reduce the dependence performed between collaborative objects. For example, objects need to be clearly perceived and connected to other objects that they want to rely on. However, establish complex distributed applications, developers must explicitly plan the connection between the interdependence services and object interfaces, but this is some extra work - the unrealguable realization of the vulnerable. 2, lack universal application server standards. CORBA 2.x does not indicate that the General Application Server Framework is implemented to perform public server configuration management, including initialization servers and their QoS policies, public services (such as notice, or naming services), and manage the runtime environment for each component. Although Corba 2.x standardizes the interaction between object implementations and object request Agents (ORBs), server-side developers must still be determined: (1) How does the object implementation is installed in ORB; (2) ORB and object implementation How to interact. The lack of universal component server standards have a tight coupling, and the Ad-Hoc server is implemented, which increases the complexity of software upgrades and reduces the reusability and elasticity of CORBA-based applications. 3, lack of software configuration and posting standards. There is no standard method in the CORBA 2.x specification to decentralize the arrangement and start object implementation. Thus, application administrators must rely on scripts and programs to publish software implementations, configure target machines, and execution software implementations on the target machine, and then listed that the software implementation enables them to prepare the service client. However, software implementation is often modified to adapt to such an AD-HOC publishing mechanism. The maximum reuse of software with other software implementation and service interaction will make this problem more prominent in the future. Lack of higher level software management criteria leads to the system more difficult to maintain, software components are more difficult to reuse. (to be continued...)
CNDEVELOPERW (YSF_GZB@21cn.net)
