J-Integra® for .NET is a bi-directional bridge. On the surface, this means that it can act as a client or server (or both at the same time with callbacks/events). The implications however run much deeper, as there are so many different scenarios. Along with the fact that .NET Remoting has successfully de-coupled the transport protocol (TCP or HTTP) from the message payload format (binary), deploying J-Integra® for .NET in a .NET environment can lead to confusion. Follow the examples in conjunction with this section to hopefully make deployment scenarios much clearer.
Every deployment that involves J-Integra® for .NET can be categorized in just four scenarios, and they will be explained in detail:
J-Integra® for .NET can access .NET remoting components using HTTP, but only when they are hosted in IIS. The following diagram illustrates this.
Included example: Access .NET Hosted on IIS from Java.
J-Integra® for .NET can access standalone .NET remoting components using TCP. The following diagram illustrates this:
Included example: Access .NET from Java Using J-Integra® for .NET.
Access to Java components from .NET over HTTP is achieved through Java Servlet technology. Therefore, the Java components must be hosted in a J2EE-based Application Server. The following diagram illustrates this:
Included example: Access Enterprise Java Beans in WebLogic 6.1 from .NET Using J-Integra® for .NET.
Standalone Java components can be access from .NET using TCP. The following diagram illustrates this:
Included example: Access Java from .NET Using J-Integra® for .NET.
|
© 2007 Intrinsyc Software International, Inc. All rights reserved. Legal |