مقایسه تکنولوژی .NET از مایکروسافت با CORBA
ارسال کننده : جناب آقای محمد حسن رحیمی
سطح فعالیت : ناشر
ایمیل : mohammadhassan1384[@]gmail.com
تاریخ ارسال : ۹ تیر ۱۳۹۷
دفعات بازدید : 213
زبان نوشتاری : انگلیسی
تعداد صفحه : 12
فرمت فایل : word
حجم فایل : 148kb
Distributed computing allows different users or computers to share information. Distributed computing can allow an application on one machine to leverage processing power, memory, or storage on another machine. In many cases, a particular problem might demand distribution. If a company wishes to collect information across locations, distribution is a natural fit.
In today’s business climate, distribution of business processes is common place. A factory might be in one location, sales in another, and marketing in a third. In many cases, the computation associated with the business processes can be distributed along similar lines.
The most popular distributed object paradigms are OMG’s Common Object Request Broker Architecture (CORBA) , JavaSoft’s Java / Remote Method Invocation (Java/RMI) and Microsoft’s Distributed Component Object Model (DCOM) right now. Several months ago, Microsoft announced her new distributed framework: Microsoft .NET and claimed it would be the “next generation of Internet”. In this article, let’s examine the differences between the OMG’s CORBA and Microsoft’s .NET.
CORBA framework is designed to support the distribution of objects implemented in a variety of programming languages. This is achieved by defining an interface definition language(IDL) that can be mapped to a number of existing languages. IDL is used to define the services offered by a particular distributed object. CORBA defines a protocol –Internet Inter-ORB Protocol (IIOP) - for making requests to an object and for the object to respond to the application making the request. The IIOP protocol ensures interoperability between client applications and server based objects. These services are required by applications regardless of the exact nature of the applications. These services are defined in CORBA IDL.
Microsoft .NET framework is XML-driven server-based services that run across many
platforms and can be accessed by any client device. With its focus on interoperability
and improved "user experience," Web services will facilitate inter-company communication and make the Web more attractive to consumers. According to Microsoft, “the fundamental idea behind Microsoft .NET is that the focus is shifting from individual Web sites or devices connected to the Internet, to constellations of computers, devices and services that work together to deliver broader, richer solutions.”
Comparing CORBA and .NET
Both CORBA and .Net adopted the three-tiers architecture, which includes client side, server side and the services.
Interoperability , Security , Availability
that are used by many distributed object programs. For example, a service providing for the discovery of other available services is always necessary regardless of the application domain. In CORBA, we have Naming Service and Trading Service to fulfill this role. There are also some other Object Services, such as lifecycle management, security, transactions, and event notification, as well as many others.
- Common Facilities -- These interfaces are oriented towards end-user applications. An example of such a facility is the Distributed Document Component Facility (DDCF), a compound document Common Facility based on OpenDoc. DDCF allows for the presentation and interchange of objects based on a document model, for example, facilitating the linking of a spreadsheet object into a report document.
- Domain Interfaces -- These interfaces are oriented towards specific application domains. For example, one of the first OMG RFPs issued for Domain Interfaces is for Product Data Management (PDM) Enablers for the manufacturing domain. Other OMG RFPs will soon be issued in the telecommunications, medical, and financial domains.
- Application Interfaces -- These interfaces are developed specifically for a given application. Because they are application-specific, and because the OMG does not develop applications (only specifications), these interfaces are not standardized.