Get Adobe Flash player
Oficjalna strona partnera projektu

postheadericon Strona główna

Brak tłumaczenia.

Although a lot of work has been done for automating electronic business processes, still it is a great challenge.

However amazing it may appear, it has usually been overlooked that the best (if not the only) way to proceed with automation of sophisticated electronic business processes is to begin with automating the use of a single business service.

Typical, not automatic way of using a business service by a customer consists of the following four phases:

  1. The service requester sends a query to a service provider specifying roughly what she/he wants from the service, and then gets back a quotation (a proforma invoice) from the provider. The quotation specifies details of what (and how) the service can perform for the requester.
  2. Having the quotation, the requester creates an order and sends it to the provider. Usually, the provider replies with an appropriate contract.
  3. If the service is performed according to the contract, the provider sends expertise or carriage letter to the requester, whereas the requester sends back a delivery note (or acknowledgement of receipt) or a complaint.
  4. Finally, the service provider sends invoice, and the requester realizes the payment for the provided service.

Sometimes, after sending the order, the service provider sends back an invoice, so that the payment must be done before service delivery.

In order to automate the use of a whole service, each of these interrelated four phases  must be automated. For any specific type of service this may be done by a dedicated software application implemented, for example, in BPEL. Note that in each of the aforementioned phases, there is a document flow, that is, query and quotation in the first phase, order and contract in the second phase, carriage letter, delivery note, and complaint in the third phase, and finally invoice and payment. These documents can be created in XML. For each of the phases, the document flow can be described as a separate operation in WSDL. Since WSDL does not provide means to define the relations between the four phases, the complete process of using a single service can be implemented (hardcoded in, e.g. BPEL) separately for any service type in a dedicated way. However, our goal is to do so generically, that is, to construct tools that allow automation of service use for any service type.

Relations between the phases (operations) are crucial to the automation of business processes.
They must be formally specified, so that they can be automatically processed.
For this purpose, the following concepts are proposed:

  • XSD schemata of the XML documents (as service environment representation) processed in the second, third and fourth phase.
  • Formal language describing the XSD schemata.
  • Arrangement of business service, i.e., request and quote (in the first phase), is expressed universally as formulas in the formal language, and are related to the documents from the other phases.

The proposed language does describe service (like WSDL) and describes also the environment in which the service is executed, that is, the XSD schemata and corresponding XML documents.
This description consists of a precondition and an effect. The precondition specifies the local (for this service) situation in the environment (specifying a collection of input XML documents) that must occur before the service can be executed. The effect specifies the situation in the environment caused by the service execution, i.e., a collection of appropriate output documents.
This corresponds to IOPE (Input-Output-Precondition-Effect), i.e. service description in OWL-S. However, in the proposed approach the service implementation is considered as a black box, while in OWL-S it is specified in a form of Service Model that describes the internal process of service performance.

In this way, only external view of service is described, i.e. the environment of the service.
In other words, only changes in the environment (i.e., initial situation and effect of the service execution) are described.
The environment is represented by XSD schemas of XML documents created and processed by clients and services.
This representation provides a grounding (a concrete semantics) for service description language used to automate the first phase, that is, the request-offer phase of the business process.
The information about relationship between phases is specified in the first phase in the formal language and can be automatically processed in the next phases.

Since a user (on the client side) may not (and often does not) know the specific requirements of the service in relation to its intention, it is necessary to query the service by a client in order to obtain all the parameters needed to send a proper order and agree on a contract.
Hence, during the process of service arrangement (the first phase) all the parameters and their values necessary for the order and contract (documents in the second phase) creation are determined.
These parameters (e. g. date and time of service performance, options, related scope, and price, etc. ) are specified in a quote as a formula in   the universal description language.

So that, the request and quote (exchanged in the first phase and defined as formulas in the description language) include all essential information about documents to be created and processed in the next phases.

Hence, the crucial point for the automation of the first phase (and then the next phases) is the concept of the service environment, its formal representation in XSD, and the description language used in the communication between services and clients.
OWL, Entish (, or any other simple language of first order logic without quantifiers can be used as the description language. The only requirement is that the services and clients must be able to understand the language, i.e. create and interpret messages defined in that language.

Actually, we propose an extensions  of the business service architecture  related to Web service and Semantic Web. In the architecture there are two ways of communication. The first way (during the arrangement phase) consists of exchanging messages (with contents defined as formulas in a description language). The second way of communication is a document flow and processing using WSDL during the order-contract, execution, and payment phases.

The concept of business service and the automation of the arrangement phase (using formal description language) give rise to automaton of the whole complex business process consisting of many services. It constitutes the core of the proposed new technology specified in the form of protocols. The corresponding prototype system for automation of business process (including planning, composing of services, and execution) has been implemented as a communication platform, and is available online in the form of a set of tools (
The platform (called SOA-enT) is generic and may be applied to any application domain when adjusted. The adjustment encompasses a definition of the appropriate XSD schema. The technology, and the platform is presented in detail in the subsequent sections.

The proposed system architecture, its components and communication protocols (defining the order, format and semantics of message exchange between these components) are described in the publication:
S. Ambroszkiewicz, W. Bartyna, M. Faderewski, P. Kulma, A. Ryżko, et al.. Platform for development of electronic markets of sophisticated business services. In Ambroszkiewicz, S.; Brzeziński, J.; Cellary, W.; Grzech, A.; Zieliński, K. (Eds.) Service Oriented Architecture - Advanced Tools and Applications, Studies in Computational Intelligence Vol. 499, Springer, Heidelberg and New York 2013. ISBN 978-3-642-38956-6

Utworzony: poniedziałek, 05, styczeń 2009 08:07
Aktualizowany: niedziela, 28, wrzesień 2014 17:03