Web Services on Universal Networks Yun-Young Hwang1
[email protected]
Il-Jin Oh1
[email protected]
Kangchan Lee2
[email protected]
Hyung-Jun Yim1 Kyong-Ha Lee1
[email protected] [email protected]
Seungyun Lee2
[email protected]
Kyu-Chul Lee1
[email protected]
1 Department of Computer Engineering, Chungnam National Universigy, Gung-Dong, Yusung-Gu, Dajeon, Korea 2 Electronic and Telecommunications Research Institute, Doryong-Dong, Yusung-Gu, Dajeon, Korea
1. INTRODUCTION
ABSTRACT The clients, in ubiquitous environment, want to be consistently offered services at any time and in any places. There are so many service discovery middleware such as Jini, UPnP and HAVi. Each one of them supports different communication protocol. Therefore, when the clients ask an inquiry of service search, they have to support communication protocol of all service discovery middleware. Namely, all the cost shall be borne by the customer. In addition, these middleware does not consider the service location and status. To solve these problems, we suggest the SOA-based framework is Web Services on Universal Networks. The framework supports a dynamic service discovery through the interoperability between service discovery middleware. Furthermore, it considers service location and status at service discovery process.
Categories and Subject Descriptors A.0 [General]: Conference proceedings C.2.4 [Computer-Communication Networks]: Distributed Systems – Client/Server, Distributed applications, Network operating systems J.7 [Computer in Other Systems]: Publishing, Real time K.6.3 [Management of Computing and Information Systems]: Software Management – Software development, Software maintenance, Software process
General Terms Management, Design, Standardization
Reliability,
Human
Factors
and
Keywords Ubiquitous, Dynamic Services Discovery and Web Services
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The common service discovery middleware, which is used in distributed network environment, is Jini[1], UPnP[2] and HAVi[3]. Each one of them supports a different communication protocol. For example, a device of Jini can communicate by using RMI, and one of UPnP supports the SOAP. Therefore, when the clients ask an inquiry of service search, they support both of them because they want to be offered all usable services. It may bring expense to the client. In ubiquitous environment, all units, included client and device, can move to anywhere and at anytime. The current systems do not support ubiquitous feature like that dynamic change of service status and movement. In Addition, they can’t support another communication protocol. To solve the current problems, we suggest a Web Services on Universal Networks (WSUN). WSUN is SOA based framework. The framework supports a dynamic discovery protocol is Universal Service Discovery Protocol. Furthermore, It supports an interoperability between service discovery middleware. In this paper, we shortly introduce WSUN. The detail description of WSUN is described in [4]. And we prove our approach through implementation the prototype system. The second chapter of this study introduces Web Services on Universal Networks, the third describes the design of WSUN, the fourth describes our system and the fifth presents the conclusions of this study and further research related to this study
2. Design of Web Services on Universal Netowrks Web Services on Universal Networks (WSUN) is based on Services Oriented Architecture (SOA) framework. The framework supports the ubiquitous web services discovery and binding. This framework has a Universal Service Broker (US Broker) (Figure 1). It is core component that supports dynamic service discovery and interoperability between service discovery middleware. Since any Web Services client can find the services which are located in any service discovery middleware, we transfer all services in service discovery middleware to Web Services. A description of Web Services is registered in a registry. When a client searches services, Query Agent receives and parsed the client message and it searches the services through US Registry.
3. Design of Web Services on Universal Networks 3.1 Design of Listener
WSUN US Broker
Virtual Service
…
Virtual Service
UWS Service
…
UWS Service
Listener
Client
Query Agent Publish Agent
WSUN Device
US Registry Device/Service Registry
Context Registry
Routing Module
DPWS Device
Listener takes charge of communication between US Broker and client or WSUN device. The client has to support SOAP protocol. WSUN device supports our protocol is Universal Service Discovery Protocol.
Service Service
JINI Device
JINI Adaptor
Service
JINI Client Device
Device
Device
LUS
Device
JINI
Universal Adaptor
…
DPWS Adpator
Service
DPWS Client Device
Device
DPWS Device
Device
Figure 1. Web Services on Universal Networks
Listener is composed of three components (Figure 2). The client and WSUN device send the multicast message to find the US Broker. Telecommunication of Listener gets this message and returns the response message. We register all service information in US Registry. We register the WSUN device information through Register. For this purpose, Register uses the Publish Agent operation. We check whether service is registered or not.
US Broker has six components such as Listener, Query Agent, Publish Agent, Universal Adaptor, Routing Module and Universal Services Registry. The following is the explanation of components. z
Listener: It takes charge of telecommunication between Client and US Broker or WSUN devices.
z
US Registry: It stores specific metadata that a ubiquitous web service possesses. Meanwhile, the US Broker stores and manages ubiquitous web service features in the Device/Service registry. And context registry stores location information of ubiquitous web services. In a ubiquitous environment, the service location changes frequently. Service location is an important factor for service discovery. For example, clients who are close to the Eiffel Tower are provided with service which is supported nearby.
z
Query Agent: It processes the clients’ service discovery inquiry. Query Agent searches services in US registry after it receives the clients’ service discovery inquiry. It delivers the results to the clients.
z
Publish Agent: It publishes ubiquitous web service information in the US registry and context registry. After UniA creates virtual web service, it stores their information in the Service/Device registry. After the storage is completed, it informs to the UniA of this fact.
z
Universal Adaptor (UniA): It transfers the messages between the sub-network and the US Broker. It creates the sub-network service as the virtual web service. At this time, to acquire the information needed, the subnetwork protocol is used to communicate and gSOAP is used to communicate within the US Broker. In addition, it handles all events of sub-networks and reflects this fact to two registries.
z
Routing Module: It binds the service that the clients want. It provides virtual web service within the US Broker that the web service clients choose and the existing web service binding.
Figure 2. Diagram of Listener
3.2 Design of US Registry US Registry is composed of two registries: Device/Service Registry and Context Registry.
Figure 3. Table of US Registry Device/Service Registry has device and service information such as their name, description, ID and category information. Service
location is stored in Context Registry. The information is used when the client searches the service. For supporting a interoperability between sub-networks and US Broker, we register service ID in our framework and in sub-networks. We can map services in sub-networks to services in our framework.
3.3 Design of Query Agent Query Agent takes charge of service discovery in US Registry and client message processing. For this purpose, it is consists of Parser, Matching, CheckService and GetServiceDeviceInfo(Figure 4). Parser supports the client message parting and query planning. Before we register the service information on US Registry, we check whether the service is registered or not. For this operation, we design the CheckService component. We can get the device and service information from GetServiceDeviceInfo. The information includes service and device name, description, ID, location and category information. We find the services corresponding to client query using the result of GetServiceDeviceInfo. Figure 5 illustrates the sequence diagram of Query Agent. Query Agent receives service discovery message from client. This message is parsed through Parser. After parsing, parsed information is sends to Matching component. We can find the service using this information. Also, the Matching searches the service location on context registry. The location of services must be near to clients’ location. The last step, the Matching joins the result from Device/Service registry and Context Registry. And then, the matching results are sent to client.
Client
Parser
Matching
Figure 4. Design of Query Agent
GetServiceDeviceInfo
Service/Device Registry
Query about Service Search
parsing Message
Query about Service Search request service list request service/device info service list service list request service list request service location service list service list
join service list
service list
Figure 5. Sequence diagram of Query Agent
Context Registry
Figure 6. Insert information on registry
Adaptor
Parser
Register
CheckService
Service/Device Info
parsingMessage
Service/Device Info ServiceID Result
updateServiceStatus if non register Service
Figure 7. Update information on registry
Result
Service/Device Registry
3.4 Design of Publish Agent
service is located in Jini network. In this environment, we can confirm that the client uses all services in any networks.
Publish Agent registers device and service information on Device/Service Registry and Context Registry. Therefore, it is composed of four components: UUID Generator, Parser, CheckService and Register. UUID Generator generates unique UUID of service and devices which are used in the US Broker. The Parser takes charge of message from UniA or Listener. After parsing the message, we can register the service and device information on US Registry. Publish Agent has two processes. One is insert process and another is update process. The following is explanation of insert process (Figure 6). ①
Parser receives the request message included publish service and device information.
②
Parsed message is sent to Register.
③
Before publish the information service and device, Register checks whether service is registered or not.
④
If service is not registered and Register publishes the service and device information to Device/Service Registry, and the location of service to Context Registry.
⑤
If service is registered and Register update service status from invalid to valid.
The following is explanation of update process (Figure 7). This process is same process in Figure 6 except registered service and device information on US Registry.
Figure 8. Query Interface
5. Conclusion This study explains the WSUN and proves our approach. The WSUN supports interoperability between service discovery middleware, and helps clients to use ubiquitous web service without additional work by generating virtual web service for the clients’ convenience. The current WSUN is designed for the integration of Jini, UPnP, and DPWS but through further study, other sub-network environments will be included. The further study will verify this with several scenarios by realizing the WSUN. Also, after clients’ inquiry will be maximized and their context information will be considered, more improved ubiquitous web service discovery protocol will be defined.
6. ACKNOWLEDGMENTS 4. Implementation of Web Services on Universal Networks Our implementation environment is following. z
OS: Window Server 2003 R2 Enterprise Edition R2
z
Execution Environment
z
J2SDK 1.4.2 version
z
MySQL 4.1 version
z
Tomcat 5.0.30 version
z
Apache 2.0.58 version
z
Axis 1.3 version
We consider the scenario to prove our approach. The client enters the meeting room. He wants the three services. One is black and white printing service for materials. The other is color printing service for picture. Another is vim projector for presentation. First, client search the black and white printing service. He can use the service name, description and category information to discovery services. And the client can receive the result included device name, service name, location and WSDL URL(Fig 8). We also consider the black and white printing service and vim projector service are located in DPWS network, and color printing
This research was supported by the Ministry of Information and Communication, Korea, under the College Information Technology Research Center Support Program, grant number IITA-2006-C1090-0603-0031.
7. REFERENCES [1] Jini Community, http://www.jini.org. [2] Bret A. Miller, Toby Nixon, Charlie Tie and Mark D. Wood, “Home Networking with Universal Plug and Play”, IEEE Communication Magazine, 192-197, 2005 [3] Havi Consortium, “HAVi Specification(ver 1.1)”, Specification of the Home Audio/Video Interoperability (HAVi) Architecture, 2001 [4] Yun-Young Hwang, Il-Jin Oh, Hyung-Jun Im, Kyu-Chul Lee, Kangchan Lee, Seungyun Lee, “UWS Broker for Ubiquitous Web Services Dynamic Discovery”, The 2007 International Conference on Intelligent Pervasive Computing(IPC-07), 2007. 10 [5] Jan Newmarch, “A Custom Lookup Service for UPnP Services and Jini Clients”, 2005 [6] Microsoft Corporation, “Web Services Dynamic Discovery (WS-Discovery)”, http://specs.xmlsoap.org/ws/2005/04/ discovery/ws-discovery.pdf, 2005
