Summary kinds of technology

What is the difference between soap and CORBA, COM/DCOM?
When soap was just proposed, many people raised the question: What is the difference between soap and CORBA and DCOM?

The Common Object Request Broker Architecture (CORBA) is a standard object-oriented application system specification developed by OMG. It consists of the Object Request proxy orb, object service, public facilities, domain interfaces, and application interfaces. The core part is the object request proxy ORB (Object Request Broker ). ORB provides a mechanism through which objects can transparently send requests and receive responses. Distributed and interoperable objects can use orb to construct interoperable applications. ORB can be seen as a middleware for establishing customer/service relationships between objects. Based on ORB, the customer can transparently call the methods provided by the service object. The service object can run on the same machine as the customer, it can also run on other machines to interact with customers through the network. Orb intercepts the request sent by the customer, finds the service object implementing the request on the software bus, then completes the parameter and method call, and returns the final result. CORBA 1.1 was released in 1991 by the object management organization. The Interface Definition Language (IDL) and application programming interface (API) are defined to activate the interaction between the client and server by implementing the Object Request proxy (ORB. In 2.0, CORBA was released to define how to communicate across different orb providers.

COM/DCOM (Component Object Model/Distributed Component Object Model) is a Distributed Component Object Model standard proposed by Microsoft. It supports communication between objects of different computers on the LAN, Wan, or even the Internet. DCOM processes low-level details of network protocols based on COM applications, components, and tools, without having to worry too much about network protocol details, this allows you to focus on solving the problems required by users. DCOM is located between the components of the application, and the components are glued together in an invisible way to form an application with complete functions.

1. Comparison between soap and CORBA, DCOM/COM.

3. 3.1 first, it is pointed out that soap will not replace CORBA, COM/DCOM. The three concepts are different. COM/DCOM is a component model standard, while CORBA is a service standard for distributed applications. CORBA and DCOM create services for distributed applications and use service objects to execute services called by clients. Soap is a communication protocol for Distributed Objects Based on XML and HTTP, and a protocol for communication between COM/DCOM and CORBA objects. In fact, the use of soap interoperability and powerful implementation capabilities of CORBA can be well combined. OMG (Object Management Group responsible for the CORBA specification) is paying attention to this development.

   3.2. The applications of CORBA and DCOM cannot implement interoperability, and the two cannot collaborate together. Because in the orpc (Object RPC) protocol, objref represents a reference to a running object. In the CORBA/IIOP (Internet Inter-ORB Protocol, interoperable object reference (IOR) represents the object reference of a server. Unfortunately, IOR and objref cannot be associated. However, the use of soap can achieve horizontal integration of the DCOM technology on the vertical application layer, which can better integrate the CORBA and DCOM as a whole.

   3.3 soap does not define information semantics, service quality, and Internet-based transaction processing. The message is encoded in XML. Correct Processing requires the server and the client to execute and understand and execute the information formats used by each other (one-to-one, request/reply, broadcast, applications play a very important role in semantic parsing. In contrast, CORBA and DCOM represent the semantics of transmitted information, and binary encoding is used for parameters and return values. No metadata such as parameter names or types can be encoded, but it makes it difficult for the mediation to process messages. Because each system uses different binary codes, it is difficult to implement inter-system interoperability.

   3.4 although CORBA can be executed on different platforms and DCOM can run on various Microsoft platforms, the solution based on CORBA and DCOM must rely on a single application. For example, if you run a DCOM server program, all distributed clients have to run on Microsoft's operating platform. Although CORBA can run on different platforms, its interoperability is not extended on higher-level services, such as security and transaction processing. In this case, many provided services are not well optimized. DCOM and CORBA are suitable for communication between servers, but they are very vulnerable to communication between clients and servers, especially when client programs are distributed over the Internet.

   3.5 unlike DCOM, soap tries to define all elements of a distributed system. Soap does not provide distributed class libraries, type security checks, version control, and so on. Soap is at a lower level than DCOM, similar to the role of IIOP in CORBA, DCOM provides some additional protocol functions, which are not available in IIOP or soap. However, many additional. DCOM functions are used only for server-to-server communication, while client-to-server communication is redundant.

Bytes ----------------------------------------------------------------------------------------------------------------
Introduction to Service Data Objects

SDO and WDO
Web Data Objects (or WDO) are the names of SDO earlier versions released with IBM WebSphere Application Server 5.1 and IBM WebSphere Studio Application Developer 5.1.2. If you have used WebSphere Studio 5.1.2, you may have some knowledge about SDO, although you may be used to marking it as WDO, for example, in the database name. Forget WDO. Its current name is SDO!

SDO and JDO
JDO stands for Java Data Object (Java data object ). JDO has standardized version 1.0 through the Java Community process (JCP). In May 2003, it launched the maintenance version 1.0.1, and now it has set up a JCP Expert Group for version 2.0. JDO provides a common API for data programming in the Java environment to access data stored in different data sources, such as databases, file systems, or transaction processing systems. JDO maintains the relationship between Java objects (graphs) and allows concurrent access to data.

JDO wants to simplify and unify Java data programming so that developers can focus on business logic, rather than the underlying technology. In this regard, JDO has the same goal as SDO. However, the main difference is that JDO only considers persistence issues (J2EE data layer or Enterprise Information System (EIS) layer), while SDO is more general, focus on the representation of data streams between different J2EE layers, such as the presentation layer and business layer.

Interestingly, SDO can be used together with JDO. JDO can be used as a data source and SDO can access it. This is the specific application of the data transfer object (data transmission object, DTO) design pattern. Similarly, SDO can be used in combination with the solid EJB component and Java Connector Architecture (JCA) to provide unified data access.

SDO and EMF
EMF stands for eclipse modeling framework (eclipse modeling framework ). EMF generates a unified metadata model (ecore) based on data models defined using Java interfaces, XML schema, or UML class diagrams. It can be used together with the Framework, create high-quality model implementations. EMF provides persistence, an effective reflection object control API, and a change notification framework. EMF also includes general reuse classes used to build the EMF model editor.

Both EMF and SDO can process data representation. In fact, IBM's SDO reference implementation is an EMF Implementation of SDO, which will be used later. You can also use EMF code to create some SDO implementation parts based on the UML model definition or SDO itself. SDO implementation is basically a small layer (aspect) in EMF, Which is packaged and provided as part of the EMF project. For more information about EMF, see references.

SDO and jaxb
Jaxb stands for Java API for XML data binding (binding XML data to Java API ). Jaxb 1.0 was released by JCP in January 2003. The JCP Expert Group has prepared a preliminary draft of version 2.0. Jaxb is about binding XML data. That is to say, XML data is represented as a Java object in memory. As a Java XML binding framework, jaxb can save time for parsing and creating XML documents. (In fact, you do not need to deal with XML at all .) Jaxb executes grouping/serialization (Java to XML) and grouping/parallelization (XML to Java) for you ).

SDO defines its own Java binding framework, but it is far away. Jaxb only focuses on binding Java to XML, and binding to SDO is not just about XML data. As mentioned above, SDO provides unified access to different types of data. XML is only one of the data types. SDO also provides static and dynamic APIs *, while jaxb only provides static bindings.

*Note that the sample application in this article only uses dynamic SDO, although the EMF code generator also provides complete support for static code generation of data objects.

SDO and ADO. net
Ado stands for ActiveX Data Objects (ActiveX Data Object), but its meaning has changed in the. NET context. ADO. NET provides a unified data access mechanism between different levels under the. NET Framework.

ADO. NET and SDO share the same motivation and are used to support XML and applications distributed across multiple layers. Apart from technical differences, the two technologies are mainly different: ADO. net for Microsoft. NET platform is a proprietary technology, while SDO is used for Java (J2EE) platforms to standardize through Java Community processes.

Components of SDO
This section describes the architecture of SDO. We will introduce the collaboration between different components of the Composition Framework and them. One of the three components to be discussed is the "conceptual" feature of SDO, and there is no corresponding interface in the API.

SDO Client
The SDO client uses the SDO framework to process data. SDO clients use SDO programming models and APIs instead of technical APIs and frameworks. The SDO client processes the SDO Data graph (see figure 1). You do not need to know how the processed data is permanently saved or serialized.

Data intermediary service
DMS is responsible for creating data graphs from data sources and updating data sources based on changes in data graphs. The data mediation framework does not belong to the SDO 1.0 specification. In other words, SDO 1.0 does not involve the specific DMS. Common DMS types include jdbc dms, entity ejb dms, and xml dms.