orbacus technical review white paper

Document Sample
orbacus technical review white paper Powered By Docstoc
					Orbacus Technical
IONA Technologies February 2007
Orbacus Technical Review                                                                                 2

Orbacus for C++ and Java is a CORBA 2.6-compliant Object Request Broker. The C++ version excels at
high load and performance, while the Java version emphasizes portability and full integration with the
Java 2 Platform. Both versions are completely interoperable via the industry standard Internet Inter-
ORB Protocol (IIOP), which enables cross-platform integration of distributed software components.

Orbacus is distributed as source code, which affords the ability to look under the hood. This lets you
diagnose potential problems in an application or underlying infrastructure, to make modifications as
necessary, and to take better advantage of the internal operation and structure of the ORB. In
keeping with this philosophy, the Orbacus engineering team provides technical support for Orbacus.

Orbacus is a mature product that is in use in a variety of applications in more than 2000 end-user
organizations and ISVs in the telecommunications, e-commerce, financial, defense and petroleum
industries, among others.
Orbacus Technical Review                                                                                    3

Orbacus is compliant with the CORBA 2.6 standard and some parts are CORBA 3 compliant.

It is easy to embed Orbacus in an application or existing environment because Orbacus is compiled
from source. Possession of the Orbacus source code provides many advantages. Customers can:

     •    Pick and choose which pieces of the product they wish to use in their application, and can
          compile Orbacus with the specific flags and optimizations used in their application. Compiling
          and linking only the necessary libraries, and specifying flags and optimizations at compile
          time reduce the footprint of the application.

     •    Create debug builds that help you debug your application; debug builds of Orbacus contain
          additional diagnostics that help the developer create correct CORBA applications.

     •    Populate the library with optimizations and/or additional selected compiler flags to better fit
          your environment.

     •    Rebuild Orbacus and the application to address binary-incompatible changes in the
          underlying OS.

     •    Choose from a wider range of tools and protect against platform incompatibility. For
          example, differences in installed versions of GCC and GLIBC across various Linux platforms
          can often affect runtime behavior. Source availability ensures compatibility with your toolset
          and provides the ability to ship tailored distributions of your product.

     •    Use the product's service implementations as examples of real world CORBA services, and
          as templates for building your own applications and services.

     •    More easily obtain and apply source code patches. Orbacus patches are small, easily
          distributed by e-mail, and are easy to apply. This too helps the developer avoid becoming
          locked in to toolsets or particular OS distributions.

Thus after embedding Orbacus in an application, customers need not worry about different versions
of operating systems and compilers, different patch levels, different compiler settings, or the myriad
other variations that are typical in a fast-moving technical environment. With Orbacus, you build in
infrastructure that precisely matches your application and environment.

Orbacus is supported directly by its developers, who provide extremely fast response and expert
problem-solving capabilities for enterprise-class environments. This Developer-to-Developer
support level allows your engineers to communicate with the Orbacus developers not only to resolve
bugs, but also to discuss design issues, offer recommendations for future additions, and to find ways
around issues that would be roadblocks with closed-source products.

During business hours, customers with support contracts can send queries to support@orbacus.com
and get a response within hours. For customers with mission-critical 24x7 support requirements,
Orbacus Technical Review                                                                         4

IONA can provide support by means of a global customer services organization. You can also have an
assigned technical account manager who is familiar with your deployment environment, to make sure
your systems have the minimum time to problem resolution.
Orbacus Technical Review                                                                                5

Major Features
Orbacus features are described in the sections below.

Configuration and Bootstrapping
Installing and configuring Orbacus applications is a remarkably simple. The complications of ORB
configuration have been removed. You simply start your servers and clients—no ORB daemons are
necessary. And you can optionally use the Implementation Repository, which automatically starts
your servers on demand.

Orbacus also supports the new URL-style object reference standard for simplified application
bootstrapping. For example, you can specify the location of the Naming Service with:


In addition, Orbacus now provides a generic facility for dynamically loadable modules (previously, all
Orbacus modules had to be loaded at application startup). Dynamic loading is useful for transparently
installing extensions and services such as transactions, interceptors, and protocol plug-ins. It allows
application extension via configuration, rather than programming, and improves application
portability by eliminating proprietary application initialization code.

