The MONET Broker Yannis Chicha, Manfred Riem, David Roberts (Editor) The MONET Consortium

Transcription

1 Task: 3.1 Version: 1.0 Date: March, 2004 The MONET Broker Yannis Chicha, Manfred Riem, David Roberts (Editor) The MONET Consortium c 2003 The MONET Consortium (IST ) D16-D18 (Public)

2 Abstract The broker is the central component of the MONET framework. Features of discovery based on semantic information, composition of services increasing the flexibility of the system, and automatic execution to ease the process of service invocation, are all handled by the broker. In this document, we describe the architecture of the MONET broker with all its components. We present each of them and explain how they can be used. Furthermore, we describe ways to extend their functionalities to help further developments. The MONET Broker (Task: 3.1) ii

3 Contents 1 Overview Goals Client Manager Registry Manager Planning Manager Composition Plan language Planners Execution Manager Broker: architecture and usage Global architecture Client Manager Architecture Usage Registry Manager Recording services Using the instance store as a back-end External interface Exception handling Usage Planning Manager Plan language Planners Structure and connections Page 1 of 20

4 2.4.4 Exceptions Usage Execution Manager Architecture Usage The Broker API Client Manager Registry Manager Planning Manager Planners Plan resolution Plan language Execution Manager The MONET Broker (Task: 3.1) Page 2 of 20

5 Chapter 1 Overview The MONET broker is an essential component in the MONET framework. Its purpose is to provide clients with means to solve the problems they submit. The broker can also perform the necessary actions to obtain the solutions to these problems. This document is articulated around three chapters, Chapter 1 presents different aspects of the broker in a general way, providing highlevel descriptions of its features. Chapter 2 details the architecture of the broker and describes how each of its components can be used and deployed. In terms of deliverable, this chapter corresponds to D16. Finally, in Chapter 3, we explain in what ways each part of the broker can be extended. This corresponds to deliverable D18. Let us specify that both deliverables are part of the same document because the software developed for D16 already matches the specification of D18: the broker is a combination of web services rather than a monolithic piece of software. In this context, a single document providing high-level information, detailed architecture, and extension possibilities, seems appropriate. 1.1 Goals There are two main goals for the broker: discovery of services and invocation of services on behalf of a client. Discovering services to solve a problem is supported by three elements: Registry Manager, Service Matcher, and Planning Manager. Invocation of services is supported by the Execution Manager. Details about the components follow. 1.2 Client Manager The Client Manager is the front-end Service of the broker. It is course-grained, providing all the operations that are required by clients of the Broker. All operations are forwarded to either the Planning Manager, the Execution Manager or to the Registry Manager depending on the service requested as shown in the diagram: Page 3 of 20

6 Currently, authenticated clients are responsible for registering services, in future services may be allowed to register themselves given an appropriate authentication and authorization architecture. 1.3 Registry Manager The Registry Manager is used by the broker to allow services to publish their descriptions. Its role is to record the descriptions to allow the Service Matcher to find the services given a query. For more details about Service Matching, please refer to [3]. 1.4 Planning Manager The Planning Manager allows the composition of services to solve mathematical problems. The idea is that a query received by the broker from a client may not be matched by the Service Matcher. The Execution Manager executes plans created by the Planning Manager. In this section, we briefly present the concept of composition and requirements for our composition language. More details on the topic of composition for mathematical services can be found in [5], [6], and [7] Composition We call composition of services a mechanism to combine such services in order to achieve a given goal. We call plan such a composition, a plan in the MONET framework is different from plans in AI planning (use of such techniques for semantic web services composition is being studied by several people, but no conclusion has been reached yet, see [4] for example). In our case, a plan is rather a script, an algorithm similar to Maple procedures. Typical users do not wish to simply invoke one routine performing one computation. A more realistic use case would be to allow users to express a sequence of computation combining several services. In our framework, composition is an alternative or rather a complementary tool to service discovery: The MONET Broker (Task: 3.1) Page 4 of 20

