282 Zhang Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permis- sion of Idea Group Inc. is prohibited. reused, the project team needs to go through the service’s specication to verify that the service will work well with the pervasive layer to support all the pervasive channels that the application is going to support. If not, the rst thing the project team should try to modify is the pervasive layer. If the issue really lays in the fact that the business service is not a “pure” service, that is, the service is tied to access methods, then the service needs to be either modied or wrapped in order to sup- port the new requirements. When such a modication occurs, the service needs to be made backward compatible, and existing applications that use the service need to be regression tested. Eventually, the service denition needs to be modied to reect the changes. With this architecture, when a new pervasive access channel appears, or there is a change in an existing channel, then the only thing that needs to be modied is the pervasive channel. All business services can remain the same. Future. Directions Moving forward, there needs to be much research and development work on build- ing a system infrastructure that can use different sources of information to judge where the user is, and what devices and interaction modes are available to the user during a pervasive session. This will enable smarter location-based information push to better serve the user. A related research topic is how to smoothly transition an interaction to a new device and interaction mode as the user changes locations and devices. Some initial work on this subject, referred to as seamless mobility, is being conducted at IBM and other organizations. Another area that deserves much attention is the proactive delivery of information that users will need based on their proles and information such as activities on their calendars or to-do lists. This relates to previous research efforts on intelligent personal assistants with integration into the pervasive computing environment. References 3Gtoday. (2005). Retrieved November 5, 2005, from http://www.3gtoday.com Blackwell, G. (2002, January 25). Mesh networks: Disruptive technology? Wi-Fi Planet. Retrieved October 25, 2005, from http://www.wi-planet.com/col- umns/article.php/961951 Leveraging Pervasive and Ubiquitous Service Computing 283 Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. Bluetooth SIG. (2005). The ofcial Bluetooth wireless info site. Retrieved November 3, 2005, from http://www.bluetooth.com Culler, D. E., & Hong, W. (Eds.). (2004). Wireless sensor networks. Communica- tions of the ACM, 47(6), 30-57. Feder, B. (2003, June 10). Glass that glows and gives stock information. New York Times, P.C1. Fox, B. (2001, November 21). “Mesh radio” can deliver super-fast Internet for all. New Scientist. Retrieved November 15, 2005, from http://www.newscientist. com/news/news.jsp?id=ns99991593 Geier, J. (2002, April 15). Making the choice: 802.11a or 802.11g. Wi-Fi Planet. Retrieved October 16, 2005, from http://www.wi-planet.com/tutorials/article. php/1009431 Hamblen, M. (2005). Wi-Fi fails to connect with mobile users. ComputerWorld, 39(37), 1, 69. Henderson, T. (2003, February 3). Vocera communication system: Boldly talking over the wireless LAN. NetworkWorld. Retrieved November 12, 2005, from http://www.networkworld.com/reviews/2003/0203rev.html Holtzblatt, K. (Ed.). (2005). Designing for the mobile device: Experiences, chal- lenges, and methods. Communications of the ACM, 48(7), 32-66. IEEE. (2005a). IEEE 802.15 Working Groups for WPAN. Retrieved November 7, 2005, from http://www.ieee802.org/15/ IEEE. (2005b). The IEEE 802.16 Working Group on Broadband Wireless Access Standards. Retrieved November 22, 2005, from http://www.wirelessman. org McCarthy, K. (2000, April 7). Anoto pen will change the world. The Register. Re- trieved September 14, 2005, from http://www.theregister.co.uk/2000/04/07/ anoto_pen_will_change/ Rubio, D. (2004, October 20). VoiceXML promised voice-to-Web convergence. NewsForge. Retrieved November 23, 2005, from http://www.newsforge. com/article.pl?sid=04/10/15/1738253 Schrick, B. (2002). Wireless broadband in a box. IEEE Spectrum. Retrieved No- vember 19, 2005, from http://www.spectrum.ieee.org/WEBONLY/publicfea- ture/jun02/wire.html Schwartz, E. (2001, September 26). Free wireless networking movement gathers speed. InfoWorld. Retrieved December 5, 2005, from http://www.infoworld. com/articles/hn/xml/01/09/26/010926hnfreewireless.xml ZigBee Alliance. (2005). Retrieved November 11, 2005, from http://www.zigbee. org/en/index.asp 284 Zhang Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permis- sion of Idea Group Inc. is prohibited. Section V Enterprise Service Computing: Formal Modeling A Petri Net-Based Specication Model Towards Veriable Service Computing 285 Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. Chapter.XII A.Petri.Net-Based. Specication Model Towards.Veriable Service.Computing Jia Zhang, Northern Illinois University, USA Carl K. Chang, Iowa State University, USA Seong W. Kim, Samsung Advanced Institute of Technology, Korea Abstract The emerging paradigm of Web services opens a new way of engineering enterprise Web applications via rapidly developing and deploying Web applications by com- posing independently published Web-service components to conduct new business transactions. However, how to formally validate and reason about the properties of an enterprise system composed of Web-service components remains a challenge. This chapter introduces an advanced topic of enterprise service computing: the formal verication and validation of enterprise Web services. The authors intro- 286 Zhang, Chang, & Kim Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permis- sion of Idea Group Inc. is prohibited. duce a Web-services net (WS-Net), which is an executable architectural descrip- tion language incorporating the semantics of colored petri nets with the style and understandability of the object-oriented concept and Web-services concept. As an architectural model that formalizes the architectural topology and behaviors of each Web-service component as well as the entire system, WS-Net facilitates the simulation, verication, and automated composition of Web services. Introduction The emerging paradigm of Web services opens a new way of engineering enterprise Web applications. The key concept is to rapidly develop and deploy Web applications by composing independently published Web-service components to conduct new business transactions. Accordingly, a Web-services-oriented system refers to a Web- application system that contains one ore more Web-service components. In theory, a system containing Web-service components may also contain some parts that are not Web services; however, in reality, every component in a Web-services-oriented system is wrapped as a Web service. Thus, for the rest of this chapter, we will use the terms service components, services, and components interchangeably. The existing Web-services model favors the creation, registration, discovery, and composition of distributed Web services. In this model, Web services basically adopt a triangular provider-broker-requester operational model, or the so-called services-oriented architecture (SOA), as shown in Figure 1. A service provider publishes services at a public service registry using universal description, discovery, and integration (UDDI; Universal Description, Discovery, and Integration, 2004). The public interfaces and binding information of the registered services are clearly dened in the standard Web service description language (WSDL; Web Services Description Language, 2004). Such a public service registry generally provides two interfaces: a registry interface serving service providers, and a query interface serving service requesters. As illustrated in Figure 1, published Web services are hosted by the service providers. A service requester queries the service registry for certain services registered, and obtains the binding information of the correspond- ing service provider. Then the service requester binds to the service provider and remotely invokes the services from the service provider through a lightweight mes- saging protocol: the simple object access protocol (SOAP; Simple Object Access Protocol [SOAP] 1.2, 2003). Although the paradigm of Web services has been extensively considered as the model of the next generation of distributed computing and Internet computing, how to formally validate and reason about the properties of an enterprise system composed of Web-service components remains a challenge. As a matter of fact, A Petri Net-Based Specication Model Towards Veriable Service Computing 287 Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. the actual adoption of Web services in industry is quite slow, mainly because there lacks an established way of formally testing Web-services-oriented systems (Zhang, 2005). As a research aiming at facilitating Web-services composition and verication, Web-services net (WS-Net) is an executable architectural description language that incorporates the semantics of colored petri nets (CPNs) with the style and understandability of the object-oriented concept and Web-services concept. WS- Net describes each system component in three hierarchical layers: (a) An interface net declares the set of services that the component provides, (b) an interconnection net species the set of services that the component requires to accomplish its mis- sion, and (c) an interoperation net describes the internal operational behaviors of the component. Each component may be either an independent Web service or a composition of multiple Web services, and the whole system can be considered as the highest level component. Thus, WS-Net can be used to validate the intracom- ponent and hierarchical behaviors of the whole system. As an architectural model that formalizes the architectural topology and behaviors of each Web-service com- ponent as well as the entire system, WS-Net facilitates the simulation, verication, and automated composition of Web services. To our best knowledge, our WS-Net is the rst attempt to comprehensively map Web-services elements to colored petri nets so that the latter can be used to facilitate the simulation and formal verication and validation of Web-services composition. Figure 1. Service-oriented architecture Service Broker Se rv ic e R epo si tory Service Provider Se ar ch serv ic es (UDDI) Publish serv ic es (WSDL) Query Interface Register Interface Se rv ic e De scr ipti on Application Com ponen t Service Requester Se rv ic e R eque st Application Com ponen t R eque st serv ic es (SOAP) 288 Zhang, Chang, & Kim Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permis- sion of Idea Group Inc. is prohibited. The remainder of the chapter is organized as follows. First, we will introduce the state of the art of Web services composition toward services-oriented engineering. Second, we will discuss the challenges of formal Web-services-oriented verica- tion. Third, we will compare options and make selections. Fourth, we will discuss related work. Fifth, we will introduce our WS-Net approach. Finally, we will make conclusions and discuss future work. State. of. the.Art.Web-Services Composition. and. Challenges State.of.the.Art.of.Web-Services.Composition In this section, we will briey introduce the state of the art of Web-services com- position. Figure 2. Web-services composition A Petri Net-Based Specication Model Towards Veriable Service Computing 289 Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. Concept.of.Web-Services.Composition The SOA model discussed in the introduction describes how to obtain a single Web service. In reality, however, a service requester typically needs to synergistically coordinate and organize multiple Web services into business processes. Web-ser- vices composition thus refers to the construction process of composite services from Web services, as shown in Figure 2. It generally involves two procedures: selecting and constructing. The selecting procedure focuses on selecting qualied services, while the constructing procedure focuses on dynamically building ow structures over selected services. Figure 2 illustrates a simplied Web-services composition. The composition is con- ducted by a composer residing at the nal environment. The composer decides to integrate four existing Web services, namely, S 1 , S 2 , S 3 , and S 4 . As shown in Figure 2, there are temporal relationships between the four services. S 1 will run rst. Then, depending on the output of S 1 , either S 2 or S 3 will be executed. If S 2 is chosen, then S 4 will be executed afterward. As shown in Figure 2, the four service components will be implemented by four Web services that belong to different service providers and reside on different sites. When the composer runs the composite service in the nal environment, it will remotely invoke the corresponding Web services accord- ing to the predened scenario. The construction of a composite Web service can be modeled by specifying a structure of service components using a service ow language, such as the BPEL4WS (busi- ness process execution language for Web services; Specication: Business Process Execution Language for Web Services Version 1.1, 2003) and Microsoft BizTalk Server (Microsoft, 2003). The structure denes an e-business process model; an invocation of the composite service is treated as an instance of the process model. Examples of the composition model are eFlow (Casati, Ilnicki, Jin, Krishnamoorthy, & Shan, 2000), the scenario-based service composition by Kiwata, Nakano, and Yura (2001), the quality-driven model by Zeng, Benatallah, Dumas, Kalagnanam, and Sheng (2003) and Zeng, Benatallah, Ngu, Dumas, Kalagnanam, and Chang (2004), the constraint-driven composition by Aggarwal, Verma, Miller, and Milnor (2004), and so forth. With the rapid increase of the number of Web services published on the Internet on a daily basis, the demand for integrating heterogeneous services in an automatic or semiautomatic way becomes urgent. Efforts have been made to automate the service- composition process by employing discovery agents. According to the information provided in a service request, these discovery agents generate a structure of service operations based on some registered services. Commonly used approaches for agents to make decisions are rule-based systems (Ponnekanti & Fox, 2002) and ontology- based approaches (Arpinar, Aleman-Meza, Zhang, & Maduko, 2004). However, to date, fully automated approaches sometimes involve unavoidable, unrealistic 290 Zhang, Chang, & Kim Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permis- sion of Idea Group Inc. is prohibited. assumptions; for example, rule-system-based approaches assume that the service requester knows the exact input and output interfaces of a desired composite service. Liang, Chakarapani, Stanley, Su, Chikkamagalur, and Lam (2004) thus utilized a semiautomatic approach to assist service composition. As shown in Figure 2, Web-services composition differs from traditional applica- tion-component composition in several signicant ways. First, unlike in a traditional component composition where component parts are deployed in the same nal en- vironment, Web-services composition is a virtual composition in the sense that all participating services will never be physically deployed into the nal environment. This is because Web services are hosted by corresponding service providers and can only be used through remote invocations. Second, Web-services composition implies uncertainties. Since Web services are hosted and managed by their own service providers, their availabilities may autonomously change (Zhang, 2005). An available Web service on a specic day may not be available on the next day. Furthermore, the quality of service (QoS) and even functionalities of Web services can also change over time due to changes in adopted technologies or business models from the corresponding service providers. Therefore, Web-services composition may have to be conducted upon a per-usage basis. Third, Web-services composition needs to serve more dynamic changes of user requirements. This is not a new issue; however, users adopt Web services for higher exibility and adaptability, thus they hold higher expectations than before. Architecture.of.Web-Services-Oriented.Systems Just as an architectural diagram is an essential guideline for architectural constructions, software architecture is critical for the success of a Web-services-oriented system Figure 3. Two dimensions of Web-services composition Serv ic e Architecture Service Service Service Service Service Se rv ic e A Petri Net-Based Specication Model Towards Veriable Service Computing 291 Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. and Web-services composition. According to The American Heritage Dictionary of the English Language (2000), architecture is “the art and science of designing and erecting buildings, a structure of structures collectively, a style and method of de- sign and construction.” In other words, software architecture plays an essential role in providing the right insights, triggering the right questions, and offering general tools for thoughts. Thus, architecture description languages (ADLs; Medvidovic & Taylor, 2000) are commonly created to formally specify and dene the architectural model of a software system as a guideline before construction. As shown in Figure 3, Web-services composition is a process of composing mul- tiple Web services as components into a composite Web-services-oriented system. In order to facilitate services composition, the architecture specication (e.g., an ADL) that represents a complex Web-services-oriented system should capture two dimensions of design information: the service dimension and architecture dimension. The service dimension focuses on specifying low-level interconnections between Web services, for example, how to glue different service components together, how to communicate between services, how to orchestrate services, and how to choreo- graph services. The architecture dimension, on the other hand, focuses on specifying high-level compositional views or architectural views of a nal composite service, for example, hierarchical relationships among service components. In more detail, a Web-services-oriented ADL needs to catch the following three categories of design information: (a) the structural properties and Web-services- component interactions, (b) the behavioral functionality of each major high-level Web-services component, and (c) the behavioral functionality of the entire system. In recent years, researchers from both industry and academia have been developing a number of Web-services-oriented ADLs, typically, WSDL (Web Services De- scription Language, 2004), Web services ow language (WSFL; Leymann, 2001), BPEL4WS (Specication, 2003), Web service choreography interface (WSCI; Web Service Choreography Interface [WSC]), Version 1.0, 2002), XLANG (Thatte, 2001), and so forth. Challenges. of. Formal.Verication and Validation of.Web-Services. and. Composition Although Web-services composition exhibits a boom to enterprise software engineer- ing, it is not clear that this new model guarantees various Web-service components can be composed and integrated seamlessly and properly (Zhang, 2005). In detail, the exibility of Web-services-centered computing is not without penalty since the value added by this new paradigm can be largely defeated if, for example, selected Web-service components do not thoroughly fulll the requirements (i.e., functional [...]... components If service component Ci requests a service from service component Cj, Ci is called a client service component, and Cj is called a server service component A service component can act as a client service component at some time, and as a server service component at other times WS-Net chooses to define required services as foreign services since the services need to be performed by other service. .. Model Towards Verifiable Service Computing 309 Interconnection Net In order to describe the relationships between architectural components in a services-oriented system, we need to specify both the provided services (i.e., via the interface-net specification) and required services of the service components In other words, a service component may require supporting services in order to provide promised services... WS-Net is applied to Web-services-oriented systems as well as integrated with the ad hoc Web-services standards, such as WSDL and XML Formal Verification Work on Services-Oriented Systems Narayanan and McIlraith (2002) proposed to use petri nets as tools to simulate, verify, and automate Web-services composition Their Web-services composition refers to the composition of programs into a Web service and does... of the remote service components, names of the services required from the service components, and the type of connectors to be used to invoke each foreign transition These service names and component names are used to identify the services represented by foreign transitions In addition to the inscriptions, the color set of the plug-ins of the foreign services in the client (i.e., local) service component... pointing into a transition contain an adequate number of tokens, the transition is enabled and may fire; thus, the transition removes all of its input tokens and deposits a new set of tokens in its output places Web services can be modeled as petri nets by assigning transitions to services, and places to inputs and outputs Each Web service has its own petri net, which describes service behaviors Each service. .. two services: enqueue service and dequeue service, which accept user-submitted messages and retrieve user message requests, respectively In order for the services to be invoked, the corresponding input ports of the services must receive proper tokens The enqueue service receives an item token and returns a Boolean result as either a success or failure The dequeue service receives a request as a unit token... addition to the inscription for places, transitions, and arcs as used in CPN, WSNet provides additional inscriptions for both service components and each service provided In detail, for the service- component inscription, a service- component name is provided to uniquely identify the service component For a service inscription, service- name and connector-type information are provided Connector type implies... provided Connector type implies the possible protocols to be used when the service is invoked In our example, both enqueue and dequeue services are invoked via the SOAP protocol If multiple protocols can be used, the connector type can have multiple entries Similar to the name inscription for places and transitions, these inscriptions for service components and services are not considered petri-net inscriptions... composition of Web services into new Web services In contrast to their work, our research covers both inter-Web-services and intra-Web-services composition In detail, our interconnection net simulates and validates the interactions and composition among Web services The interoperation net simulates and validates the composition inside a Web service, which may or may not contain other Web services Moreover,... the interconnection net specifies an architectural service component as a set of provided services Each provided service containing foreign transitions is in turn decomposed into a set of required foreign services A foreign transition is therefore an abstract view of the service provided by another service component To differentiate it from a local service component, the input and output places of a . between Web services, for example, how to glue different service components together, how to communicate between services, how to orchestrate services, and how to choreo- graph services. The. dimensions of Web-services composition Serv ic e Architecture Service Service Service Service Service Se rv ic e A Petri Net-Based Specication Model Towards Veriable Service Computing 291 Copyright. (2002) proposed to use petri nets as tools to simulate, verify, and automate Web-services composition. Their Web-services composition refers to the composition of programs into a Web service and