ASP.NET and Web Services

ASP.NET and web services are a perfect match. Chapter 7 places special emphasis on how .NET and ASP.NET support web services.

Both J2EE 1.4 and .NET supply APIs for accessing diverse types of repositories. For example, .NET employs ADO.NET to access SQL Server data, whereas J2EE uses JDBC for storing and retrieving data in Oracle, DB2, and other repositories. Some problems come immediately to mind when employing these approaches:

• Data storage location Proprietary solutions must provide information on data location. Support must be provided for both parties on their respective platforms.

• Performance issues Serialization of data on the submitter’s platform and deserialization of data on the recipient’s end are problematic. The code must be updated on both platforms in the event either participant changes the format or protocol. Additionally, ensuring validity of data is another problem because data conversion is risky.

One of the problems facing Sun, Microsoft, and third-party vendors is the lack of a consistent industry-wide standard for multi-tiered, distributed software development.

Participating business members must agree on a common set of methods and a specified protocol before they can share processes, resources, and achieve true application integration. This scenario frequently exists when trading business partners use legacy systems dissimilar in methodology and protocol. They require a customized solution. A proprietary solution may work in one context, but not be reusable in another. Proprietary solutions are too expensive to maintain. This is the case with both ODMG’s CORBA and Microsoft’s DCOM. Both technologies represent attempts to provide methods for developing protocols to facilitate interoperability between incompatible technologies and platforms. Unfortunately, they are limited to applications and components installed within their respective platform’s environment. Both technologies use tightly coupled proprietary protocols and are connection oriented, limiting their use as distributed services.

DCOM, CORBA’s counterpart, is Microsoft’s initiative to make legacy application and platform integration possible. It encounters the same problems as CORBA. Written expressly for Internet use, DCOM assumes that interacting applications on both ends are implemented as COM objects. DCOM allows an application to invoke COM components installed on different servers. Employing reusable components in a loosely coupled environment is a necessity when programming enterprise-distributed applications, something tightly coupled components do not allow. Unfortunately, clients face numerous barriers when communicating with the servers. Firewalls restrict the use of open ports, making calls in an open environment difficult.

Another problem DCOM displays is its connection-oriented architecture, thereby limiting its use as distributed services. DCOM cannot easily manage interruptions such as external calls from other clients. When a client makes calls via the Internet, it cannot control the connection. Although the connection may succeed, the next call may fail if an interruption occurs. Designing load-balanced connections between client and server is difficult. It is not possible to reroute a new request to another server. In order to maintain integrity of the currently processed transaction, the connection must be preserved. Remoting implies communication between objects existing within different application domains. This is true whether the objects reside on the same machine or exist on machines connected by a network. Recognizing the difficulties encountered using CORBA or DCOM, the developer should consider several criteria for accommodating Remote Procedure Calls:

• Interoperability Clients on other platforms must freely use a remote service.

• Strongly typed interfaces Data types transmitted to and from the client must map easily to data types defined by most procedural programming languages.

• Support for any language The implementation of a remote service should use existing Internet standards, thereby eliminating the need to reinvent the wheel. Java, Perl, C#, Visual Basic, and managed C++ must all have access to the web service.

• Support for any distributed component infrastructure Avoid tightly coupled components.