Flexibility and policy schema

Although an internal orchestration structure is initially created by utilizing an instance of the orchestration schema, it is possible to alter the sequence while the execution continues. The modification of an execution is permissible unless the rules

83

defined in the schema are not ignored. In other words, an individual flow sequence can be assembled for a specific message if the new path does not contradict to the instance of policy schema. However, the modification may not be suitable for some circumstance. Additionally, there might be some other restrictions for the modification even if it is allowable by the schema.

The alteration of the internal orchestration entails additional controlling mechanisms. Even though the adaptability is an excellent feature so that the system offers a flexibility to build individual message flows, the policies should be enforced to apply the limitations and the boundaries to precede the correct flow sequences. Some handlers may process any type of messages arriving to the system without causing any complication. Yet, the others may not be appropriate to be executed without restrictions. There may be a necessity for a compulsory sequence among some handlers. For example, an encryption should be processed at the beginning so that the remaining handlers can understand the message content. Therefore, while the new sequence is created from the available handlers on the fly, the policies have to be kept in mind.

Hence, we come up with another XML Schema to define the policies; see Appendix B. A policy file may contain many descriptions. They define conditions to carry out the execution without having an accident. We choose any type for the description element to allow describing any kind of policies. Some definitions may be optional although some others must be compulsory. The schema also defines an important element to describe the orders among the handlers. The policy may comprise of many ordering elements to force the necessary restrictions. Moreover, it contains the

84

orchestration schema file name and its version to let the system know where the policies need to be applied.

4.7

Summary

Orchestration is a significant feature to collaborate the distributed applications. Handlers are the key components of Web Services. Dissemination of the handlers to have efficient and effective SOAP message execution requires a well-organized orchestration. We introduced the separation of description from the execution in the orchestration mechanism for this purpose.

The separation has many benefits. First of all, it offers very efficient and effective flow engine while it is providing very powerful expressiveness in the description. Weighting between the simplicity and the efficiency is always an issue. Without sacrificing the efficiency, acquiring simplicity is very challenging.

Secondly, the separated mechanism provides an advantage to be able to get support from Petri net model that offers proven mathematical and flow model. The description document can facilitate a visual workflow system for the simulation. Many visual workflow tools have been introduced so far. They can be the supporting tools to analyze the orchestration in many conditions. The orchestration document comprises of enough expressive power to verify and analyze a deployment by using the model. While we are building the orchestration, we care the compatibility feature with the Petri net so that the flow mechanism can be converted to this model. Moreover, applying the orchestration document to Petri net model supports the correctness of the flow structure with the mathematical model. It is very constructive in order to fortify an empirical system with a theoretical approach.

85

Last but not least, the separated mechanism can help us to be able to build a static, semi-dynamic and dynamic handler distribution mechanism. DHArch utilizes predefined handler setup. Handlers and their sequences are described by an XML document, an instance of DHArch Orchestration Schema. This is a static handler deployment. The orchestration engine interprets the document, creates and executes the sequence.

Moreover, our approach allows to build semi dynamic handler execution mechanism. The handler sequence can be optimized on the fly. The predefined sequence can be altered via introducing parallel execution among the appropriate handlers or rearranging the order. This arrangement must be controlled by a policy document, an instance of DHArch Policy Schema. While the sequence is being altered, the policy document imposes the rules to enforce the modifier to obey the dependencies. Hence, the handler orchestration sequence is modified without breaking the rules defined in the policy document.

Finally, the more appealing but complex mechanism, fully dynamic execution, can be built. The handlers and their sequence are resolved by DHArch. When a message has arrived, the system looks at the context and decides the required handlers and runs them in ad-hoc manner. It can check whether they can be executed parallel or not. It decides which handler should be executed first and so on. This mechanism requires very complicated module, an agent base system.

86