7 whenever a service is not available, a composition of services may solve the submitted problem. Composition is thus essential to using web services in the context of mathematics Plan language In order to compose services, a plan language proves necessary. The reason is that services can not just be invoked in sequence transmitting values along the way. More subtle operations should be supported such as conditional expressions, loops, and so on. There are currently several composition languages to choose from (BPEL [1], WSCI [2],... ). Unfortunately, it is difficult to know what language will actually become a standard. Consequently, one can not rely on one formalism or another and we decided, for the time being, to produce our own language inspired from BPEL. The goals for this language are: independence: if the specification of a given composition language changes, we should not have to reflect it in our tools. simplicity: the translation with BPEL should be straightforward, thus allowing the use of existing tools (e.g. IBM s BPWS4J [9]). flexibility: our language should be flexible enough to allow the translation into a number of target languages. One possibility would be to use a computer algebra system such as Maple [12] to execute plans Planners Typical planners are simple services providing access to databases storing plans and using problem names as keys. Although simple, it is likely that this type of planner would be most common in a real-life setting. More sophisticated planners analyzing the query could be imagined, however dynamic creation of plans through deductions made from a query are very hard to do. This type of planners remains rare. 1.5 Execution Manager The main responsibility of the Execution Manager is to deliver an environment in which mathematical plans written in the MONET plan language, a subset of BPEL, can be executed. The Execution Manager is a component of the MONET architecture, more precisely it is a slave component to the Client Manager that asks for execution on behalf of a client. The result of the execution of a plan is returned to the client as a document written using the mathematical explanation language described in []. The simplest plan consists of a single call to a mathematical webservice of which the location is known. More elaborate plans involve sequences, conditional statements, loops and may result in several calls to different mathematical web services. In this way, a plan may be seen as an abstract description of a new mathematical web service in terms of available services which are used as building blocks. For example, a plan describing the Euclidean algorithm only needs a service computing the remainder in order to be viewed as a service for the computation of the greatest common divisor. The Execution Manager described in this document is implemented as a web service. The MONET Broker (Task: 3.1) Page 5 of 20

8 Chapter 2 Broker: architecture and usage 2.1 Global architecture The Monet Broker implements a Service Oriented Architecture (SOA) using Web Services that communicate via the HTTP protocol. SOA relies on each component service being independent of the other Services. A reasonable definition of a Service is: A Service is a function that is well-defined, self-contained, and does not depend on the context or state of other Services (service-architecture.com) All component Services are entirely independent of each other and are even unaware of the existence of the Broker. The Broker is the only Service that knows about other Service components, it uses combinations of the other Services to offer front-end operations which are useful to users and applications. These operations might typically be solve this problem, register this service or submit a plan to solve a particular type of problem. The SOA architecture of the Broker makes it highly extensible, if the Broker needs to use a new Service it can do so without affecting the existing Services: new services can be added as and when they are needed. For example, the Broker currently authenticates web clients against an internal database of users, if we wanted to use a Service for authentication and authorization instead this could be done without affecting its existing services. The Broker holds no permanent state, in essence it acts as a proxy chaining Services together. However if, for example, clients want to store the intermediate results of a submitted problem the Broker can also return these results as well as the solution. The way the Broker connects Services and proxies intermediate results can be seen in figure 1.1: Page 6 of 20

9 Figure 2.1: The Services and Protocols used by Monet Broker For example, the Steps involved in solving a problem would be: 1. The Client requests: solve problem and submits an MSQL query. 2. The Broker forwards this document to the Planning Manager, which forwards it to the Service Matcher. 3. The Service Matcher translates it into the DIG formalism and runs its engine. 4. The Planning Manager receives a list back from the Service Matcher and makes an MSPL plan out of it. 5. If the result is an empty list then the Planning Manager invokes a Planner and tries to find a plan that way. 6. The resulting plan is returned to the Broker, this plan is returned to the client if intermediate results where requested. 7. The Broker forwards the plan to the Execution Manager which executes the Services according to the plan. 8. The Execution Manager returns a solution or an error message to the Broker in MEL format. 9. The Broker sends the resulting MEL to the client. The MONET Broker (Task: 3.1) Page 7 of 20

10 2.2 Client Manager Architecture The Client Manager is the Web Service that the Broker provides to clients wanting to perform operations such as solve this problem, register this service or submit a plan to solve a particular type of problem. The architecture of the Client Manager is the architecture of the Broker Usage A Web Application has been developed which demonstrates the services provided by the Broker. Both the Broker and its associated Web Application can be downloaded from Monet CVS [13], under the broker module. At the time of writing a version of the Web Client is available at A typical usage scenario for the Web Client would be: 1. Login using user=system, password=manager. 2. Select Manager Service from the side links and then Select Register Service 3. Example services (msdl files) and queries (xml files) can be found by following the link to example files at the bottom of each page after logging in. 4. Register an MSDL service using any of the input options - url, file, cut and paste. 5. The URL of the registered service should be returned once registered - save this URL to do an UnRegister operation later. 6. Select Solve a Problem from the side links (a) - Select the option Return a list of services from the 3 options (NB THIS IS NOT THE DEFAULT OPTION) (b) - Select the method of input URL, File, Cut and Paste. (c) - Submit the query. - if there is a match for the query (the nag*.msdl and nag*.xml files in example files described above in 3 should return a match) the URL of the match is returned. 7. Select Manage Services from the side links and then Select UnRegister Service. 8. Enter the URL saved above in Enter the same query as in 6, no service URL should be returned. 10. Try variations on the above, try creating MSQL using Create MSQL option and submitting MSQL to return a solution. 2.3 Registry Manager The Registry Manager is available as a web service. Its purpose is to register capabilities of mathematical web services. The MONET Broker (Task: 3.1) Page 8 of 20

11 2.3.1 Recording services To register a service, one needs to send the corresponding service description expressed into the Mathematical Service Description Language (MSDL). This MSDL document should contain WSDL information. In particular, one needs to be able to find the URL of the service to register. To do so, the Registry Manager can download the WSDL document using the URL provided as an attribute of the service-interface-description element of the MSDL document. If the URL is not available, then WSDL information should be provided inline in the service-interface-description. The URL of the service is the key to record MSDL descriptions. When one registers a service, the provided MSDL document is recorded in a web accessible location for the Execution Manager to download as needed (see Section 2.5) Using the instance store as a back-end In the current implementation, the Registry Manager does not interpret the MSDL document. That is, no information is extracted from the service description for future exploitation by the service matcher to locate services with respect to a query. The role of the Registry Manager is rather to offer a front-end for the Instance Store (see [10] and [3]) and to record the actual MSDL document. The Instance Store provides the actual reasoning power of the broker for service discovery. For convenience, the Instance Store is exposed as a web service. This back-end takes OWL descriptions as input, that is why the Registry Manager also has the task of translating the provided MSDL document into OWL input. This is done using an XSL stylesheet available from the MONET CVS repository (see [13]) External interface The external interface of the Registry Manager is quite simple, as it only exports two main functions: register and unregister. interface Registry Manager { String register(string msdldocument); boolean unregister(string uri); } Exception handling There are several cases for error reporting in the Registry Manager: Properties not available. Properties are very important to the Registry Manager. If they can not be accessed either because the file is not accessible or because one of the properties was not provided, an exception is raised. Without all the properties values, the Registry Manager can not work properly. Problem at the Instance Store. Because the Registry Manager is only a front-end for the Instance Store, errors at the Instance Store level become errors at the Registry Manager The MONET Broker (Task: 3.1) Page 9 of 20

