VisiBroker for .NET Developer’s Guide : Understanding the VisiBroker for .NET model

Understanding the VisiBroker for .NET model
This chapter introduces the VisiBroker for .NET components, and it describes the technologies with which VisiBroker for .NET lets your applications interoperate.
What is VisiBroker for .NET?
The VisiBroker for .NET product provides high performance connectivity between the Microsoft .NET runtime and J2EE and CORBA components. This product allows you to build managed client-side and server-side applications developed for the .NET Framework (and ASP.NET applications) that can access heterogeneous server-side components via IIOP, the highly scalable, interoperable and secure communications protocol.
Figure 1 illustrates how a deployment with VisiBroker for .NET-powered applications might look. The left and right sides of the figure show two .NET application environments, the top ones running stand-alone .NET applications, and the others running ASP.NET hosted applications. In the middle of the diagram the J2EE and CORBA server environments are shown.
The functionality provided by VisiBroker for .NET, the client stubs, server skeletons, and the VisiBroker for .NET runtime, is displayed in the shaded areas. Note that there is no shading in the J2EE and CORBA server environments, indicating that VisiBroker for .NET does not need to be deployed into the server environment in order to interoperate with the .NET environment.
Figure 1
Changes in VisiBroker for .NET
Earlier versions of VisiBroker for .NET (before version 7.0) used J# reflection to instantiate the class type. From version 7.0 onwards, VisiBroker for .NET runtime is now independent from either Microsoft J# or the SUN JDK. It is now completely in .NET MSIL. Therefore, the default access control for class default constructor may not work as before.
Important
You must explicitly declare class SampleServerLoader using the keyword "public" in order for .NET runtime to access it. If you do not do so, an exception is raised and you cannot possibly access the default constructor.
VisiBroker for .NET developer tools
Stubs and skeletons are required for VisiBroker for .NET-powered applications to invoke methods on J2EE and CORBA objects. Stubs and skeletons are interface-specific objects that provide parameter marshaling and communication for an application to invoke methods on an object that is running in a different execution environment. The VisiBroker for .NET developer tools provide you with compilers to generate the stubs and skeletons needed to communicate with your CORBA and J2EE server objects.
The J2EE-based compiler reads interfaces specified in Java Remote Method Invocation (RMI) files. The CORBA-based compiler reads interfaces specified in Interface Definition Language (IDL) files. The resulting stubs and skeletons target the .NET Common Type System (CTS), Microsoft’s language-neutral type system. Although the compilers generate stubs and skeletons in the C# programming language, once the C# stub or skeleton is compiled into the Microsoft Common Intermediate Language (CIL) by a C# compiler it is usable from any .NET-compatible language.
VisiBroker for .NET runtime
The VisiBroker for .NET runtime is a collection of libraries and network resources that integrates within end-user applications, and allows your applications to locate and use objects. The runtime exposes the basic CORBA and J2EE APIs required for using remote objects. These APIs are compliant with the Microsoft Common Language System, and are therefore accessible to any .NET programming language.
The VisiBroker for .NET runtime provides the following capabilities:
Marshaling—a high-performance, scalable engine for reading and writing IIOP packets.
Connection management—controls the allocation of TCP connections and other communication resources.
Security—encryption and authentication of messages based on the widely adopted standards: SSL, TLS, X.509, etc. (Note that this enables secure connectivity to any J2EE 1.3 compatible product.)
Objects-by-value—allows arbitrarily complex data types to be passed across client-server boundaries (for J2EE 1.3 products).
Invocation context propagation—provides the ability to augment IIOP packets with system-level data.
Portable interceptors—provides the ability to augment IIOP packets with user- or system-level data. This is particularly important for products that provide distributed transaction support based on the OTS and XA specifications. (Note that interoperable transaction support is optional in J2EE 1.3, and is therefore only provided by a subset of J2EE vendors.)
VisiBroker for .NET features
The VisiBroker for .NET product provides the following capabilities:
High Performance: VisiBroker for .NET provides binary data formatting by using IIOP for client-server networking.
Stateful services: VisiBroker for .NET provides a full distributed object model, which can support arbitrary server-side components and arbitrary life-cycle requirements.
Advanced security support: Encryption, authentication and authorization are all supported in VisiBroker for .NET, based on the latest security standards.
Support for complex data types: Using VisiBroker for .NET, data conversions are handled automatically, which is both more efficient and less error prone.
Enterprise Quality of Service: VisiBroker for .NET provides advanced QoS out of the box, including:
Load balancing: The ability to fan-out requests to a collection of service providers.
Fault tolerance: The ability to redirect requests from a failed server to an alternate provider.
Transactions: The ability to propagate two-phase-commit transaction contexts across application boundaries and start transactions on the client side.
Scalability: The ability to control the lifetime of connections, multiplex over connections, etc., for optimizing resource utilization.
What is .NET?
Microsoft .NET provides developers with a single approach to build both desktop applications and Web-based applications. It also enables developers to use the same tools and skills to develop software for a variety of systems, using a variety of programming languages, and it can minimize conflicts between applications by helping incompatible software components coexist.
The .NET Framework consists of the .NET Framework class library (FCL), for building .NET applications, and the common language runtime (CLR), for running them. The .NET Framework is available as a free download from Microsoft.
VisiBroker for .NET uses Microsoft .NET Framework version 3.0.
Common language runtime
The common language runtime (CLR) is the runtime engine in the Microsoft .NET Framework for executing applications. The CLR also provides managed applications with services such as cross-language integration, code access security, object lifetime management, and debugging and profiling support.
Programs can be written for the CLR in just about every language, including C#, C++, Microsoft Visual Basic, and JScript. The runtime simplifies programming by assisting with many mundane tasks of writing code. These tasks include memory management—which can be a big generator of bugs—security management, and error handling.
When it is compiled using a compiler in a .NET language, the code written in your programming language of choice is compiled into an assembly-like language called common intermediate language (CIL). The CIL is compiled down to executable code by the common language runtime at execution time.
.NET Framework class library
Programmers who write Windows applications are familiar with the Windows API, standard class libraries, and functions or classes of their own. The .NET Framework class library (FCL) includes prepackaged sets of functionality that developers can use to build applications that use the types, methods, and properties that target the common language runtime. Writing code using the types provided in the FCL is the surest way to have completely interoperable .NET applications.
Some of the features included in the FCL are:
.NET Remoting
Distributed applications are traditionally based on DCOM, CORBA, and Java RMI remoting technologies using binary protocols, such as IIOP, that utilize network bandwidth efficiently. In contrast, much of .NET interoperability centers on XML and SOAP.
The VisiBroker for .NET runtime provides a managed code implementation of IIOP for the .NET Framework. VisiBroker for .NET allows you, the developer, to locate and call methods on remote objects using .NET Remoting-style calls, shielding you from having to learn how to write CORBA or Java RMI-style calls. See application development examples in “Developing VisiBroker for .NET client applications” and “Developing VisiBroker for .NET Remoting servers”.
Managed vs. Unmanaged Applications
The .NET Framework supports what it calls managed and unmanaged applications. Managed applications are programs that you create using a supported .NET language, such as C#, and which adhere to various rules imposed by the Framework. All VisiBroker for .NET code is managed code.
Unmanaged applications are programs created in unsupported languages, or which do not completely adhere to .NET Framework rules. These applications, many of which are legacy applications, can still be run within a wrapper process provided by the .NET Framework.
What is J2EE?
Java 2 Platform, Enterprise Edition (J2EE) technology and its component based model simplifies enterprise development and deployment. The J2EE platform manages the infrastructure and supports the Web services to enable development of secure, robust and interoperable business applications. J2EE consists of several APIs to implement Enterprise JavaBeans, Java Servlets, Java Server Pages, and JDBC for database access, among many others.
J2EE simplifies enterprise applications by basing them on standardized, modular components, by providing a complete set of services to those components, and by handling many details of application behavior automatically. J2EE takes advantage of CORBA technology for interaction with existing enterprise resources.
Enterprise JavaBeans
Enterprise JavaBeans (EJB) technology gives developers the ability to model a wide range of objects useful in the enterprise by defining two distinct types of EJB components: Session Beans and Entity Beans. Session Beans represent behaviors associated with client sessions. Entity Beans represent collections of data, such as records in a database, and encapsulate operations on the data they represent. Entity Beans are intended to be persistent, surviving as long as the data they're associated with.
Client applications communicate with EJBs using strictly standardized EJBHome and EJBObject interfaces to locate, instantiate, and invoke methods on remote objects. You can use the VisiBroker for .NET developer tools to generate all the code needed to communicate with the EJBs, from its Java RMI source to the .NET-compatible C# language.
Java RMI
Java Remote Method Invocation (RMI) technology allows developers to work completely in the Java programming language to produce Java technology-based distributed applications. There is no separate Interface Definition Language (IDL) or mapping to learn. Java RMI technology that is run over Internet Inter-Orb Protocol (RMI-IIOP) delivers CORBA distributed computing capabilities to the J2EE platform.
Like CORBA, RMI-IIOP is based on open standards defined with the participation of hundreds of vendors and users in the Object Management Group. Like CORBA, RMI-IIOP uses IIOP as its communication protocol. IIOP eases legacy application and platform integration by allowing application components written in C++, C, COBOL, and other CORBA supported languages to communicate with components running on the Java platform.
What is CORBA?
Common Object Request Broker Architecture (CORBA) is an architectural specification that provides the capability for distributed applications to interoperate without understanding detailed communication requirements on one end or the other. CORBA is based on open standards defined with the participation of hundreds of vendors and users in the Object Management Group.
A common model of a CORBA application is a typical client-server model, with the exception that it uses a middle layer, known as middleware, or more specifically, an Object Request Broker (ORB). An ORB is a collection of services that manage interactions between distributed applications.
Interface Definition Language
The Interface Definition Language (IDL) is a descriptive language you use to describe your CORBA interfaces to remote objects. You use an IDL compiler to generate a client stub file and a server skeleton file in your implementation language, usually C++, Java, C#, or another high-level language. The Object Management Group (OMG) has defined specifications for language mappings to a variety of programming languages. VisiBroker for .NET provides a language mapping for IDL in C#. See “IDL to C# mapping” for more information.
You can write your IDL code in any IDE but you need an IDL compiler to generate .NET compatible stubs and skeletons. Using the VisiBroker for .NET developer tools, you can use one of the IDL compilers included to generate the C# client stub from an IDL file. The IDL compiler reads the IDL file and generates a class or other addressable object that includes stubs, which are general methods that accept a simple message request from an application. The stub passes the request to the object implementation, on the server for example, and, on receiving a response, decodes the response and returns the results to the calling application, or client.
The VisiBroker for .NET features comply with the CORBA specification (version 3.0) from the Object Management Group (OMG) and are interoperable with VisiBroker.
CORBA and .NET Remoting
Much of .NET interoperability centers on XML and SOAP. While these technologies have their strengths, primarily in being able to use connectionless protocols, such as HTTP, they have serious drawbacks when it comes to synchronous communications.
In those cases, using peer-to-peer protocols, such as IIOP, are more efficient and secure. Additionally, using synchronous client-server communication allows you to pass binary data across a more tightly-coupled system, providing more data security and recovery capabilities.
VisiBroker for .NET allows you to bootstrap to the CORBA middleware, and locate objects using either CORBA-style calls or .NET Remoting calls in your client code. See examples of application development in “Developing VisiBroker for .NET client applications” and “Developing VisiBroker for .NET Remoting servers”.
Microsoft Visual Studio .NET options
If you selected the Microsoft Visual Studio .NET component when you installed VisiBroker for .NET, your Visual Studio environment will have some extra elements to make your VisiBroker for .NET application development go smoothly.
To configure the VisiBroker for .NET options in Visual Studio:
1
2
The following configuration options are available: