Migrating IONA Orbix 3 Applications

Transcription

1 Migrating IONA Orbix 3 Applications Contrasting the migration path of Orbix 3 applications to Orbix 2000 and to Borland Enterprise Server, VisiBroker Edition by Will Edwards, Senior Consultant, The New Customware Company Introduction With the introduction of the CORBA 2.4 specification, market leaders Borland and IONA upgraded their CORBA products, VisiBroker and Orbix, respectively, to support this new and revised version of the CORBA standard. These products are Borland Enterprise Server, VisiBroker Edition and IONA Orbix The difference between the Orbix 3 product and the current Orbix 2000 release is substantial. As a result, upgrading applications from Orbix 3 to Orbix 2000 is no small task. Because of these differences, we examine in this paper whether it would be just as easy to upgrade an application from Orbix 3 to Borland Enterprise Server, VisiBroker Edition. The CORBA 2.4 specification is a radical revision of the standard. In the Borland Enterprise Server,VisiBroker Edition and IONA Orbix 2000 products, all features are CORBA 2.4- compliant, and many vendor enhancements are provided. Contents Introduction 1 Client-side issues 2 Server-side issues 5 General issues 7 Summary and Conclusions 8 One important differentiation between the versions of these products is the way they address the problem of upgrading from the previous releases of those products. In Borland Enterprise Server, VisiBroker Edition (the VisiBroker Edition), much of the functionality available in previous versions of the product is still provided, delivering backwards compatibility and easing upgrading. In Orbix 2000, much of the old functionality has been either repackaged or removed in favor of a pure CORBA 2.4 product. The consequence is that the upgrade path from earlier versions of Orbix Orbix 3 to Orbix 2000, for example is significantly more challenging than the path