12 level. An exception is raised and detailed information is logged if anything happens at the site of the Instance Store. Note that the exception raised by the Instance Store is not transmitted to the client but logged at the location of the Registry Manager. The only information sent to the client is that a problem occurred with the Instance Store back-end. It is up to the Registry Manager administrator to take care of the problem possibly by contacting the administrator of the Instance Store. Recording impossible due to local filesystem problem. In case local IO errors occur when recording the MSDL document, an exception is raised. There are also normal responses made in the form of exception raising: at registration time: Service already registered. If the URL of the service was already registered, this exception is raised. Updates are currently not supported and the only solution is to unregister first and re-register the service. at unregistration time: Service not registered. Obviously, if the service one wants to unregister is not registered, the client should be informed of the situation Usage We briefly describe here the usage of this package. More details are provided in the README file of the distribution. The registry manager was tested with Java and Java 1.4.2, Tomcat and Tomcat , Axis 1.1, and JWSDP 1.3. It may not work with other tools. There are two distributions: binary and source. The binary distribution comes as an example of properties file, a couple of XSL files and a WAR file. This means that a web application server should be used to run the service. We recommend Tomcat as this is the server we used for our development and tests. The source distribution contains all the sources and scripts to easily create the WAR file that can be used to deploy the service. The installation process is very simple: install a web application server (Tomcat), drop the war file in the webapps directory, provide appropriate values in the properties file, and start the server. 2.4 Planning Manager The Planning Manager finds and resolves plans solving problems for which no service could be found by the Service Matcher. As for the other components of the broker, it is available as a web service. Plans manipulated by the Planning Manager use a specific, algorithmic-like language Plan language The plan language used by the Planning Manager is similar to an algorithmic language. It is described by an XML Schema document available in the distribution. The language currently supports the following instructions: sequence, to describe a sequence of instructions. The MONET Broker (Task: 3.1) Page 10 of 20

13 parallel, to specify instructions that do not have to be executed sequentially. while, for loops. cond, for conditionals. Note that if expressions can be expressed using a cond. return, to return a result to the client. invoke, to invoke a web service. assign, to assign a value (often a result of an invocation) to a variable. Furthermore, it supports general parameters (typically the same parameters as the problem solved by the plan) and local variables. A plan may have three states: abstract, unresolved, resolved. In its abstract version, a plan does not have any notion of web service. It is simply a document in the form of an algorithm describing a way to solve a problem using URNs to refer to sub-problems. A resolved plan is an abstract plan for which all invocation steps (that is, all steps where a computation was specified) have been associated to one or more web services. Finally, an unresolved plan is a plan in which only part of the invocation steps have web services associated to it. Note that an abstract plan is a special case of unresolved plan Planners In our prototype, we created a repository planner. Such a planner is a real web service that can be invoked by any number of Planning Managers. Consequently, a planner does not have to be deployed at the same location as the Planning Manager. Furthermore, through the planners_url option in the properties file, the administrator of the Planning Manager may specify several planners to use when looking for a plan. This allows the Planning Manager to increase the possibility of finding a suitable plan to answer a given query Structure and connections The Planning Manager plays the role of the middle-man in the MONET architecture. This web service is part of the MONET broker. The Planning Manager is responsible for finding one or several strategies to obtain solution to a given query. The query is transmitted by the Client Manager. The first action taken by the Planning Manager is to find out whether a single service can solve the problem directly. To do this, it contacts the Service Matcher, which analyzes the query and tries to find a corresponding service. If a service is found, a one-step plan is dynamically generated. If no service is returned from the Service Matcher, the Planning Manager interrogates its planners. If no plan is found, then an empty plan is returned to the Client Manager. Otherwise, plans obtained from the planners are analyzed and, by contacting the Service Matcher, each invocation step in each plan is associated with a list of services solving the corresponding subproblem. This last action is called resolution. Plans for which all steps have been resolved are called resolved plans. Typically, when submitted a query, the Planning Manager returns a list candidate resolved plans. It is up to the client to select which plans to execute. There is no direct connection to the Execution Manager although this entity executes plans generated by the Planning Manager. This is because the Client Manager handles itself the client s requests and the communication between the different entities of the broker. The MONET Broker (Task: 3.1) Page 11 of 20

