XSLT Service Engine
XSLT Service Engine enables transformations of XML documents from one format to
another using XSL stylesheets. The service engine allows XSL transformations to be
deployed as web services which can then be used by external clients.
New XSLT modules can be built to run against the XSLT service engine by selecting
the File | New Project menu option and then selecting the XSLT Module option
from within the SOA category as shown in the following figure:
Several different types of files can be created within an XSLT Module to allow the
service engine to transform XML files from one format to another. XML Schema files
can be used to define XML within the transformation process. WSDL files are used
to define the operations that are transformed within the service engine. We won’t
discuss how WSDL files and XML Schema files are created and maintained in this
chapter, however, we will discuss them in full detail later in this book.
The final type of file that can be specified within an XSLT Module is an XSLT
Service. These types of files can be created by right-clicking on the XSLT Module
within the Project explorer in NetBeans and selecting the New | XSLT Service menu
option. The result is shown in the next screenshot.
When creating an XSLT Service Unit, two different processing modes (Service type)
are available:
- Request-Reply Service
- Service Bridge
The Request-Reply Service mode enables an XML message to be received from a
client, transformed, and then sent back to the original client.
The Service Bridge mode enables an XML message to be received from a client and
transformed into a different format. The transformed message is then used as an
input for invoking a service. The output of this service is then transformed using a
second XSL stylesheet and returned to the original caller. The Service Bridge mode
is therefore acting as a bridge between two services. This is an implementation of the
Adapter Pattern as defined in Design Patterns—Elements of Reusable Object-Oriented
Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
When creating a Request-Reply Service, the New XSLT Service wizard allows the
web service for the XSLT transformation to be specified including details of the port,
the operation being executed and the input and output types of the operation as
shown in the following two screenshots:
When creating a Service Bridge service, the two web services to be bridged are
specified by first selecting the WSDL for the implemented web service and then for
the invoked web service.
Having selected the web services to bridge, the wizard allows the implemented and
invoked web services to be fully specified. Here we need to specify the operation
from our implemented service and the operation to call on the invoked service.
Summary
In this chapter, we have introduced the concept of a Service Engine and given
an overview of the Service Engines installed with the NetBeans Enterprise Pack
(the BPEL, Java EE, SQL, IEP, and XSLT Service Engines). We’ve learned that
Service Engines:
- provide business logic functionality to their clients
- can be consumers and/or providers
- run within a Java Business Integration (JBI) Server
- expose their interfaces via WSDL
- communicate within an Enterprise Service Bus via messaging
We’ve also discussed some basic concepts about JBI such as the Normalized Message
Router, Service Assemblies, and Service Units. We have a good understanding of
JBI, some of the problems with Enterprise Application integration and why JBI is
useful. In the next chapter, we extend our knowledge of JBI and SOA application
development with NetBeans by describing another standard JBI component—the
binding component.
October 8, 2009
SOA