2 required to migrate from earlier versions of VisiBroker to Borland Enterprise Server, VisiBroker Edition. Let s take as an example the following Java client code line in Orbix 3: In this paper, we take the Orbix 3 product features that either are commonly used or are technically challenging and explore the upgrade paths from Orbix 3 to Orbix 2000 and from Orbix 3 to the VisiBroker Edition. This paper describes our results and discusses the pros and cons of various options available when upgrading. Client-side issues In this section we examine the issues surrounding the upgrade of Orbix 3 client code and compare the changes necessary to upgrade this code to Orbix 2000 and to the VisiBroker Edition. Object location and binding Before using any CORBA object, it is first necessary for a client to locate and bind to a server object. In Orbix 3, this can be accomplished in a number of ways by using: The CORBA naming service The CORBA trading service Object references converted to strings by the server and then read by the client and converted back into an object reference A proprietary bind method With respect to CORBA, _bind the least common standard of the above techniques is an easy and convenient way for clients to discover and obtain references to a CORBA object. The fact that this method has not been included in Orbix 2000 is probably the most significant change to client-side code since developers would be forced to use one of the other techniques listed above. bankref = bankhelper.bind ("BankServer:BankMgr"); To use the name service with Orbix 2000, this would now become similar to: org.omg.corba.object obj = orb.resolve_initial_references("nameservice"); rootcontext = NamingContextHelper.narrow(obj); NameComponent[] name = new NameComponent[2] ; name[0] = new NameComponent("BankServer", ""); name[1] = new NameComponent("BankMgr", ""); obj = rootcontext.resolve(name); bankref = bankhelper.narrow(obj); The name service is not the only option available when migrating from Orbix 3 client code using bind() to Orbix It is, however, the easiest of the migration paths: the comparable code using the trader service or object reference strings would create even more complex client-side code. Although it uses slightly different technology than Orbix, the VisiBroker Edition retains the ability to use bind(). It therefore is easier to migrate the above Orbix 3 code to the VisiBroker Edition. In the case of migrating from Orbix 3 to the VisiBroker Edition, the above client code, using bind(), would become similar to: bankref = bankhelper.bind(orb, "/bank_agent_poa", BankServer:BankMgr".getBytes()); This conversion is more intuitive, as the two bind calls perform the same action. In this case, the only difference between them is the number of parameters taken and the reference to the POA, which will be discussed later. If an existing Orbix 3 system is using the bind() method for clients to discover and obtain object references, then the deployment will also use the Orbix 3 daemon, orbixd. 2

3 In Orbix 2000, orbixd is no longer available. The consequence is that all orbixd processes have to be replaced with name service, trader service, or string storage processes in the deployment and the arguments and configuration files constructed to provide the same or similar functionality. The conversion from Orbix 3 to the VisiBroker Edition would also require the replacement of orbixd, and it would require running the VisiBroker Smart Agent, osagent, and the VisiBroker Object Activation Daemon, oad; these two VisiBroker processes are the equivalent of the old Orbix 3 daemon, orbixd. Although not every command line and configuration parameter is the same, the conversion from orbixd to osagent and oad is much more intuitive, as the two VisiBroker processes combine to perform an almost identical function to orbixd. Communications protocol In releases after Orbix 2.3 but prior to Orbix 2000, IONA supported the use of two protocols for communication with a server: the CORBA standard Internet Inter-Orb Protocol (IIOP) and the IONA Proprietary Object Protocol (POOP). Typically, applications written prior to the release of Orbix 2.3 relied on the POOP protocol. In Orbix releases prior to Orbix 2000, the call to CORBA::ORB_init() before processing any requests was not necessary and was performed automatically by the Orbix libraries. However, Orbix 2000 requires developers to initialize the ORB explicitly. Therefore, this call must be added to all clients and servers. The Borland VisiBroker product has always required that the ORB be explicitly initialized. Since, with both the Orbix product and the VisiBroker product the same lines of code would have to be added the amount of work required to perform the upgrade would be the same. You should call CORBA::ORB_shutdown() and CORBA::ORB::destroy() before the end of the program to ensure clean termination. This is true for both ORB implementations with Orbix 2000 and the VisiBroker Edition. However, this step was not needed on the Orbix product prior to the release of Orbix Hence, these calls have to be added to all client and server code. Since these calls are identical in the two products, the same amount of work would be required to add these calls to an existing Orbix application to upgrade it to the VisiBroker Edition and to Orbix In Orbix 2000, IONA has removed support for the POOP protocol entirely, and applications that used POOP must now be converted to use IIOP. Upgrading applications from Orbix releases prior to Orbix 2.3 must undergo a significant number of changes. The VisiBroker product, on the other hand, has always used IIOP as its communications protocol. Thus, it is as easy to upgrade these applications to the VisiBroker Edition as it is to upgrade them to Orbix CORBA compliance Orbix 2000 enforces strict compliance with the CORBA 2.4 standard. The following client-side CORBA-compliance issues can be expected when upgrading to Orbix 2000: The object CORBA::Orbix is not supported in Orbix Therefore, the developer must convert client Orbix 2000 code that uses this convention to use the standard CORBA::ORB or PortableServer modules. The VisiBroker Edition does not use proprietary wrappers for the ORB core classes, so the same changes would be made whether upgrading an Orbix application to Orbix 2000 or to the VisiBroker Edition. Orbix APIs In Orbix releases prior to Orbix 2000, many of the CORBA core objects were wrapped by an Orbix-specific module. Perhaps the simplest example of this would be with the packaging of the Java modules in Orbix 3. The following packages were available: 3

4 IE.IONA.OrbixWeb contains classes for accessing CORBA constants such as type codes and timeouts. The package also contained proprietary Orbix features and factories used to obtain Orbix 3 implementations of abstract CORBA classes. IE.IONA.OrbixWeb.CORBA contains the Orbix wrappers for the standard CORBA objects such as Any, Basic Object Adaptor (BOA), Name Value Lists (NVList), etc. IE.IONA.OrbixWeb.Features contains classes for implementing Orbix features such as programmatic configuration, on-demand object loaders, object Filters and transformers, and authentication. These proprietary APIs and most other APIs have been left out of Orbix 2000 in favor of either the standard CORBA API or other means, such as moving programmatic configuration to configuration files. The full extent of these changes in C++ and Java is too extensive to list in this document; however, these changes mean that all programs needing to migrate will require rewriting or even re-designing to some extent or another. Passing the CORBA environment In Orbix C++ applications prior to Orbix 2000, it was necessary to place a CORBA::Environment parameter in most method signatures so that compilers which did not support exception handling could be supported. With the de facto support for exception handling in the current C++ compilers, this parameter is no longer needed. Orbix 2000 requires that any CORBA::Environment parameters be removed from IDL implementation method signatures. For example the IDL implementation signature virtual Bank::Account_ptr create_account( const char* name, CORBA::Environment&); would become virtual Bank::Account_ptr create_account( const char* name); The VisiBroker product has never required the additional environment parameter and as such, with the VisiBroker Edition, the method signature of the above code would look the same as in the second example above. Orbix smart proxies Orbix 3 supports smart proxies, a proprietary mechanism for overriding the default behavior of the client. This lets an application handle outbound requests within the local client process rather than using the default behavior of making a remote invocation on the server. This feature is widely used for things such as client-side caching, logging, load balancing, and fault-tolerance. Orbix 2000 does not directly support smart proxies. These smart proxies can be emulated, however, either by writing your own proxy wrapper or by using the functionality enhancements in Orbix 2000 that allow for logging, fail-over, load balancing, and local caching. It is, therefore, necessary to replace smart proxy functionality in existing Orbix 3 applications with the new and different methods in Orbix This step is not simply changing an API call in a program; it requires the re-architecting of the application that uses smart proxies. Orbix smart proxies are very similar in nature to the functionality provided in the VisiBroker Edition Typed Object Wrappers. While upgrading an Orbix 3 smart proxy application to use the VisiBroker Edition object wrappers would still require the rewriting of the interface code, it would not necessitate the re-architecting the application for deployment. 4

5 Server-side Issues Due to the migration of the older Basic Object Adapter (BOA) to the newer and more functionally complete Portable Object Adapter (POA), server code typically requires many more changes than client code. Migrating from the BOA to the POA Migrating server-side code from the BOA to the POA is a time consuming task that must be performed on every CORBA server in an application. For example, when using the BOA, object registration usually took three steps: 1. Initialize the BOA. 2. Create the Object. 3. Inform the BOA that the object was ready. With the POA these steps would typically become: 1. Lookup (resolve) a reference to the root POA. 2. Create the policies for an application POA. 3. Create a POA for the application with the desired policies. 4. Create a servant object. 5. Activate the object with the application POA. 6. Activate the application POA, if needed. The POA method of object registration requires substantially more code. The main benefit of doing this extra work is the greatly enhanced flexibility of the POA when compared with the BOA. However, it is a lot of work to upgrade servers if this flexibility is not needed. With Orbix 2000, there is no backward-compatibility support for BOA applications, and it is necessary to change servers to support the POA. In contrast, the VisiBroker Edition has not only POA support but also BOA support for backward compatibility. The BOA in the VisiBroker Edition is built on top of the POA implementation. That is, the functionality is fully CORBA 2.4 compliant. The VisiBroker Edition simply provides an ease-of-use and backward-compatibility interface on 5 top of the POA. Using the VisiBroker Edition BOA still requires code changes if upgrading an Orbix 3 BOA application in order to specify the specific VisiBroker BOA library or package, however it is much quicker to do this than convert the entire application to use the Orbix 2000 POA. It is generally preferred that all servers are converted to use the POA, but BOA support in the VisiBroker Edition is a good measure to take while this upgrade process is being performed. In conclusion, if upgrading an Orbix 3 server to use the POA were desired, this could be accomplished just as easily using the VisiBroker Edition as using Orbix Object identifiers In Orbix releases prior to Orbix 2000, object id s were defined as strings; in the Orbix 2000 and all releases that use the POA (including the VisiBroker Edition), object id s are defined as octet sequences, usually an array of bytes. This conversion is reasonably straightforward, though somewhat time-consuming. It is just as easy to upgrade in this way an Orbix 3 client to Orbix 2000 or to the VisiBroker Edition. Orbix loaders Orbix 3 Loaders are an API that allows the loading of objects on-demand as requests for them arrive; the comparable functionality in the VisiBroker product is called Activators. This functionality is primarily used to load server objects ondemand rather than keep all objects in memory all the time and dynamically load them and restore their state from a database or other storage device. Both Loaders and Activators are proprietary vendor extensions to the CORBA BOA. In CORBA 2.4, the ability to load an object on-demand is implemented in a standardized way using the POA servant manager functionality. Orbix 2000 requires that all server code be migrated to use the POA and Orbix 2000 no longer support Loaders. Thus, all

6 Loader code must also be migrated to use the POA servant manager. The VisiBroker Edition, however, does retain backward-compatibility support for the BOA and Activators. When migrating an Orbix 3 server to either Orbix 2000 or to the VisiBroker Edition, it is necessary to rewrite the Loader code. But, as Activators are more directly analogous to Orbix 3 Loaders than is the POA servant manager architecture, it is easier to migrate the server to the VisiBroker Edition using Activators. In many cases, migrating Orbix 3 Loaders to VisiBroker Edition Activators can be accomplished quickly and simply: migrating them to the POA requires many more changes even re-architecting the server application, in some cases. Orbix Filters Orbix 3 Filters provide an API that allows the programmer access to the low-level request broker runtime system. Using this API, developers can intercept the CORBA message request/response at various points and modify the flow of data. Filters are not available in Orbix 2000, and how an Orbix 3 application that uses Filters is migrated depends upon the reason that Filters are being used. Following are some of the most common uses of Filters and how they might be upgraded to Orbix 2000 and to the VisiBroker Edition: Logging, performance data gathering, and debugging: Orbix 3 Filters can be used to intercept client requests and log them to accumulate client usage statistics, and to provide debugging information and server loading data. Both Orbix 2000 and the VisiBroker Edition provide an implementation of the CORBA 2.4 Portable Interceptors; these Portable Interceptors provide a similar functionality to Filters, and code using Filters can be migrated to use Portable Interceptors just as easily for Orbix 2000 as for the VisiBroker Edition. For request logging, however, Portable Interceptors may be somewhat of overkill: PortableInterceptors give more information than may be required for a straightforward logging application. The effort required to use this low-level functionality could be considered disproportionate to the benefit. A simpler and more straightforward approach would be to use the object wrappers features of the VisiBroker Edition. Object wrapper provide a high-level, simple-to-use API for intercepting the CORBA request/response mechanism for: when a client sends the request, when the server receives the request, when the server sends the response, and when the client receives the response. This level of functionality is not available in Orbix For applications that require the logging of informational and debugging messages, Orbix 2000 provides a set of logging tools that allow the recording of messages across the Orbix domain. Object life-cycle management: Using Orbix 3 Filters, applications can monitor object use to detect idle activity with specific objects. Combined with on-demand object activation (see discussion of Orbix loaders), both Orbix and VisiBroker servers can be made extremely resource-efficient. The Orbix 2000 and VisiBroker Edition implementations of the POA allow for object activation and deactivation using the POA servant managers. However, migrating an application that manages object life cycle via Orbix 3 Filters to use the Orbix 2000 POA is an expensive task, not only because of the API changes but also because it changes the fundamental architecture of the management method. If it is desired to simply migrate the existing method of life-cycle management, it is possible to do this using Portable Interceptors for Orbix 2000 or of the VisiBroker Edition. Again, this is a reasonably time-consuming operation, since the Portable Interceptor API is quite different from the Orbix 3 filter API. For life-cycle management, a simpler and more straightforward approach is to use the object wrappers feature of the VisiBroker Edition, a feature which is not available in Orbix

7 Load balancing: Orbix 3 Filters can intercept and then reroute client requests based on the current server load. In Orbix 2000, load balancing is supported natively via the use of domains and object groups. Therefore, a current load balancing application, using Filters, can be upgraded to Orbix 2000 and the current load balancing system replaced with a deployment configuration of domains and object groups. As stated previously, this could also be accomplished via the use of Portable Interceptors in Orbix 2000 and in VisiBroker Edition. Or, more simply, this could be accomplished in the VisiBroker Edition simply by using object wrappers. Another alternative in the VisiBroker Edition is to use the native load balancing available via the VisiBroker Smart Agent architecture. Piggybacking data: If Orbix 3 Filters are being used to append extra data to a request message, the user id and/or terminal id of the client, for example, then this piggybacking can be replaced in both Orbix 2000 and the VisiBroker Edition with the CORBA 2.4-compliant method using ServiceContexts. In general, most Orbix 3 filter applications can be upgraded in many ways. The filter can be replaced with an Orbix 2000 or VisiBroker Edition Portable Interceptor, or the application can be re-architected to use a different feature of either product. In many cases, the upgrade can be accomplished easily by using the object wrapper API of the VisiBroker Edition. Orbix transformers Transformers are features that are available on Orbix 3 but which are not present in Orbix Transformers allow access to the very low-level binary data of a CORBA request/response message and can be used for a variety of purposes such as custom encryption, low-level debugging and tracing, network diagnosis, etc. While this low-level data access is not available in Orbix 2000, most encryption methods can be replaced with the Orbix 2000 SSL/TLS (Secure Socket Layer/Transport Layer Security). In the VisiBroker Edition, the low-level data access is 7 available via interceptors in addition to SSL and TLS via the VisiBroker Edition Security Service implementation. If it is desired to upgrade the current Orbix 3 transformer application directly, thevisibroker Edition interceptors provide the most direct method for this upgrade: inorbix 2000 there is no a way to access directly the binary CORBA request/response data. General issues This section briefly describes some general upgrade issues not specifically related to clients or servers. Make file changes When upgrading from Orbix 3, it is necessary to change the IDL compiler command-line arguments, link with a different set of libraries for C++, or include a different set of jar files in the classpath for Java whether upgrading the application to Orbix 2000 or to the VisiBroker Edition. This means the applicationbuilt scripts of make files must be changed, regardless of the upgrade path. Command-line tools Orbix 2000 unifies administrative commands under a single itadmin tool. This means that upgrading from Orbix 3 to Orbix 2000 requires the re-learning of the administrative commands and/or the rewriting of administrative scripts. The same would be required if upgrading to the VisiBroker Edition. However, it is our opinion that the graphical environment for the management and administration of the CORBA system in the VisiBroker Edition is simpler and more intuitive to use than the Orbix 2000 itadmin tool.

8 Summary and conclusion An enterprise seeking to upgrade its Orbix 3 application must determine whether to re-architect the application, simply rewrite enough of the application to conform to the new API details, or adopt a combination of these to upgrade the application immediately to the new API, and then gradually re-architect the application over time. With its repeal of former product features and its dedication to the CORBA 2.4 standard, Orbix 2000 makes rewriting only portions of the application extremely difficult. It would be necessary not only to rewrite the application but also to re-architect it, not only from a development perspective but also from the perspective of deployment and administration. If instead the decision were made to migrate the application not to Orbix 2000 but to the Borland Enterprise Server, VisiBroker Edition, re-architecting could be performed more gradually. While the Borland VisiBroker product and the IONA Orbix product historically have had many of the same vendor features, Orbix 2000 represents a significant departure from that trend. The VisiBroker Edition maintains many of the same features that have persisted in previous versions of this product. Hence, it is possible to upgrade an Orbix 3 application to the VisiBroker Edition by using comparable features rather than re-architecting the application all at once. 100 Enterprise Way Scotts Valley, CA Made in Borland Copyright 2001 Borland Software Corporation. All rights reserved. All Borland brand and product names are trademarks or registered trademarks of Borland Software Corporation in the United States and other countries. CORBA is a trademark or registered trademark of Object Management Group, Inc. in the U.S. and other countries. IONA and Orbix are registered trademarks of IONA Technologies PLC and/or its subsidiaries. All other marks are the property of their respective owners