Interface Repository
Orbacus includes a fully compliant Interface Repository (IFR). It is highly reliable, and has been tested
with many applications (such as scripting languages). Orbacus IDL-to-C++ and IDL-to-Java
translators, as well as documentation generators, are based on the IFR. When an IDL translator is
executed, the IDL code is first stored in an internal IFR, and code then is generated directly from that
IFR. This scheme makes it easy to implement your own IDL tools, without having to reinvent the
wheel and write a new IDL parser from scratch.

Dynamic Programming
Orbacus fully supports the Dynamic Invocation Interface (DII), the Dynamic Skeleton Interface (DSI),
and the Dynamic Any interfaces. With the DII and DSI, you can send and receive requests without
compile-time knowledge of interface types and operation signatures.

Normally the DII and DSI are restricted to primitive types only. However, Dynamic Any extends the
DII/DSI by allowing you to construct or interpret values of complex types for which no static type
information exists. Thus Dynamic Any is critical for the effective use of the DII and DSI.

Concurrency Models
Concurrency models describe the strategies an ORB employs for concurrent communication and
request execution. There is no one-size-fits-all approach with respect to concurrency models.
Selecting the proper concurrency model for a particular application is essential to ensuring correct
Orbacus Technical Review                                                                               6

behavior and optimizing performance. Orbacus supports a multitude of concurrency models: the two
primary models being single-threaded and multi-threaded.

In contrast to many other ORBs, which support nested callbacks in multi-threaded mode only, the
Orbacus architecture supports nested callbacks even in single-threaded mode. Further, it takes only
a few initialization steps to integrate Orbacus with existing single-threaded event dispatchers such as
X11 and Windows. Orbacus also supports custom event dispatchers.

Multi-threading is essential for high-load, large-scale architectures. With multi-threading, you can
fully exploit the power of your multi-processor hardware.

Orbacus provides a fully thread-safe library that supports thread-perclient, thread-per-request, and
thread pool and a Leader-Follower request dispatch models. Orbacus also supports JThreads/C++,
which provides Java-like threads for C++. This high-level thread abstraction library gives C++
programmers the look and feel of Java, and can reduce training requirements significantly—if you
understand Java threading, you can instantly use Jthreads/C++. On each platform, Orbacus obtains
maximum performance by using the underlying native threads directly rather than via emulation:

          WIN32 threads on Windows XP and 2003
          POSIX or DCE threads on Unix

Active Connection Management
Orbacus clients and servers can be configured such that idle connections are reclaimed
automatically, conserving threads, sockets, memory, and other important system resources, as
shown in Figure 1. Using active connection management, you can design server applications that
support thousands of clients.
Orbacus Technical Review                                                                           7

Figure 1: Active Connection Management

Documentation Tools
Keeping a project's documentation current is cumbersome and time-consuming if you don't have the
right tools.

Orbacus gives you the tools you need to generate attractive, useful documentation. More importantly,
you only need to maintain one file for both source and documentation, which helps ensure that
documentation is always consistent with the source code.

Orbacus includes two translators that generate Hypertext Markup Language (HTML) and Rich Text
Format (RTF) documents from your commented IDL files. In order to minimize the learning curve, the
Orbacus IDL-to-HTML and IDL-to-RTF translators support many of the same comment tags as Sun's
Javadoc utility. The generated HTML documents can be viewed with standard Web browsers such as
Netscape Navigator or Internet Explorer, and the generated RTF files can be imported easily into all
major word processing applications, including Microsoft Word.
Orbacus Technical Review                                                                                    8

The Portable Object Adapter
The Portable Object Adapter (POA) provides high scalability for servers that contain very large
numbers of objects. The POA lets you implement sophisticated object caches, or use a single in-
memory object to represent unlimited numbers of CORBA objects in a database. The POA thus
provides management of server-side resources to improve scalability. By deactivating server-side
components when they are idle, and re-activating them as needed, the same amount of computing
resources can support many more clients.

The Portable Object Adapter (POA) lets you write server code that is highly portable to other ORB
products. In addition to portability, the POA offers many other advantages. For example, you can have
several POAs in one single application, with each POA being responsible for a set of objects with
common characteristics (such as activation or persistence). You can also have several POA
managers, with each of them controlling the flow of requests for a group of POAs.

