| There may be times when integrating data across disparate systems requires structure-level as well as content-level transformations. For situations that require content-level transformations, where external data caches or relational database systems contain the necessary replacement data, a cross-reference lookup function is required to extract the appropriate data from the external source and use it to replace or enrich the document with its results. These high-level requirements can be satisfied by a single monolithic transformation service or by constructing two loosely coupled, autonomous services. The latter approach, which is better suited for service-oriented architectures, will be explored in this section. In a typical transformation, XSLT and XPath are essential ingredients in XML-to-XML transformations, where the underlying engine parses and transforms the structure of a source XML document to that of the target. XSLT also provides prefabricated functions to manipulate strings and numeric values (e.g., Substring, Concat, and Sum) as well as offering the ability to write XSLT extensions that can then be used as part of an XSLT transformation. One particular extension can contain JDBC and SQL logic to access external stores such as an Oracle database (Figure 11-6). These are executed at runtime to perform lookup and replacement functions to satisfy content-level transformations. Although this design will work in most situations, it simply will not scale in midsized to large projects for several reasons: The XSLT is tightly coupled with JDBC, hindering reusability. XSLT extensions are processed as external callouts from a data-driven, callback-oriented parser. This can create a scoping and initialization problem, which makes it difficult to take advantage of common JDBC features, such as connection pooling, and to be able to create reusable service types that can be supplied with configurable runtime parameters. XSLT extensions can be difficult to debug and test, requiring redeployment of new classes and JAR files when changes are made. XSL alone is more dynamic.
Figure 11-6. Transformation service combining XSLT and database lookup 
Contrast this all-in-one approach to writing a composite process that consists of two autonomous services (Figure 11-7). This can be designed and developed to satisfy the requirements in a much more elegant fashion one that fits nicely into an SOA model for mid- to large-scale projects. Figure 11-7. The two-step XRef pattern separates generic XSLT transformation with a JDBC database XRef lookup service 
The "Service Reusability" section of Chapter 7 explains the concept of reusable service types that can be instantiated with different configuration options. In this case, we have separated out the tightly coupled transformation service into two steps to separately address the problems of structure-level transformation and content-level transformation. Therefore, we can create two abstract service types that can expose configuration and runtime parameters that give each instance of the newly refactored services a unique identity. By breaking the solution out into two autonomous services, we can rapidly derive new instances of each service type. This promotes service reusability to cost-effectively solve other business problems that follow the same use case and require structure- and content-level transformation using similar techniques. Using this approach, even the database XRef service can be written once as a custom service type, and then customized with unique SQL statements as configuration parameters, as illustrated in Figure 11-8. Configuration parameters related to the database connection such the database name, JDBC driver information, username, and password can be configured. Configuration parameters that are supplied to the service instance are used to build, execute, and handle the returning result set. Figure 11-8. XSLT, XPath, and SQL statements are supplied to the service instance as configuration parameters 
By decoupling both XSLT and JDBC/SQL operations into their own service and using an ESB process to tie them together, we now have a more strategic and scalable solution compared to the previous approach. This provides us with the following benefits:
- A higher degree of code reusability.
-
A generic XSLT transformation service can be applied to other use cases. A generic database lookup service can be applied in non-transformation contexts as well.
- Accelerated development time.
-
This approach allows concurrent development of service types, simplifies debugging and testing, and provides better isolation overall.
- Faster database access.
The database access service can exploit JDBC 2.0 in order to leverage connection pooling for faster database access.
- Faster database access.
The database access service can exploit JDBC 2.0 in order to leverage connection pooling for faster database access.
- Loose coupling.
-
Problems that occur at the data access level do not affect XSLT operations. |