14 2.4.4 Exceptions Planner In general, exceptions are raised when the properties file of the planner is not accessible or when required properties are not available. There are other causes for raising exceptions. First, our prototype of planner includes operations to register and unregister plans dynamically. Exceptions are raised when a plan can not be recorded or removed on the local filesystem. The primary purpose of the planner being to fetch and serve plans, exceptions are also raised when a problem occurs with the back-end (XML file storing all necessary information) fails in some way (usually because of possible failures of JAXB, which is used to implement this back-end). Planning Manager There are two types of exceptions in the context of the Planning Manager: failure of contacts with the Service Matcher and general exceptions. Service Matcher. Contacting the Service Matcher is essential for the Planning Manager, because this is how plans are resolved. Exceptions are raised when an exception is received from the Service Matcher. Miscellaneous. This includes any kind of exceptions occurring once: invalid submitted query, problem with properties, and so on Usage We briefly describe here the usage of this package. More details are provided in the README file of the distribution. The registry manager was tested with Java and Java 1.4.2, Tomcat and Tomcat , Axis 1.1, and JWSDP 1.3. It may not work with other tools. There are two distributions: binary and source. The binary distribution comes as three WAR files: planner alone, planning manager alone, both planner and planning manager. In the distribution, there are also examples of properties file for the planner and planning manager. WAR files mean that a web application server should be used to run the services. We recommend Tomcat as this is the server we used for our development and tests. The source distribution contains all the sources and scripts to easily create the WAR files that can be used to deploy the service. The installation process is very simple: install a web application server (Tomcat), drop one of the war files in the webapps directory, provide appropriate values in the properties file, copy the XSL file at a chosen location (specified in the properties file) and start the server. 2.5 Execution Manager This section is separated into 2 parts. The first part describes the architecture in a general manner. The second part describes how you can use the Execution Manager as a standalone web service. The MONET Broker (Task: 3.1) Page 12 of 20

15 2.5.1 Architecture The architecture of the Execution Manager is described in the figure below. MPL XSLT Jelly Jelly Engine MEL Jelly Extensions As the figure above makes clear, execution of plans by the Execution Manager is done in two major steps: 1. Convert the MPL to a Jelly script 2. Execute the Jelly script on the Jelly engine and return MEL In the picture you also see references to Jelly [11] extensions. These extensions make it possible for you to extend the capabilities of Jelly. One of the extensions written for the current implementation of the Execution Manager is the extension that allows you to call a web service Usage Although the Execution Manager is a component in the Monet Architecture it can also be used on its own. The picture below show you what the integrated web client looks like after executing a plan. The MONET Broker (Task: 3.1) Page 13 of 20

16 Chapter 3 The Broker API This chapter corresponds to the deliverable D18 and presents the components of the broker with the point of view of extension. The descriptions here explains how and in what way each component of the MONET broker can be extended. The MONET broker itself is easily configurable and extensible in a dynamic way through the use of web services for its components. 3.1 Client Manager The Client Manager provides the following service API. The services break down into three groups: services to return a plan, services to register/unregister a service and services to execute a plan. A client application that wants to offer a solve service would do so by chaining the findplan service with the executeplan service. /** * Takes a query expressed as an MSQL string and returns a plan * expressed as a MSPL string. This string can be parsed to discover * what options the client has to solve their mathematical problem. * msqlquery - a query expressed in MSQL. an unresolved (generic) MSPL plan. */ String findplan(string msqlquery); /** * Transforms an abstract(unresolved) plan in MSPL into a resolved plan in MSPL. * MSPL - the abstract plan. - the resolvedplan in MSPL. */ String resolveplan(string MSPL); /** * Takes a resolved plan with parameters and executes it returning MEL Page 14 of 20

17 * expression (see 18A - The Monet Mathematical Service Response Ontology) * representing the solution to the problem. * resolvedmsplplan - a String which is a resolved plan expressed in MSDL. a String which is in MEL, the answer to the problem * or an error message. */ String executeplan(string resolvedmsplplan); /** * Execute a plan and indicate whether it should be resolved first. * returning an MEL expression (see 18A - The Monet Mathematical * Service Response Ontology) representing the solution to the problem. * plan - a plan that may be resolved or unresolved. resolve - whether this plan should be resolved. a String which is in MEL, the answer to the problem * or an error message. */ String executeplan(string plan, boolean resolve); /** * Register a service described in MSDL. * msdlofservice - the MSDL that describes the functionality provided by the * service being registered, it also contains the WSDL and (therefore) the URI of * the service that it describes. the URI of the service registered, which will act as a key for accessing * the service. */ String registerservice(string msdlofservice); /** * Removes the service URI from the service registry. * serviceuri - the URI of the service to be removed. boolean indicates the success or failure of the operation. */ boolean unregisterservice(string serviceuri); /** * Return MSDL as a String given the URL of the Service * url -is the URL of the service (which is the key to obtain an MSDL * document from the "database" managed by the Registry Manager) the MSDL as a String. */ public String getmsdl(string url); The MONET Broker (Task: 3.1) Page 15 of 20