A CORBA system uses the POA to specify resource allocation and deallocation patterns, by setting
POA Policies. These policies determine whether POA-created object references are transient or
persistent; whether objects are activated for the duration of a method call (or for a longer or shorter
period), and how CORBA objects are mapped to servants. There are a total of seven POA policies; the
most important determine the characteristics of four basic resource allocation patterns, called
Service, Session, Process, and Entity.

For example, the following policies can be applied to these allocation patterns:

     •    LifespanPolicy of an object reference can be TRANSIENT or PERSISTENT. When a server
          fails, TRANSIENT object references become invalid (even if the object in question is not
          deleted). The difference between these two policies is clearest in cases of load-balanced
          objects on a multi-machine server. A PERSISTENT object reference supports reliable
          execution and allows load balancing on a per-object, per-session basis.

     •    ServantRetentionPolicy of an object reference can be RETAIN or NONRETAIN. A NON-
          RETAIN servant is deactivated as soon as it returns from an invocation. In contrast, a servant
          with RETAIN object reference remains active and is recorded in the POA's Active Object Map.
          This allows future invocations to be routed directly to the servant.

     •    IdAssignmentPolicy of an object reference can be SYSTEM_ID or USER_ID. For SYSTEM_ID,
          the ORB assigns the ID while for USER_ID the programmer chooses the ID string. Upon
          reactivation of a servant, the ORB passes the ObjectID to it, and the servant uses the ObjectId
          to restore its state. At that point, the POA pass the invocation to the servant for execution.

Asynchronous Method Invocation (AMI)
AMI allows you to have asynchronous behaviour in the request/reply itself as opposed to having a
separate CORBA service such as the Event or Notification Service.
Orbacus Technical Review                                                                               9

Using AMI allow clients to continue processing while waiting for the results of asynchronous
invocations. The most common use of the AMI is when a client calls a server that has a long response
time. With this technique, long-running calls don’t interfere with other calls. It also allows single-
threaded applications to avoid blocking while waiting for responses. This feature potentially makes
programming easier and avoids the need to determine the best threading model to use for the

There are problems with callback-based servers that are caused by the server having to manage and
keep track of many callback objects, their registrations, and the data sent to them. Fortunately, these
problems do not arise with the AMI callback model because the server ORB treats the asynchronous
request as it does a synchronous request, i.e., it dispatches the request and returns the reply. The
client ORB, not the server, handles the asynchronous aspects of the reply. In fact, existing CORBA
servers need not be changed at all to handle AMI requests.

An important consequence of both the callback and polling models is that multiple two-way AMIs can
be processed asynchronously within a single thread of control. This design simplifies the need for
concurrency control that would otherwise be required if multiple threads were used to process
multiple two-way synchronous calls simultaneously.

Benefits of using AMI:
 Simpler to program            Some applications are better expressed asynchronously. Rather than
                               having a client spawn another thread to wait on conditions, they can
                               simply respond to callback messages as they occur. This greatly
                               simplifies the design of a client application.

 No changes required on        AMI requires only client-side changes. However, you are free to
 the server                    redesign your servers to allow an even easier client design. Consider
                               a thermostat application; this would normally poll a thermometer
                               and when a specific temperature value is received, it would perform
                               some specific task. You could redesign the server to only return a
                               'true' value when a specific value is reached, rather than returning
                               the current temperature value. The client could make an
                               asynchronous request once and when the server returns, it would
                               handle the condition. This greatly reduces network traffic and
                               eliminates the need for a client to spawn a monitor thread.
 Less resource usage           AMI allows you to design applications that require less threads, CPU
                               usage and network messages, thus saving on resource usage. No
                               need to deploy the Notification Service for many simple situations.
Orbacus Technical Review                                                                                 10

The Implementation Repository
Production environments often need the ability to start servers on demand, and the flexibility to
migrate servers to different hosts without adversely affecting clients. The Orbacus Implementation
Repository (IMR) provides this functionality, along with an administrative application that simplifies
configuration and maintenance thanks to an intuitive graphical user interface.

Objects by Value
In a network environment of high latency and relatively low bandwidth, reducing network traffic can
improve the overall performance of the distributed system. Objects By Value are instrumental in
adopting this approach; rather than performing one or remote invocations on an object, you can use
Objects By Value to turn the remote interaction into a local one.

