Services at Canaxia

The following is a description of how Canaxia moved into Web services. The functionality that they chose to turn into Web services and the thought processes behind the choices.

Canaxia's SOA Analysis

The system architecture analysis done by Myles Standish indicated that several areas would benefit greatly from an SOA. The business drivers for the SOA implementation would be these:

• Save money by creating components from existing legacy applications and client/server functionality so that they can be integrated into the enterprise architecture.

• Make Canaxia agile by increasing architectural flexibility and by increasing the choices of how to provide a given functionality.

• Produce shared components for the software product line that Canaxia is building.

Given this architectural analysis, it was decided to implement a generic SOA internally and to begin the process of externalizing selected functionality as Web services.

Internal Services

The architecture team at Canaxia recognized the potential of SOAs and has implemented a generic SOA. As part of that SOA, the following services were developed:

• A set of technical services (including logging, reference, and the registry that is used to locate services)

• Security/trust service

• Financial reporting service

For these internal services, UDDI was overkill, so Canaxia has developed a simpler registry system. The registry operates as a service. Consumers connect to the service via a proxy object. The proxy object can be accessed via HTTP/S or by RMI/IIOP (EJB access). The proxy acts as a front to the actual service locating functionality. This registry functionality is implemented using the command pattern. The user creates a Canaxia data transfer object (CanData), builds the XML message that the CanData object will carry, and passes the CanData object and the fully qualified command name (package name plus name of service interface) to the registry service. The service interface that handles that particular command is located in the Canaxia command catalog, and the CanData object is passed to the module that is listed as implementing that interface. The consumer is now directly connected to the service and receives the data returned by it in the form of a CanData or a CanError object.

The Command pattern allows the consumer to issue a request and have the command interpreter locate the proper receiver of this request and pass the request to it. All details of how the command is executed and who executes it are hidden from the requestor (Gamma 1995).

The Canaxia registry implementation allows the dynamic linkage of service consumer with service provider, as is required for an SOA. When it is desirable to change the physical location of the service or the module that implements the service interface, the change is completely transparent to the consumer.

In addition to the registry service, a logging service was developed. Previously, each development area built its own logging mechanism, with varying levels of quality and functionality. This unruly set of logging solutions impeded the development of a software product line for Canaxia. In addition, the multitude of formats for log file entries made them useless as a systems monitoring resource. As a result, a logging service was developed and its use was mandated for all future development. Since quite a bit of effort was expended to make the new logging service easier to use than the existing logging objects, developers readily adopted the new service and even did some limited retrofitting of it to existing code. In several areas, being able to mine logging information was considered crucial, and these applications were rewritten to use the new logging service.

The registry service was created to provide in-memory access to configuration data. The configuration data are contained in a set of XML files, which are read at startup and reread when a change in them is detected.

A file system resource adapter was developed for the logging service. This resource adapter encapsulates all the details of writing the logging entry to the file system. The first-pass implementation of this service is multithreaded, formats the logging information into XML, and logs everything to a central server.

The security service encapsulates the existing set of Canaxia security applications. Access is via a proxy. The HTTP adapter allows external businesses to obtain credentials from the Canaxia security service. The beefed-up authentication of HTTP v1.1 is required by the security service, which is why the Canaxia HTTP adapter was developed for that version. Most Canaxia applications are J2EE and they use the RMI/IIOP adapter to access the security service.

The financial service encapsulates access to the data warehouse developed for financial reporting. As noted in Chapter 1, the data necessary for generating quick financial reports is mandated by SEC Order 4 460. It utilizes the existing transport adapters. On the back end, a JDBC resource adapter was created to extract data from the data warehouse, and database connection information is obtained from the Reference Service.

The choice of what functionality to move into the SOA came out of a matrix of the business priority, architecture priority, development risk, and effort. The business driver for moving the logging functionality to the SOA was to improve systems management by mining log files for error conditions and alerts. Because the security service touched so many other parts of Canaxia's application ensemble, it had a high business and architectural priority. The choice of the financial service for the first round of development was driven solely by the fact that this was a very high business priority.

Web Services at Canaxia

Canaxia has a long-range plan to integrate its supply chain via Web services. However, the current immature state of Web service standards precludes the publishing right now of any Web services by Canaxia.

Canaxia will be proceeding with a low level of Web service development. The initial plan calls for the creation of a Web service that allows visibility into Canaxia's vehicle inventory and that can produce figures outlining current vehicle consumption patterns.

The decision has been made that the Canaxia Web service registry will be UDDI compliant. It will be built and owned by Canaxia.

Internationalization

Canaxia is an international company with business units in many countries. The ability of different business units to operate in their native languages is vital to the smooth operation of Canaxia. Therefore, all Canaxia applications have to be internationalized, and any SOA for Canaxia must support effective internationalization. Internationalization is handled on several levels. For the presentation layer, Canaxia follows Java and J2EE standards in that all the messages and labels presented to the user are in resource bundles. The localization setting on the user's workstation brings up the proper language resource bundle to use for the UI.

The UDDI-compliant Web services registry that Canaxia will create for locating Web services takes advantage of the fact that consumers can specify a language when searching for a binding Template from the registry.

UDDI registries organize data pertaining to services, at least in part, with binding Templates. See McGovern et al. (2003) for more detail.

In addition, XML tags can have a language attribute. Therefore, the XML data generated from Canaxia locations in the Caribbean specifies Spanish as the language for the tags. If the locale specified for the computer displaying the data is not Spanish, a translation of the tags is performed.