ScopeWhile Web services provide a very powerful technology for enterprise application integration, they are not suitable for all applications and interoperability scenarios. Both the .NET Framework and Java offer implementations of Web services, with varying degrees of integration into the underlying platform. Because SOAP is text-based, Web service calls might be too slow for applications that require frequent, fast, and fine-grained communications. Service-oriented interfaces such as Web services are also unsuited for conventional object-oriented models. Although a service can be thought of as a single, persistent server-activated object, client-activated objects such as ones that the new operator constructs and access requests to static methods are not generally supported. Similarly, if an application needs to access a wide variety of objects and classes or link to a rich object-oriented set of Java APIs from the .NET Framework, Web services are probably not the solution. In addition to the preceding issues, Web services do not support callbacks in the same manner as local object-oriented architectures. In such cases, an alternative solution is required that enables interoperability between .NET Framework applications and Java applications with .NET Remoting as the underlying connecting protocol. Developers familiar with Java EE technology may wish to view .NET Remoting as a .NET parallel to Remote Method Invocation (RMI) and Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP). The problem is that .NET Remoting can normally only be used in a homogeneous (.NET) environment. To achieve interoperability using .NET Remoting, you can use J-Integra for .NET (also known as Ja.NET) that allows .NET applications to access existing Java/Java EE applications as though they were actually .NET. Ja.NET is part of Intrinsyc Software's J-Integra Interoperability Suite. It is a runtime bridging product that exposes Java objects and methods in a way that enables the user to address them with .NET Remoting and vice versa. Ja.NET differs from a number of other Java/.NET Remoting bridging products in that it is bi-directional. Thus, as well as enabling Java server side objects to be accessed from .NET clients, it can also be used to access .NET servers from Java. SolutionJa.NET provides a two-way implementation of the .NET Remoting stack for Java. It comprises a Java runtime component and a development toolset used to generate proxies and to configure the runtime. Using Ja.NET, a set of C# proxies can be generated to access Java from .NET. Similarly because Ja.NET is a bi-directional bridge, Java proxies that expose or consume .NET Common Language Runtime (CLR) components using the .NET Remoting protocol can be generated. The main components of Ja.NET are
Accessing an EJB from .NET FrameworkAccessing an EJB from a .NET client is achieved as follows:
Figure 5-7. Generation of .NET proxies for EJB
Figure 5-8. Generation of Web Application ArchiveFigure 5-9. Deployment for accessing Java EJB from .NET CLR clientAccessing a .NET Component from JavaJa.NET can also be used to enable Java clients to access .NET CLR components as follows:
Channels and Formatters (Messaging and Object Serialization)The .NET Remoting Framework supports the use of interchangeable formatters and channels. Channels are used to transport messages to and from remote objects. Formatters are used to serialize the data to be transmitted in a particular format. Currently SOAP and binary formats are supported over either HTTP or TCP channels. Using these channels and formats, Ja.NET is wire-line compatible with the .NET Remoting Framework, which is why there is no need to deploy any Ja.NET runtime components on the .NET side. The HTTP channel is used when, as in the EJB case, the server-side component is accessed via a Java EE/Web server. Developers can choose to either use the internal Web server that is shipped with Ja.NET to host their Java server components or use a WAR file to deploy them in any other Java EE application server/Web server that supports servlets. Alternatively, for standalone hosting of Java classes, the TCP server that is part of the Ja.NET runtime can be used to access them via a TCP channel. The stream of messages flows when a .NET client invokes a method on a Java server-side object, as illustrated in Figure 5-13. The .NET client invocation goes through the proxy object (generated by the GenNet tool) to the .NET Remoting Framework, where it is serialized using the configured formatter (binary or SOAP) and sent to the configured URL using the specified channel (HTTP or TCP). Figure 5-13. Message flow for invocation of Java component method from .NET CLR clientOn the Java side, the incoming message is received by the Ja.NET runtime (either via the Web server and Ja.NET servlet in the case of HTTP or via the Ja.NET TCP server). The message is deserialized using the appropriate Formatter (binary or SOAP) and dispatched by the marshaler to the appropriate Object Ref instance, which invokes the method on the actual Java object. The response message flows back in the opposite direction for serialization and transmission to the .NET Framework. Refer to Figure 5-13. Object Lifetime ManagementKnowing when to destroy an object that is referenced remotely is always a problem for distributed technologies. COM used reference counting to solve the distributed garbage collection problem. .NET Remoting uses leasing. With leasing, a remote object remains available for a configurable period of time before being destroyed. Leases may also be configured to be extended when the object is accessed, and additionally sponsors may be configured to be responsible for renewing leases before they expire. Because Ja.NET adheres to the .NET Remoting standard, the Ja.NET runtime contains a Lease Manager for administering leases so that Java objects instantiated by .NET clients follow the same leasing mechanism. ScalabilityWhen using HTTP, Ja.NET is entirely compatible with the use of Web servers/Java EE application servers to achieve deployment scalability. For TCP-based deployments, Ja.NET gives developers and administrators the ability to manage resource usage through configuration of TCP server parameters, such as the thread pool size and the maximum request queue size. Ja.NET also provides a connection pooling mechanism to improve performance and optimize resource usage. SecurityJa.NET leverages standard mechanisms for securing channels and authenticating clients. HTTPS may be used when accessing components via a Web server. Also the desired authentication method can be selected to specify how the client authenticates itself to a Web server when trying to access remote objects. HTTP Basic or Digest authentication methods may be usedor "Best," which causes the most secure method supported by the server to be automatically selected. Ja.NET supports the SecureRemoting protocol and various standard encryption algorithms (3DES, DES, RC2, and Rijndael). TCP channels can be secured by configuring the Ja.NET runtime to use the desired encryption protocol and algorithm and deploying a .NET SecureRemoting channel provider to encrypt/decrypt the data on the .NET side. BenefitsWeb services is a technology that is specifically designed for businesses to provide services and exchange information over the Internet. While .NET Remoting is not an industry-wide standard, it does have the following advantages over Web services, which are especially relevant in an intranet environment:
Because Ja.NET uses .NET Remoting, it also has these advantages over Web services. Ja.NET is wire-line compatible with .NET Remoting and does not require any custom runtime components to be deployed on the .NET side. It supports standard Web server/.NET Remoting security mechanisms. Interoperability between .NET and Java/Java EE is achieved without the need for developers to write any custom code on either the client or server sides. Ja.NET provides tools for auto-generation of the proxy classes that are used in deployment, and developers can access existing Java components from .NET as if they were accessing them as CLR components using the standard .NET Remoting protocol. Similarly, Ja.NET allows Java clients to access existing CLR server components as if they were local Java objects. LimitationsCurrently a single type of .NET Remoting exception is returned to the client, regardless of the specific type of the underlying exception that occurred. Future releases of Ja.NET will include support for returning specific system and custom exception types. ExamplesAs an example, a financial services provider has used Ja.NET to integrate the components of an online trading system. Refer to Figure 5-14. The presentation layer runs on Windows Desktop devices and includes MS .NET GUI components that interact with other MS Office applications. These use Ja.NET to interoperate via .NET Remoting with business logic components that are hosted by Java EE application servers running on commercial Unix or Linux platforms. The application components in turn use JDBC/JMS to interact with database servers that provide persistent services. Figure 5-14. Online trading system (simplified architecture)This deployment configuration is like the one shown previously for accessing EJB components from a .NET client. The following sample code illustrates in more detail how a .NET client can access a Java server via .NET Remoting using Ja.NET. This example is based on a simplified scenario from the WS-I Supply Chain Management architecture, in which a client queries the server for a catalog of available products. The Java server comprises a Catalog class, which implements an ICatalog interface. This interface has a getProducts method, which returns an array of Product objects. The Catalog class provides an example of a PassByReference object. Refer to Listing 5-5. Listing 5-5. Sample "Pass by Object" Object
The Product class provides an example of a PassByValue object. This class implements the Serializable interface. Refer to Listing 5-6. Listing 5-6. Sample PassbyValue Object
.NET proxies for these classes are generated using the Ja.NET GenNet tool. Upon examining the generated proxies, one should notice how the byvalue class contains all its fields, and the remote byreference class is only a shell that defines the class definitions. .NET needs these for compile definitions and then again at runtime for the .NET Remoting transparentProxy class to mimic the remote server. If one attempts to create a local copy of this class, this generates an exceptiononly remote instances of this class are generated. The proxies use no custom code, just pure .NET Remoting managed code. Refer to Listing 5-7. Listing 5-7. Sample .NET Proxy
The .NET CLR client application configures .NET Remoting in the standard way using the configuration file remoting.config. This file specifies the URL of the java_server.Catalog object and the channel and formatter types to be used. For example, if the Ja.NET TCP server is used to host the java_server on the same machine using port 7562, the configuration file would contain the following application entry: <client> <wellknown url="tcp://localhost:7562" type="java_server.Catalog, JanetExample"/> </client> The client can then just instantiate and invoke methods on the Java server objects as if they were local CLR components. Refer to Listing 5-8. Listing 5-8. Sample .NET Client to Access Product Catalog Java Server
Resources
|