Rather than having two objects communicate over the network, one of these objects is moved (passed
by value) to the location of the other object, and the formerly remote interaction is changed to purely
local communication.

Thus in Orbacus, objects are not restricted to being passed only by reference. Using valuetypes,
objects can also be passed by value. Valuetypes are similar to structs, but support operations,
inheritance, and arbitrary sharing semantics. The latter is especially important for defining complex
data structures, such as lists, trees, or graphs.

Abstract interfaces, when used with Objects By Value, provide an even higher degree of flexibility. An
instance of an abstract interface can either be a regular object reference or a valuetype, as
determined at runtime. This allows a mixture of local and remote objects having the same interface,
and whose location is transparent to the client.

Portable Interceptors
Orbacus implements the Portable Interceptor specification. Interceptors provide a hook for adding
code that is called upon for each operation invocation, on both the server and client side.

This can be used to build custom CORBA services, such as an Object Transaction Service or a
Security Service, or to build distributed debugging tools. For example, the specification makes it easy
to write an interceptor that logs all operation invocations, including exceptions, return values, and

Orbacus comes bundled with the Naming, Events, and Property CORBA services. The Notification
Service is provided as a separate product -Orbacus Notify.

Finding and obtaining object references is made easy with the CORBA Naming Service. The Naming
Service is a directory service—essentially a white pages or a lookup service for objects—where the
name is known and the Name Service returns a CORBA pointer to the object. With Orbacus Names,
Orbacus Technical Review                                                                               11

objects are registered with a unique name that can later be used by applications to look up and
recover the associated object reference.

The CORBA Event Service provides asynchronous messaging—which supports loose coupling —
between applications. Some applications can exchange information without explicitly knowing about
each other, and a server may not be aware of the nature and number of clients that are interested in
the data it provides. Orbacus Events provides decoupled data transfer between servers and clients.
Orbacus Events runs as a separate process accessed by standard CORBA application interfaces.

The CORBA Property Service permits developers to annotate an object with extra attributes (called
properties) that were not pre-defined by the object’s IDL interface. This lets developers annotate
objects at runtime with properties that may be applied to individual objects or across object types.

In this way, an application or family of applications can set or query object properties dynamically, for
example, to augment object characteristics defined in IDL. OMG provides an interesting example of
this feature’s use, in which an online service download utility program keeps count of the number of
times the service is invoked. By using the Property Service, this information is associated with the
object but is not part of the object’s type.

A property managed by Orbacus Properties consists of two components, the property’s name and its
value. The name is a CORBA string and the associated value is stored as a CORBA Any.

Orbacus Notify provides asynchronous publish/subscribe-based messaging, naturally
complementing the CORBA synchronous request/reply paradigm and Asynchronous Method
Invocation (AMI). Orbacus Notify also supports various levels of Quality of Service by enabling the
configuration of the event channel and individual connections to it. Orbacus Notify’s is an
implementation of the Notification v1.3. For more information on Orbacus Notify please refer to the
separate white paper.

Fault Tolerance and High Availability
Orbacus supports transparent failover by implementing multiple profile Interoperable Object
References, also known as Multi-Profile IORs. A Multi-Profile IOR encapsulates multiple object
references, which can be accessed optionally using different transport protocols. An embedded client
failing to access an object on one server will transparently attempt to access an object on a different
server with no change to the application code.

Orbacus also provides a manually configurable Load Balancing Service: This feature lets you balance
client requests across a set of replicated objects and (stateless) servers. When a client invokes on a
replicated object, the balancing service selects a replica using the configured load balancing strategy,
and returns a reference to this replica to the client.

The client then establishes a connection using the new object reference, and communicates directly
with the server without further intervention of the service. This load-balancing mechanism is
completely transparent to the client.
Orbacus Technical Review                                                                              12

Pluggable Protocols and the OCI
Orbacus provides the means to support other network protocols besides TCP/IP. The Open
Communications Interface (OCI) is a transport plug-in framework that lets developers define support
for new transports and easily integrate them into Orbacus.

