OrbixWeb 3.0 is a CORBA 2.0 compliant, 100% Pure Java ORB with better lifecycle management of distributed objects. It includes many useful services which make it easier to develop, deploy and manage distributed applications in the Internet age. In today's computing age of Internet and multi-tier architecture, combining Java and CORBA offers the best solution. If you want to do it, then you might want to look into Iona's OrbixWeb 3.0 as one of the leading edge, robust and proven solutions. OrbixWeb is a fully CORBA 2.0 compliant distributed application development environment for Java.

Iona and CORBA
In the CORBA world, Iona has many firsts to its credit - including the first commercially available CORBA compliant ORB in 1993. With a strong research background of founders, it has always been a technology leader. In OrbixWeb version 3.0, Iona has removed remaining C++ code from its support utilities. The basic ORB was already Pure Java. This version comes with many new services, improved server object invocation and OMG-compliant Java mapping.

Basics of OrbixWeb Architecture
Orbix ORB is implemented as a pair of libraries (for client and server) and the Java based activation daemon orbixdj (orbixd for C++). The daemon is needed only on servers' hosts. It is primarily responsible for (re)launching server processes and connects the client/server for the first time. The daemon maintains a simple database called Interface Repository which maintains the activation modes, access lists and other information about the server. In case of "in process" activation, no separate process is started but the server runs within the same VM (virtual machine). This improves performance. For non-Java servers you will have to use "out process" activation. Manual activation would be required for persistent servers and you might use it for your legacy server. Orbix supports different thread models - namely, per-client, thread-pool and per-client-thread.

After establishing the connection, the requests are passed directly from the client to the server. The messaging component within the libraries manages the (un)marshalling, protocol and synchronization. Orbix supports its proprietary and OMG IIOP protocol.

OrbixWeb-Based Distributed Systems
As a CORBA-based developer you might need to begin with writing the interfaces, using OMG's Interface Definition language, for your object.

Then you compile the IDLs using Iona's supplied IDL-to-language compiler. The IDL to language compiler (Java, C++, Smalltalk, Ada) generates (client side proxy) stubs and (server side) skeletons in that language. OrbixWeb 3.0 completely supports the OMG IDL to Java mapping including the Java ORB portability interfaces. You don't have to recompile stub and skeleton for use against different vendor's ORBs. If you use a previous version of OrbixWeb then I have bad news for you. The new Java IDL mapping is different from OrbixWeb's previous version. You must convert to the new interfaces. The good news is that you can use migration utilities.

Develop Dynamic Client and Servers
In a different scenario, you might not need to start with writing IDL; that is, using Dynamic Invocation Interfaces (DII). In this case, your client might not know the interfaces at compile time. In such cases, the client program browses the Interface Repository (IFR), gets the methods and parameters, formulates the request, sends the request and then polls and processes the result. You can use trader service (OrbixTrader) and naming service (OrbixNames) for getting the object reference that is required for IFR. OrbixWeb also supports Dynamic Skeleton Interface (DSI) which is for developing a dynamic server.

Develop Web Applications Using OrbixWeb
OrbixWeb 3.0 supports Internet Inter-ORB Protocol (IIOP) communication. It enables the Object invocation and callbacks to be sent across the Internet. A client applet along with any browser can download the stub and related OrbixWeb classes. OrbixWeb does not depend upon static embedded browser classes or plugins. Thus, if required, you can change the ORB configuration information on-the-fly. The applet then uses Internet ORB Protocol (IIOP) to communicate with the backend services on the Web server.

One of the most serious concerns you might have for Internet applications is security. To protect the internal hosts from the hacker's attack, you might need to use Iona's Wonderwall. Wonderwall is a mechanism for firewall navigation by IIOP requests. This proxy allows IIOP traffic to be filtered and routed at the firewall. The Wonderwall "proxifies" the Interoperable Object reference (IOR) of an object and allows remote invocation on the proxy IOR. Once a proxy for the IOR has been established, the client can communicate with the proxy through a single, known port.

Develop Dynamic Client and Servers
In a different scenario, you might not need to start with writing IDL; that is, using Dynamic Invocation Interfaces (DII). In this case, your client might not know the interfaces at compile time. In such cases, the client program browses the Interface Repository (IFR), gets the methods and parameters, formulates the request, sends the request and then polls and processes the result. You can use trader service (OrbixTrader) and naming service (OrbixNames) for getting the object reference that is required for IFR. OrbixWeb also supports Dynamic Skeleton Interface (DSI) which is for developing a dynamic server.

Develop Web Applications Using OrbixWeb
OrbixWeb 3.0 supports Internet Inter-ORB Protocol (IIOP) communication. It enables the Object invocation and callbacks to be sent across the Internet. A client applet along with any browser can download the stub and related OrbixWeb classes. OrbixWeb does not depend upon static embedded browser classes or plugins. Thus, if required, you can change the ORB configuration information on-the-fly. The applet then uses Internet ORB Protocol (IIOP) to communicate with the backend services on the Web server.

One of the most serious concerns you might have for Internet applications is security. To protect the internal hosts from the hacker's attack, you might need to use Iona's Wonderwall. Wonderwall is a mechanism for firewall navigation by IIOP requests. This proxy allows IIOP traffic to be filtered and routed at the firewall. The Wonderwall "proxifies" the Interoperable Object reference (IOR) of an object and allows remote invocation on the proxy IOR. Once a proxy for the IOR has been established, the client can communicate with the proxy through a single, known port.

Develop Dynamic Client and Servers
In a different scenario, you might not need to start with writing IDL; that is, using Dynamic Invocation Interfaces (DII). In this case, your client might not know the interfaces at compile time. In such cases, the client program browses the Interface Repository (IFR), gets the methods and parameters, formulates the request, sends the request and then polls and processes the result. You can use trader service (OrbixTrader) and naming service (OrbixNames) for getting the object reference that is required for IFR. OrbixWeb also supports Dynamic Skeleton Interface (DSI) which is for developing a dynamic server.

Develop Web Applications Using OrbixWeb
OrbixWeb 3.0 supports Internet Inter-ORB Protocol (IIOP) communication. It enables the Object invocation and callbacks to be sent across the Internet. A client applet along with any browser can download the stub and related OrbixWeb classes. OrbixWeb does not depend upon static embedded browser classes or plugins. Thus, if required, you can change the ORB configuration information on-the-fly. The applet then uses Internet ORB Protocol (IIOP) to communicate with the backend services on the Web server.

One of the most serious concerns you might have for Internet applications is security. To protect the internal hosts from the hacker's attack, you might need to use Iona's Wonderwall. Wonderwall is a mechanism for firewall navigation by IIOP requests. This proxy allows IIOP traffic to be filtered and routed at the firewall. The Wonderwall "proxifies" the Interoperable Object reference (IOR) of an object and allows remote invocation on the proxy IOR. Once a proxy for the IOR has been established, the client can communicate with the proxy through a single, known port.

• Figure 1
• Figure 2