18 3.2 Registry Manager This component is merely a front-end for the Instance Store (see [10] and [3]). It can be configured using its properties file, but very few extensions can be made. As the Registry Manager stores MSDL files, one could imagine an extension which would allow to add an operation to this web service to ask questions about the registered MSDL documents. In order to create that feature, a new method should be added to the RegistryManager file. It will also require to rebuild and redeploy the service, which can be done easily using the Ant makefile provided in the source distribution. In the current implementation, there exists a class called MSDLVerificator. Only basic validity checking is done at this level, further development could aim at handling complete MSDL validity checking at the level of the Registry Manager. This would be done before contacting the back-end Instance Store. Finally, another possible and useful extension would be to handle several back-ends. Currently, a specific Instance Store web service is used (although the actual service can be chosen by providing its URL in the properties file). The Registry Manager could use several back-ends (which could be Instance Store services or not) to cope with unavailabilities of services or to allow specialization of discovery with the Service Matcher. Current code of our prototype could easily be updated to handle a list of Instance Store services: we simply need to record the list of URLs that would be provided in the properties file. However, handling different types of backends is more cumbersome as this would involve the design of a protocol to register the MSDL document. Ideally, all back-ends would implement a given interface so the Registry Manager code does not have to be updated. Otherwise, a more awkward solution would be to provide the Registry Manager with a WSDL document including only one port type and one operation to call corresponding to registration. 3.3 Planning Manager We explain here how the Planning Manager can be extended for further developments of the MONET broker. There are several elements: planners, planning manager for resolving plans, the plan language itself Planners An important aspect is that, in the current implementation, one can easily add planners to work with the Planning Manager simply by providing their URLs in its properties file. This means that planners have to follow a common API with respect to the Planning Managers (note that a Planner can be used by several Planning Managers): it should export the findplan method. The prototype of this method in the current implementation is the following: String [] findplan(string problem) throws MonetPlannerException; Because planners are web services, one can extend the functionality of the Planning Manager simply by writing a new planner and adding its URL to the properties file. Note that this involves restarting Axis in our implementation to take the new value into account. We also remark that existing planners are completely independent from a new planner that would be added. The MONET Broker (Task: 3.1) Page 16 of 20