OCI supports connection-oriented, reliable byte-stream protocols, which allow the transmission of a
continuous stream of bytes (octets) from the sender to the receiver. Orbacus TCP/IP connectivity is
itself implemented as an OCI plug-in; by using GIOP as the message format, this plug-in implements
the IIOP protocol.

Other candidate protocols are SCCP (Signaling Connection Control Part, part of SS.7) or SAAL
(Signaling ATM Adaptation Layer). Protocols implemented as other protocol-oriented features in
Orbacus can use plug-ins like URL object references.

Non-reliable or non-connection-oriented protocols can also be used, if the protocol plug-in itself
takes care of reliability and connection management.

For example, UDP/IP can be used if the protocol plug-in provides for packet ordering and packet
repetition in case of a packet loss.

The OCI is composed of several object types that manage the sending and receiving of octet streams.
There are blocking and non-blocking send/receive operations available, as well as operations that
handle time-outs and detection of connection loss. Registries and Info objects support the discovery
and plugging in of new protocols within applications.

Orbacus ships with support for bi-directional GIOP, part of the CORBA specification. It also ships with
a legacy bi-directional IIOP plug-in that previous Orbacus versions used before this standardization
was in place. Typically, a client can open a connection to a server through a firewall, but it is not
possible for the server to open a new connection back to the client in order to send a callback. The
same applies to applets that connect to a CORBA server, since for security reasons applets are not
allowed to accept incoming connection requests.

Bi-directional IIOP is a simple and efficient solution to this problem that allows connections from the
client to the server to be reused for callbacks from the server to the client. It can be combined with
any other protocol plug-in, such as IIOP or SSL. This allows it to be used with FreeSSL, providing a
100% secure firewall-tunneling solution.

Besides standard transport plug-ins, IONA can also provide specialized plug-ins for proprietary
protocols. Please contact us for more information.

Diagnostic Features
Accurate diagnostic information is critical when developing applications or analyzing system
behavior. Orbacus provides sophisticated diagnostic facilities that can be turned on and off as needed;
users have fine-grained control over the type and amount of diagnostic information produced.
Orbacus Technical Review                                                                               13

Diagnostic information includes exception messages, connection tracing, message retries, and
failover tracing.

Orbacus also provides logging facilities to applications. Used by Orbacus for its own diagnostic
messages, the Logger facility supports four types of messages (info, error, warning and trace).
Messages can be easily directed to consoles, file systems, or other monitoring devices. An application
can log its own messages to the Orbacus Logger facility. And the Logger facility can be extended by
applications if a separate or enhanced logging service is needed.

Finally, Orbacus provides the Watson Diagnostics And Analysis Package: Watson is a dynamically
loadable module that provides method tracing within the ORB. It lets you see all operations called,
along with supplied parameters. It also displays timing information and call stacks, and so is very
useful for debugging an application.

Orbacus Security
The FreeSSL plug-in provides secure authentication and encryption facilities for Orbacus C++
programs. Released under the Berkeley license, FreeSSL is distributed with source code and has no
licensing or run-time fees.

OpenSSL is a free public domain implementation of the Secure Sockets Layer (SSL) and Transport
Layer Security (TLS). OpenSSL provides privacy between applications that exchange data through a
network connection. For C++ programs, FreeSSL uses OpenSSL to provide the underlying encryption

There is a choice between two Java SSL toolkits for use with FreeSSL: JSSE from Sun Microsystems,
and iSaSilk from the IAIK-Java Group. The Java Secure Socket Extension (JSSE) is a set of packages
that enable secure Internet communications, and implements a Java technology version of the
Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. It includes functionality for
data encryption, server authentication, message integrity, and optional client authentication. JSSE is
freely available as part of Sun’s JDK.

IAIK-iSaSiLk is a Java programming language implementation of the SSLv2 (client-side), SSLv3 and
TLS 1.0 protocols. It supports all defined cipher suites (except for Fortezza), including all AES cipher
suites from RFC 3268. iSaSiLk comes with an easy to use API and operates on top of the IAIK-JCE
Java Cryptography Extension. Orbacus applications can be SSL-enabled through the addition of a few
simple API calls. Further, applications can use any combination of secure and insecure connections,
all under the complete control of the developer.

