In this section we present a brief overview of Web service orchestration technology and related protocols. A more in-depth presentation of SOA, the Web service technology stack and Web service orchestration can be found in Gortmaker, Janssen, and Wagenaar (2005) and Janssen, Gortmaker, and Wagenaar (2006). Web service orchestration technology is based upon the notion of a service-oriented architecture (SOA). Due to its loosely-coupled nature, the SOA-paradigm is very suitable for orchestrating service-delivery processes that run across relatively autonomous agencies. Agencies can provide services to other agencies that can invoke them as subservices in their business processes. A SOA makes it possible to quickly assemble new compound services out of existing services.
Web services are an important technology for realizing SOA. Web services are a technol- ogy that enables the provisioning of functionality, on an application level, or on a business level, by means of a standardized interface in a way that they are easily invoked via Internet protocols. Web services are said to be modular, accessible, well-described, implementation- independent, and interoperable (Fremantle, Weerawarana, & Khalaf, 2002).
Automatng Governmental Cross-Agency Processes Web service technology consists of a collection of protocols needed to implement a SOA.
This “Web service stack” first defines basic technologies, such as HTTP, XML, and XML schema for the creating of documents and communication between the different Web ser- vices. The basic functionality of a SOA is provided by the message and description layers.
The interface of a Web service is defined by means of Web Service Definition Language (WSDL), and the messages by which the services can be invoked are defined using SOAP (simple object access protocol). To make it easier to discover existing Web services, a service provider can register its Web services in a Web service directory through UDDI (Universal Description, Discovery and Integration).
Higher on the Web services stack are the standards for service composition, combining two or more services together to obtain a new composite service. These are different ways to create composite services. One form of constrained aggregation is coordinating them by means of a process flow that invokes the different subservices. Service composition using process flows comes in two flavors: Web service orchestration and Web service choreog- raphy. The difference between these two forms is subtle, and they are therefore sometimes erroneously considered as synonyms. There is, however, a major distinction between the two. Web service choreography specifies only the possible sequences between the public message exchanges between different agencies. Web service orchestration requires that the whole process needed for offering the service is defined at one place. This is an executable process, defined from the perspective of one participant, and offers an overview of all internal and external Web services that need to be invoked in the process.
As choreography does not require the responsibility for the whole process to be located at one place, it is less suitable for the coordination of cross-agency service delivery processes.
It can, however, be used for coordinating interactions between different agencies within the service-delivery process.
Wohed, Van der Aalst, Dumas, and Hofstede (2003) define an executable business process as specifying “the execution order between a number of constituent activities, the partners involved, the messages exchanged between these partners, and the fault and exception han- dling mechanisms.” In Web service orchestration, these activities are typically performed by Web services that are invoked from a process by means of their standardized Web service interface.
Many competing proposals for process specification languages, including ebXML BPSS, WSCI, WSFL, XLANG, BPML, have been made, but the standard language for Web service orchestration is BPEL4WS, Business Process Execution Language for Web Services (An- drews et al., 2003), BPEL for short, a specification developed by IBM and Microsoft, based on their respective standards WSFL and XLANG. BPEL can be viewed as a layer on top of WSDL, as it uses the properties of Web services that are specified by means of WSDL.
A process that is specified in BPEL consists of two types of activities: basic activities that specify the tasks that are to be performed, such as receive an invocation, reply to the service requester, wait for a specified amount of time, and structured activities as switch for conditional branching, while for repeating parts of the business process, and sequence for performing tasks in parallel. The structured activities determine the structure, or the sequencing of the process, and the basic activities determine what happens in the process, for example, the invocation of a WS, receiving a message from a Web service, and so forth.
Gortmaker & Janssen
Business.Counter
Although the business counter for the hotel and catering industry is viewed as a best practice as it consists of account managers functioning as one-stop shops and passing permit appli- cations through to the back office, in the current situation, there is hardly any ICT support.
A model describing the high-level interactions between the actors involved is depicted in Figure 1.
.
For almost all permit applications, the applicant has to schedule an appointment with the business counter, after which the account manager coordinates the interactions with the back office and the other agencies. Many of the permit requests exceed the desired lead times.The entrepreneurs, the customers of the business counter, are often bound to the opening hours of their own business and face difficulties having to meet the openings hours of the business counters. Moreover, they would like to have a faster response time and insight into the status of their requests, as this enables the further development of their business. The city council recognizes the entrepreneurs’ needs and wants to know if Web service orchestration technology is suitable for improving the cross-agency processes.
Dpt. of Publc
Space Buldng Dpt.
check zone plan check
personal data Publish
copies of permit to 3rd parties
Muncpal
DB Zone
Plan
adviceask
Muncpal newspaper
Chambre of Commerce Polce Justce Dpt. Fre brgade
nternal actor
external actor
nternal data store Interacton
ask advice
&
check data Send
permit file application
Physcal Counter Vrtual Counter call center
pass application
entrepreneur
Back offce Front offce
Read
Send Comments
Figure 1. Actors and interactions in liquor-licensing process
Automatng Governmental Cross-Agency Processes A liquor license1 is one of the most important permits for the hotel and catering industry.
Every restaurant or café that pours alcohol is obliged to apply for a license. For request- ing a license, an entrepreneur can contact the business counter. After this first contact, an intake interview is planned, where civil servants of the business counter, the back office, and sometimes of other involved agencies are present. After this meeting, the entrepreneur has to fill in an application form and return it, together with the needed official documents, for example, a floor plan.
Hereafter, the name, address, and place of residence of the applicant are checked. If the applicant lives in the municipality, this activity is performed by the back office, otherwise a request has to be sent to another municipality. Next, the justice department is asked for advice; they check whether the applicant has a criminal record or not. The police are also asked for advice about the applicant, but look for “softer” evidence, for example, fines, crimes that were not proven, or for which someone has not been sentenced yet. Also the fire depart- ment is asked for advice concerning the construction and safety of the building. Finally, the building department has to check whether the building meets all legal requirements.
On the basis of these advices, the back office employee draws up a license, or a letter stat- ing the reasons for refusing the license. Copies of the issues license are sent to third parties such as the police, the chamber of commerce, and the fire department.
Web.Service.Orchestration...
at.the.Business.Counter
To determine the feasibility of Web service orchestration for supporting cross-agency pro- cesses, a prototype of automating the liquor-licensing process using BPEL4WS was built.
Figure 2 shows a graphical representation of a part of the cross-agency process implemented in BPEL. As real-life BPEL processes are usually very complex and consist of many elements, only part of the process could be shown. Also several process steps, mostly concerning the assigning of variables, were omitted from the picture. The figure contains a screenshot from Oracle JDeveloper BPEL Designer, the process designer belonging to their orchestration server, Oracle BPEL Process Manager (Oracle, 2004).
On the left of Figure 2 the file menu is shown, the BPEL process constructs are shown on the middle and right part of the figure. The process is started (see call out 2 in Figure 2) after the applicant initiates the BPEL process (1) by filling in an online application form on the client. First, an internal Web service (4) to check whether the form is correctly filled in, the “InputCheckService,” is invoked (3). When not all fields are filled in correctly (5), an error-message is prompted back to the applicant (6). When the application is complete, two simultaneous subprocesses are started (7): the application is published in the munici- pal newspaper (8) (which was not implemented in this prototype) and a Web service at the police (10), “Advice_Police,” is invoked (9) to get information about the criminal record of the applicant. Only a Web service providing access to the business processes of the police is shown in this picture, but every agency or organization, the justice department, the fire department, or the chamber of commerce that can offer Web service access to its business
Gortmaker & Janssen
processes can be linked into a cross-agency process in similar fashion. The complex deci- sion-making process on the license request is also not shown in the figure.