19 3.3.2 Plan resolution In the current implementation, the Planning Manager relies on an XML stylesheet to assign values from queries to the parameters of a plan. This means that, if any extension is required in the process of this assignment, extensions may occur dynamically without restarting the web service. The resolution of the invocation steps in a plan is coded in Java (in the class PlanResolver) and can only be extended by recompiling and redeploying the service. A future work on this topic would be to replace the PlanResolver class by an XML stylesheet. The difficulty resides in the invocation of the Service Matcher for each invoke steps found in the plan, because such call has to be handled in Java and the Xalan-connection showed a few problems that led to creating an all-java solution in this case Plan language In the context of composition, the element that is most susceptible to be updated is the plan language. In our prototype, this language is a first attempt at providing an algorithmic-like language for combining mathematical services. The purpose is to use it for observing and testing the way plans are created in practice. The result of this observation should lead to changing a few elements in the language. The plan language being available as a Schema, extensions are simple, and using an Java-XML binding tool such as JAXB makes it easy to propagate changes in the code of the Planning Manager. In particular, the plan language is manipulated by the Planning Manager at resolution time and when creating a one-step plan. That is, most of the work is concentrated on the invoke steps and the rest of the instructions are not manipulated. The creation of a one-step plan is made in the OneStepPlanCreator class and thus all corresponding modification would be concentrated at this location. Changes in the plan language will have more serious consequences for the Execution Manager which is responsible for translating the plan language into an execution language. In this case, the code of the translation module should be updated. The version of a plan (attribute version of the top element plan in the XSD document) can be used to handle evolutions more gracefully. However, the prototype does not currently support the handling of several versions. An interesting possible evolution would be to allow the creation of linear plans in which the input of a given step is the output of the previous one. The problem lies in the fact that these intermediate elements may not be known in advance and the problem to solve might not be known either. This is a generic plan different from the abstract or resolved ones mentioned in Section 2.4, because we do not know in advance the number of steps in this plan and there is no information as to what problems should be solved at each step (and, in particular, the types of input and output values). Currently, there is no support for this kind of plan either in the language or in the behavior of the Planning Manager. Future work should look into this very useful extension. The MONET Broker (Task: 3.1) Page 17 of 20

20 3.4 Execution Manager The API of the Execution Manager is given by its WSDL file as it is published as a web service. In Java syntax the API of the Execution Manager is defined as follows: String executeplan(string mpl); In WSDL this maps onto a structure with the following signature: <message name="execmgrif_executeplan"> <part name="string_1" type="xsd:string" /> </message> <message name="execmgrif_executeplanresponse"> <part name="result" type="xsd:string" /> </message> <porttype name="execmgrif"> <operation name="executeplan" parameterorder="string_1"> <input message="tns:execmgrif_executeplan" /> <output message="tns:execmgrif_executeplanresponse" /> </operation> </porttype> Previously we described the input of the Execution Manager to be MPL. For ease of use this is mapped onto a string. Be aware that the internal structure of the Execution Manager will convert this string to an MPL document and work with that. The output was describe earlier as to be MEL. Internally the output is an MEL document, but for convenient use this is also mapped onto a string. The MONET Broker (Task: 3.1) Page 18 of 20

21 Bibliography [1] BEA Systems, IBM, Microsoft, SAP AG, Siebel Systems, Business Process Execution Language for Web Services version 1.1, Available from [2] BEA Systems, Intalio, SAP AG, Sun Microsystems, Web Service Choreography Interface (WSCI) 1.0 Specification, Available from [3] Caprotti O., Dewar M., Turi D., Mathematical Service Matching Using Decision Logic and OWL, The MONET Consortium. [4] Carman M., Luciano Serafini, Paolo Traverso, Web Service Composition as Planning, ICAPS 2003, Workshop on Planning for Web Services. Available from [5] Chicha Y., Gaëtano M., Mathematical web services: a case study, TES 2003, 4th VLDB Workshop on Technologies for E-Services. [6] Chicha Y., Gaëtano M., Service Oriented Computing in the context of Mathematical Software, ICSOC 2003 Forum, 1st International Conference on Service Oriented Computing. [7] Chicha Y., Gaëtano M., Mathematical Services Composition, to be published in the proceedings of Software Composition 2004 Workshop. [8] Chicha Y., Davenport J., Roberts D., The Mathematical Explanation Ontology: draft, The MONET Consortium, deliverable D07, March Available from [9] IBM alphaworks, BPWS4J, Available from [10] The Information Management group, Instance Store Database Support for Reasoning over Individuals, Page 19 of 20

22 [11] Jelly Executable XML, [12] Maplesoft, Maple, [13] The Monet project, CVS repository, The MONET Broker (Task: 3.1) Page 20 of 20