The FreeSSL plug-in exploits the standard CORBA policy framework and provides an intuitive and
powerful identity model (without an identity model, it is not possible to provide authentication or non-
repudiation, both essential features of any modern e-commerce application). Client and server
applications can alter their identity by changing the policies that apply to the object reference.
Orbacus Technical Review                                                                                  14

Trust decisions are an essential part of any secure application. FreeSSL provides the ability to tailor
the trust decision rules to your enterprise, which allows great flexibility in determining
trustworthiness and making access decisions.

FreeSSL also provides authentication, privacy and integrity for Orbacus applications. Based on the
Secure Sockets Layer protocol, the FreeSSL plug-in ensures that Orbacus clients and servers can
communicate securely over any network.

FreeSSL’s features:

     •    Flexible identity control for both client and server.

     •    Total freedom in establishment of trust decision rules.

     •    Multiple key exchange algorithms.

     •    Interoperability for C++ and Java clients and servers.

For more information on OpenSSL, see http://www.openssl.org/

For more information on iSaSiLk, see http://jce.iaik.tugraz.at/products/

For more information on JSSE, see http://java.sun.com/products/jsse/
Orbacus Technical Review                                                                               15

IONA’s Orbacus Support
Technical Support
IONA has more customers and more systems in production than any other CORBA vendor, and is able
to offer the highest quality of CORBA support in the industry. When a production system fails on a
Saturday morning, the root cause must be rapidly identified and rectified. A wait of three days for
email-only support—typical for open-source ORBs—is simply unacceptable. Open-source ORB users
usually have to post product issues to a newsgroup, and hope that someone, somewhere, has the free
time to identify and correct the problem and issue a patch.

In contrast, IONA offers several levels of support (Standard, Silver, and Gold) that are tailored to
different, specific service level requirements. One of these requirements includes 24x7 on-call
response. Upon notification of a product issue, IONA’s response is a precise commitment of issue
resolution within a guaranteed, specified timeframe. The large number of enterprise-scale IONA
CORBA systems in production testifies to the quality of the technical support IONA provides.

Consulting Services
IONA’s industry experience, gained through 4500 successful customer deployments and years of
experience in services-orientated application development, helps customers lower their risk and
maximize their return on investment. IONA provides a number of different types of engagements:

     •    Application Review: IONA can optimize the performance of your application and perform a
          sanity check of your architecture

     •    Milestone Success Consulting: IONA can provide product expertise during critical project
          milestones throughout the course of a project.

     •    Dedicated On-Site Consulting: IONA can provide an integration expert for day-to-day
          assistance on your use of IONA products.

     •    Follow-up Hourly Consulting: IONA can provide occasional remote assistance with
          applications that helped to develop.
Orbacus Technical Review                                                                              16

Orbacus Key Benefits
Ease of Use
     •    Configuration and bootstrapping is simple:

                o    Daemon-less servers

                o    Servers started automatically by the Implementation Repository

                o    URL-style object references

     •    Watson diagnostics and analysis — method tracing within the ORB

     •    Extensible Logging facility — output to multiple devices

     •    Support for dynamic loading of modules

     •    Documentation Tools — Translators

                o    IDL to Hypertext Markup Language (HTML)

                o    IDL to Rich Text Format (RTF)

     •    JThreads/C++ —Java-like threading for C++

Qualities of Service
     •    Load Balancing — balance client requests across a set of replicated objects and stateless

     •    Fault Tolerance — transparent failover by implementing multiple profile Interoperable Object

     •    Active Connection Management — reclaim idle connections automatically, conserving
          threads, sockets, memory and other important system resources

     •    Security — FreeSSL plug-in provides secure authentication and encryption facilities

     •    Concurrency — Single and Multithreaded models to exploit power of multiprocessor

     •    Dynamic Loading Of Modules — transparently install extensions and services such as
          transactions, interceptors, and protocol plug-ins

     •    Flexibility through pluggable transport protocols
Orbacus Technical Review                                                                                 17

