Middleware communication support of .NET

Communication between different applications and processes is a necessity for sharing resources, Business logics and data. Networking solutions enabled PCs to be able to communicate with each other and share resources such as printers and disks, applications needed to be able to send and receive data and coordinate their actions with other applications running at the same time on other computers. Many common inter-process communications mechanisms were available, such as named pipes and sockets. These mechanisms were very low-level and using them required a good understanding of how networks work. But for rapid development we have to rely on the available frameworks that have stable, scalable and secured design and already tested under various scenarios.

History

Microsoft originally designed COM to enable communications between components and applications running on the same computer. COM was followed by DCOM (distributed COM), enabling applications to access components running on other computers over a network. DCOM was itself followed by COM+. COM+ incorporated features such as integration with Microsoft Transaction Server, enabling applications to group operations on components together into transactions so that the results of these operations could either be made permanent (committed) if they were all successful, or automatically undone (rolled back) if some sort of error occurred. COM+ provided additional capabilities, such as automatic resource management and asynchronous operations. COM+ was followed in turn by the .NET Framework, which further extended the features available and renamed the technology as Enterprise Services. The .NET Framework also provided several new technologies for building networked components. One example wasRemoting, which enabled a client application to access a remote object hosted by a remote server application as though it was running locally, inside the client application.

Technologies such as COM, DCOM, COM+, Enterprise Services, and .NET Framework Remoting all work well when applications and components are running within the same local area network inside an organization. They are also specific to the Microsoft Windows family of operating systems.

The World Wide Web provides an infrastructure that enables developers to build applications that can combine components and other elements located almost anywhere in the world, running on computers of varying architectures, and executing using a bewildering array of operating systems (not just Windows). To support cross platform application communication Microsoft comes with Web services. A Web service is an application or component that executes on the computer hosting it (server) rather than the user’s computer (client). A Web service can receive requests from applications running on client machine, perform operations on the server and send a response back to the client. A Web service can also invoke operations in other Web services, hosted elsewhere on the Internet. These are global, distributed applications. To establish Web services as a global mechanism for building distributed applications, developers had to agree on several points, including a common format for data, a protocol for sending and receiving requests, and handling security. All of these features had to be independent of the platform being used to create and host Web services. XML and XML schemas is chosen as a data format that enables Web services and users’ (or client) applications to communicate in an unambiguous manner.

Incorporating security and privacy into a Web service and client application can be a non-trivial task. To make life easier for developers building Web services using the Microsoft .NET Framework, Microsoft introduced the Web Services Enhancements (WSE) package.