Java Reference
In-Depth Information
processes change, and versioning or updates can become difficult. You may find that the ap-
plication is “chattier” than you want between client and server as well, and it would be nice if
you could reduce some of the load on that part of the network and move it to the server where
you can balance things better and distribute the load.
In order to address these problems, you might then think to move the flow logic into a wrapper
service that can be used on the server side. This service could act as the use case director, ex-
pose a WSDL that the client communicates with, and that service could define all of the steps
in the flow. This is closer to what you want, but it bakes the logic into a platform-specific lan-
guage, such as Java, making the process less transparent, and it puts the responsibility for the
process firmly in the hands of the developer. If you want more robust features of workflows,
such as parallel execution and correlation, you have to home-grow a complex threading mech-
anism to handle it. You are also dealing with the messages in a platform-specific manner, that
is, in Java code, and not in their raw XML format. This can have performance benefits that
may be required in some cases, but it also takes you further away from the fundamental goals
of SOA, highlighted earlier. You are suddenly spending more time dealing with your platform
than we are solving business problems.
What you really want is a way to express the flow in the language of the business, something
that is sufficiently abstract and catered more to analysts and architects. Such a language could
be expressed visually and easily, but ultimately be exposed as a WSDL and execute on the
server so that it's invokable as a service. What you want, in the world of SOA, is called an
orchestration. And orchestrations are often executed using BPEL, or Business Process Execu-
tion Language.
Let's look at a slightly different example to tie all of this together. Imagine you have defined
a small catalog of web services for the following tasks:
▪ A service that allows HR to modify employee data in your payroll system
▪ A service that captures signatures on a reader device used in your retail stores
▪ A service that wraps communication to and from a benefits provider
These services can operate independently in different areas of your business, under different
problem domains. Each of them fulfills its function appropriately and is self-contained. But
consider how they might be combined as a composite service for handling new hires in your
company. You could create a new process that indicates each step required for employee in-
take: adding someone to the payroll system, having them sign a variety of HR documents by
capturing their digital signature, and passing the necessary collected data to the benefits pro-
vider service to get the new hire set up with insurance or 401K enrollment. The process would
indicate the order in which each service should be invoked, and how to respond to different
messages. For example, you might want to invoke the benefits service only if the employee