CORBA features
     •    CORBA 2.6 support

     •    CORBA Services:

                o    Naming, Events and Property services are part of the Orbacus product

                o    Orbacus interoperates with the Orbix Notification, Orbix Trader and Orbix Telecom
                     Logging services

     •    Portable Interceptors — provide a hook for adding code that is called upon for each operation

     •    Portable Object Adapter — provides high scalability for servers that contain very large
          numbers of objects

     •    Objects by Value — reduce network traffic by turning a remote interaction into a local

     •    Dynamic Invocation and Dynamic Skeleton Interface — send and receive requests without
          compile-time knowledge of interface types and operation signatures

     •    Implementation Repository — start servers on demand and migrate servers to different hosts
          without adversely affecting clients

     •    Interface Repository — build IDL-to-anything translators easily

     •    BiDirectional GIOP Communications

     •    Asynchronous Method Invocation (AMI) allows the design of asynchronous, non-blocking
          clients without change to server-side design.
Orbacus Technical Review                                                                            18

Platform Coverage
For the latest platform support, see http://www.orbacus.com.

Supported Platforms            Hardware Compilers C++                          JDK
Microsoft Windows XP SP2       x86         Visual Studio 2003 (Visual C++ 7.1), JDK 1.4.2 and 5.0
                                           Visual Studio 2005 (Visual C++ 8.0)
Microsoft Windows Server 2003 x86          Visual Studio 2003 (Visual C++ 7.1), JDK 1.4.2 and 5.0
                                           Visual Studio 2005 (Visual C++ 8.0)
Sun Solaris 10                 x86,        Sun Studio 10                       JDK 1.4.2 and 5.0
Sun Solaris 9                  Sparc       Sun Studio 8,                       JDK 1.4.2 and 5.0
                                           Sun Studio 11
Sun Solaris 10                 Sparc       Sun Studio 10,                      JDK 1.4.2 and 5.0
                                           Sun Studio 11
HP-UX 11.11                    PA-RISC     aCC 3.73                            JDK 1.4.2 and 5.0

HP-UX 11.23                    Itanium     aCC 6.13                            JDK 1.4.2 and 5.0

Red Hat Linux WS/ES/AS 3.0     x86,        gcc 3.2.x                           JDK 1.4.2 and 5.0
Red Hat Linux WS/ES/AS 4.0     x86,        gcc 3.4.x                           JDK 1.4.2 and 5.0
SUSE Enterprise Linux 9        x86,        gcc 3.3.x                           JDK 5.0
IBM AIX 5L 5.3                 PowerPC     XL C++ 7.0                          JDK 1.4.2 and 5.0

Note: Orbacus supports both Classic and Standard I/O streams on all platforms.
Orbacus Technical Review                                                                                                                                                    19

IONA Technologies PLC                                  IONA Technologies Inc.                                 IONA Technologies Japan Ltd
The IONA Building                                      200 West Street                                        Akasaka Sanchome Building 7/F
Shelbourne Road                                        Waltham MA 02451                                       3-21-16 Akasaka
Dublin 4                                               USA                                                    Minato-ku Tokyo
Ireland                                                                                                       Japan
Phone +353 1 637 2000                                  Phone        +1 781 902 8000                           Phone +813 3560 5611
Fax      +353 1 637 2888                               Fax          +1 781 902 8001                           Fax       +813 3560 5612
Support: support@iona.com                              Training: training@iona.com                            Sales: sales@iona.com
WWW: www.iona.com                                      www.orbacus.com
Artix, Artix Mainframe, Adaptive Runtime Technology are Trademarks of IONA Technologies PLC. Orbix, Orbix 2000 Notification, and Orbix/E are Registered Trademarks
of IONA Technologies PLC.
While the information in this publication is believed to be accurate, IONA Technologies PLC makes no warranty of any kind to this material including, but not limited to,
the implied warranties of merchantability and fitness for a particular purpose. IONA shall not be liable for errors contained herein, or for incidental or consequential
damages in connection with the furnishing, performance or use of this material.
COPYRIGHT NOTICE. No part of this publication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, photo- copying, recording
or otherwise, without prior written consent of IONA Technologies PLC. No third-party intellectual property right liability is assumed with respect to the use of the
information contained herein. IONA Technologies PLC assumes no responsibility for errors or omissions contained in this white paper. This publication and features
described herein are subject to change without notice.
Copyright © 1999-2007 IONA Technologies PLC. All rights reserved.
All products or services mentioned in this white paper are covered by the trademarks, service marks, or product names as designated by the companies that market
t0hose products.

Shared By: