Service Oriented Architecture
Business people and software engineers have different expectations about a modeling language, which therefore have to meet a lot of diverse requirements. Business analysts expect an easy-to-use graphical environment where they can define the order of business activities with from a low to a high granularity. On the other hand, software engineers expect a fine-grained model, where each task or service has its on deployable and runnable software component with a well-defined software interface.
The meeting point of these two perspectives is the Service Oriented Architecture (SOA). In the SOA each atomic business task such as filling in a form or posting a mail is implemented as a single software component called service. There may exist compound services that perform atomic tasks in a predefined order. All services are published in a catalogue, from which a compound service can look up a service that can perform one of its atomic task.
In business collaboration, services of a business use the services of another business based on a contract. When modeling these interactions, we are talking about service orchestration, if we place ourselves in either business’s point of view and observe the internal behavior of that service, and we are talking about service choreography, if we place ourselves outside of the concerned businesses and just observe their interactions.
Each service has its own interface, and therefore, for a successful collaboration of services a uniform language is required in a SOA domain that describes the task performed and gives the format of input data necessary to execute the task and the format of output data produced. E-business modeling languages provide the means to define such contracts.