Orbacus Technical Review IONA Technologies February 2007 Orbacus Technical Review 2 Summary 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 Introduction 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: corbaloc::MyServer:9999/NameService 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 application. 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 the server AMI requires only client-side changes. However, you are free to 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 parameters. Services 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 technology. 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 servers • Fault Tolerance — transparent failover by implementing multiple profile Interoperable Object References • 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 hardware • 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 invocation • 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 invocation • 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 HardwareCompilers C++ JDK Microsoft Windows XP SP2 x86 Visual Studio 2003 (Visual C++ 7.1), Visual Studio 2005 (Visual C++ 8.0) JDK 1.4.2 and 5.0 Microsoft Windows Server 2003 x86 Visual Studio 2003 (Visual C++ 7.1), Visual Studio 2005 (Visual C++ 8.0) JDK 1.4.2 and 5.0 Sun Solaris 10 x86, x86_64 Sun Studio 10 JDK 1.4.2 and 5.0 Sun Solaris 9 Sparc Sun Studio 8, Sun Studio 11 JDK 1.4.2 and 5.0 Sun Solaris 10 Sparc Sun Studio 10, Sun Studio 11 JDK 1.4.2 and 5.0 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, x86_64 gcc 3.2.x JDK 1.4.2 and 5.0 Red Hat Linux WS/ES/AS 4.0 x86, x86_64 gcc 3.4.x JDK 1.4.2 and 5.0 SUSE Enterprise Linux 9 x86, x86_64 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 Copyright 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.