Ice topic: Comparison of network service platforms

Comparison of network service platforms-one of the ice application Series

 

Since the 1990s S, the computing industry has been using object-oriented middleware platforms such as DCOM and CORBA. In the process that enables distributed computing to be used by application developers, object-oriented middleware is an important step. For the first time, developers have the possibility that they can build distributed applications without having to be a network guru. The middleware platform will take care of most network chores, such as reorganizing aling) unmarshaling (encoding and decoding of data for transmission), map the logical object address to the physical transmission endpoint, change the data representation based on the native machine architecture of the customer and server, and automatically start the server as needed. However, for some reason, both DCOM and CORBA fail to successfully occupy most of the computing market:

• DCOM is Microsoft's exclusive solution. In a heterogeneous network, various machines run multiple operating systems and cannot use DCOM.

• DCOM cannot support a large number of objects (hundreds of thousands or millions), which is largely due to the overhead of its distributed garbage collection mechanism.

• Despite the fact that many vendors provide the CORBA product, it is almost impossible to find a vendor that can provide implementation for all environments in a heterogeneous network. Despite a large amount of standardization work, the lack of interoperability between different CORBA implementations has continuously caused various problems. In addition, suppliers often define extensions by themselves, the lack of multi-threaded environment specifications for CORBA has never been fully implemented for languages like C or C ++. • Both DCOM and CORBA are too complex. Familiarity with DCOM or CORBA and corresponding design and programming are a difficult task that takes many months to master (it takes several years to reach the expert level)

• In their respective history, performance problems have been plagued by these two platforms. DCOM is only available, so it is impossible to purchase a better performance. Despite the fact that many vendors provide CORBA products, it is difficult to find implementation that complies with standards and has good performance. The main reason is the complexity of the CORBA specifications (in many cases, its features are enriched beyond the need)

• In a heterogeneous environment, it is never easy to make DCOM and CORBA coexist: Although vendors provide interoperability products, the interoperability between the two platforms has never been seamless, moreover, it is difficult to manage, resulting in isolated technical islands.

In 2002, the Microsoft. NET platform [11] Replaced DCOM. However, although. NET provides more powerful distributed computing support than DCOM, it is still Microsoft's exclusive solution and thus not a choice in heterogeneous environments. On the other hand, CORBA has stagnated in recent years. Many vendors have left the market and left consumers with platforms that are no longer widely supported. The interest of a few vendors in further standardization has declined, as a result, many defects in the CORBA specification cannot be solved, or they are resolved after being reported for many years. As DCOM and CORBA decline, the distributed computing community has a strong interest in soap [23] And WebServices [24. The idea of using ubiquitous WWW infrastructure and HTTP to develop middleware platforms is fascinating-at least theoretically. Soap and WebServices have promised to become common distributed computing languages on the Internet. However, despite the huge public effect, many papers have been published, but web services has not been able to fulfill its promise: while writing this book, there are very few commercial systems developed using the Web Services architecture. The reason is:

• In terms of network bandwidth and CPU overhead, soap will cause severe performance deterioration to applications, so that this technology cannot be applied to many systems with demanding performance requirements.

• Although soap provides the "on-the-wire" Specification, it is still not enough to develop practical applications because the abstraction level provided by the specification is too low. Applications can splice various soap messages together, but this is extremely tedious and error-prone.

• Lack of more advanced abstraction promotes suppliers to provide various application development platforms to automate soap-compliant application development. However, except for the protocol level, these development platforms are not standardized and are inevitably private. Therefore, applications developed by one vendor cannot be used with middleware Products of other vendors.

• There are some serious concerns about the architecture security of soap and Web services. In particular, many experts have said they are concerned about the platform's lack of internal security.

• Web Services is a technology that is still in its infancy. So far, there have been very few standards, and it seems that it will take several years for the standardization level to reach the level of completeness required by source code compatibility and cross-vendor interoperability. As a result, developers who want to use the middleware platform are faced with some unpleasant choices:

•. Net remoting

The most serious disadvantage is that non-Microsoft platforms are not supported. [Mono, but...]

• CORBA

The most serious disadvantage is the aging platform, high complexity, and ongoing supplier friction.

• Web Services

The most serious drawback is serious inefficiency. Private development platforms must be used and security issues still exist.

These options seem likely to cause you to fail: You can choose only in Microsoft Architecture

Choose a complex, abandoned platform, or choose inefficient, due to lack

Lack of standardized private platforms.

From: http://blog.chinaunix.net/u/20057/showart_121992.h...