INTRODUCTION

So far, we have spent a great deal of time in covering the reference architecture for business services orchestration, and defining the necessary methodology and the underlying technologies that make it possible to orchestrate business services. The actual development process for coming up with orchestration sequences is covered in the methodology section. Additionally, methods and processes, such as the Unified Process from Rational, are also a great source for going through the modeling process. This chapter devotes itself to the key concepts that need to be modeled. We talk about the necessary components of a BSO, which need to be visually rendered through a BSO notation and need to be captured by a BSO specification language (BSOL).

BSOL captures the protocol that the collaborating systems need to follow in order to interact with each other in a meaningful business manner. In a typical BSO scenario, there are many business services. These services have their public interfaces, which may have been captured by a specification language such as Web Service Description Language (WSDL). The orchestration of these services is all about how these services interact with each other in a state-full manner, typically in long-running business transactions. A buyer may send a purchase order to a seller. The seller may take several days to fulfill the order and then send an invoice back to the buyer. Although the buyer and seller services have their interfaces, the protocol defines the order in which those interface operations can be invoked.