Java Reference
In-Depth Information
Chapter 9. Service Orchestrations with BPEL
Introduction
In previous chapters, we've seen how to build well-formed web services. Services represent
the basic building blocks of a service-oriented architecture. But by definition, a well-made
service must be loosely coupled from other services. It must, in general, leave routing logic
up to an external component such as an enterprise service bus. The real promise of SOA is
not realized by building services alone, but by defining clear services with high cohesion, that
wholly describe their interactions and that are then capable of being reused, through compos-
ition, in a variety of process-based services.
The key design principles of SOA include:
▪ Loose coupling, which means that a change to one component results in minimal or no
change to other related components.
▪ Interoperability, which builds on the idea of loose coupling to suggest that services should
be able to exchange messages with other services, even if they are implemented in differ-
ent languages and their platforms differ dramatically.
▪ Reusability, which means that more than one application can act as a client of your service
without resorting to internal service changes. Services must be autonomous, or capable
of running independently, and be designed in logical divisions that fully encapsulate their
business logic.
▪ Discoverability, which means that a service's execution environment and contract allow it
to be looked up, bound to, and invoked at runtime.
These goals are interrelated, so fulfilling one or two of them usually gives you a head start
on fulfilling the others. At this point, you know how to create a single service that can be in-
voked by one or more clients, such as a website or point of sale system. But what about more
complex systems that require invoking multiple services? If the client is your point of sale
system, and you need to create a workflow surrounding an invoice, you are immediately faced
with the choice of where to put the flow logic. Your first thought might be to bake it into the
client system itself. But that process cannot then be captured very easily as an abstraction; it
encourages tighter coupling between the client and each service it invokes in the flow. If you
later create another point of sale-like system, say one that works from a handheld device or a
website or even a lighter version of the system that can be used out in the field, you have to
recreate that work. Moreover, such a strategy begins to undermine the whole point of using
web services in the first place. Flow logic is likely to grow or change somewhat as business
