分散系統管理機制應用於企業Web Services環境之研究

全文

(1)國立交通大學資訊工程系博士論文. 分散系統管理機制應用於企業 Web Services 環境之研究 Distributed Systems Management for Enterprise Web Services Environment. 研究生：吳瑞祥指導教授：袁賢銘. 教授. 中華民國九十六年六月.

(2) 分散系統管理機制應用於企業 Web Services 環境之研究 Distributed Systems Management for Enterprise Web Services Environment. 研究生：吳瑞祥. Student：Ruey-Shyang Wu. 指導教授：袁賢銘. Advisor：Shyan-Ming Yuan. 國立交通大學資訊工程系博士論文. A Dissertation Submitted to Institute of Computer Science and Engineering College of Computer Science National Chiao Tung University in partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy in. Computer Science. June 2007 Hsinchu, Taiwan, Republic of China. 中華民國九十六年六月.

(3) 分散系統管理機制應用於企業 Web Services 環境之研究. 研究生：吳瑞祥. 指導教授：袁賢銘. 國立交通大學資訊學院資訊工程系. 摘要 Web services 透過標準界面的制定，提供了企業系統整合的良好解決方案。 Enterprise Web Services Environment(EWSE)利用了這個優點，整合了企業的應用程式以及商業流程。雖然 EWSE 對整合帶來了相當多的好處，然後要為其加入管理機制並不容易。Web Services Distributed Management (WSDM) 是最常用來管理 Web services 的標準之一。然而，實作 WSDM 介面相當複雜，因為程式設計師需要了解許多相關的 Web services 標準以及開發 WSDM 相關的程式碼。此外，WSDM 只能管理單一服務，無法掌控服務間的互動以及訊息的流程。因此，EWSW 通常需要額外的軟體來處理這方面的問題。在這個研究中，我們將簡化 WSDM 介面實作的難度並提供 EWSW 的訊息導向管理機制。藉由必須開發的管理功能程式，自動產生 WSDM 的 Web services 介面。開發者可以專注於管理程式，毋須深入了解 Web services 標準。另一方面，在不更動現有程式邏輯的情形下，便可以為現有的 Web services 自動提供訊息流程導向的管理，讓系統管理者掌握系統服務的狀態，做為企業檢視服務的使用狀況。最後，我們將展示一個參考架構，做為企業建立管理系統的參考。提供企業在不耗費太多成本的狀況下建立一個有效率且具延展示的 EWSE 管理系統。. i.

(4) Distributed Systems Management for Enterprise Web Services Environment Student: Ruey-Shyang Wu. Advisor: Dr. Shyan-Ming Yuan. Department of Computer Science College of Computer Science National Chiao Tung University. Abstract Web services define standard interfaces those provide good solutions for enterprise integration. Enterprise Web Services Environment (EWSE) uses the advantage to integrate enterprise applications and business processes. Although EWSE is excellence in integration, it is not easy to add management mechanism. Web Services Distributed Management (WSDM) is one of the most used standards to manage Web services. However, to implement the WSDM interfaces is complexity because programmers have to understand many Web service standards and develop program code for WSDM. Besides, WSDM can only manage single service. It does not cover service interaction and message flows of Web services. EWSE needs additional software to handle those processes. In this research, we will simply the WSDM programs development effort and provide message flow oriented management in EWSE. The Web service interfaces are generated based on program code that implement management function and must be created. Programmers only focus on management functions and do not have to understand those Web services standards. On the other hand, the management system provides message flow oriented management atomically without modifying service code. Managers can know and control all flows as well as adjust business processes at any time. Finally, we present reference architecture for enterprise to build management system. Therefore, enterprise will not spend too much effort to build an efficient and extensible management system in EWSE. ii.

(5) 誌謝能完成本篇博士論文必須感謝許多人，首先感謝我的指導教授袁賢銘博士，謝謝老師多年來全力的指導並給予充分的發揮空間，才能學習到多方面的知識並獲得各種寶貴的經驗，也才能完成這份博士論文。同時也要感謝施仁忠教授、彭文志教授以及陳俊穎教授，對於論文中的架構、技術以及內容，適時給予重要的指引。在此要特別感謝所有的校外口試委員，曾黎明教授、楊竹星教授、鄭憲宗教授與羅文聰教授，在百忙之中給予我寶貴的建議，讓我可以讓本篇論文更加的完善。此外我也要感謝分散式系統實驗室的各位學長，張玉山、梁凱智、何敏煌、焦信達、葉秉哲、許瑞愷、劉旨峰、蕭存喻、林獻堂以及其他學弟們，在博士生涯中，給予我的幫助，讓我度過許多的難關。這邊要特別感謝葉秉哲、邱繼弘、鄭明俊，我們互相打氣，一起作研究，一起玩樂，一起寫論文。要不是你們，我的博士班生涯不會多采多姿，也不會充滿著歡笑。另外也要感謝系辦的楊秀琴小姐、俞美珠小姐、陳小翠小姐給予我的所有協助。最後將此論文獻給我的父母、大哥、二哥、妹妹以及惠屏，感謝你們一路的支持並提供我如此好的學習機會與環境，沒有你們，我不能在無後顧之憂的情況下，完成學位。求學的過程中，需要感謝的人實在太多，在此一併致謝。同時，希望在未來可以貢獻所學於社會上。. iii.

(6) TABLE OF CONTENTS. 摘要 . .................................................................................................................................................. i ABSTRACT .................................................................................................................................... ii 誌謝 ................................................................................................................................................ iii TABLE OF CONTENTS .............................................................................................................. iv LIST OF FIGURES ....................................................................................................................... vi LIST OF TABLES ....................................................................................................................... viii 1. . INTRODUCTION................................................................................................................. 1 . 2. . BACKGROUNDS ................................................................................................................. 5 . 2.1. . ENTERPRISE WEB SERVICES ENVIRONMENT ............................................................................ 5 . 2.2. . MANAGED RESOURCES ............................................................................................................ 7 . 2.3. . MANAGEMENT STANDARDS .................................................................................................... 9 . 2.4. . INDUSTRY SERVICE MANAGEMENT PRODUCTS ..................................................................... 11 . 2.5. . MANAGEMENT ARCHITECTURE ............................................................................................. 13 . 3. . MANAGEMENT ARCHETUCTURE FOR ENTERPRISE WEB SERVICES ........... 18 . 3.1. . OVERVIEW ............................................................................................................................. 18 . 3.2. . SYSTEM ARCHITECTURE ........................................................................................................ 18 . 3.3. . BUSINESS SERVICES & TECHNICAL OPERATIONS .................................................................. 23 . 3.4. . MANAGEMENT API................................................................................................................ 26 . 3.4.1. . ICapabilty Interface .......................................................................................................... 28 . 3.4.2. . Managed Resources .......................................................................................................... 30 . 3.4.3. . Data Type Mapping .......................................................................................................... 36 . 3.5. . HOOK API ............................................................................................................................. 38 . 3.6. . AGENT DESIGN ...................................................................................................................... 40 . 3.7. . MANAGEMENT APPLICATIONS & PROTOCOLS ....................................................................... 43 . 4. . WEB SERVICES PROCESS MANAGEMENT .............................................................. 45 . 4.1. . MANAGEMENT OF SINGLE SERVICE ....................................................................................... 45 . 4.2. . SERVICE COMPOSITION .......................................................................................................... 46 . 4.2.1. . Services Composition for Business Needs ........................................................................ 46 . 4.2.2. . Services Composition for Technical Needs....................................................................... 47 . 4.3. . ENTERPRISE WEB SERVICES PROCESS ................................................................................... 49 . 4.4. . MESSAGE FLOW ORIENTED MANAGEMENT ........................................................................... 51 . iv.

(7) 4.4.1. . Interoperability Standards ................................................................................................ 51 . 4.4.2. . Message Flow Tracking .................................................................................................... 53 . 4.4.3. . Dynamically Service Selection.......................................................................................... 55 . 4.4.4. . Exception and Error Handling ......................................................................................... 57 . 4.5. . ADVANTAGES OF MESSAGE FLOW TRACKING ....................................................................... 58 . 5. . REFERENCE ARCHITECTURE..................................................................................... 60 . 5.1. . WEB SERVICES FOR MANAGEMENT ....................................................................................... 61 . 5.2. . SAMPLE MESSAGES ............................................................................................................... 62 . 6. . EVALUATION.................................................................................................................... 64 . 6.1. . PROGRAMMING OVERHEAD ................................................................................................... 64 . 6.2. . RUN-TIME OVERHEAD ........................................................................................................... 66 . 6.2.1. . Hook API Overhead.......................................................................................................... 67 . 6.2.2. . Architecture Overhead...................................................................................................... 69 . 6.3. . SUMMARY OF EVALUATION ................................................................................................... 70 . 7. . CONCLUSION & FUTURE WORKS .............................................................................. 72 . 7.1. . CONCLUSION ......................................................................................................................... 72 . 7.2. . FUTURE WORKS..................................................................................................................... 73 . REFERENCES ............................................................................................................................... 75 . v.

(8) LIST OF FIGURES Figure 2-1 Relationship of Web Services and Three Fundamental Standards ..................... 5 Figure 2-2 Enterprise Web Services Environment ............................................................... 6 Figure 2-3 Management of Web services concepts ........................................................... 11 Figure 2-4 Enterprise Web Services Management Layer .................................................. 14 Figure 2-5 Agent-based Management architecture ............................................................ 16 Figure 3-1 Management System Architecture ................................................................... 19 Figure 3-2 Management Invocation Flow .......................................................................... 22 Figure 3-3 Enterprise Web Services Contains Business Services and Technical Operations ............................................................................................................................ 24 Figure 3-4 Web Services Endpoint Operation in MOWS .................................................. 25 Figure 3-5 Implementation Flow from WSDM WSDL to Program Code ......................... 26 Figure 3-6 Managed Resources and Capability Object in Management API .................... 27 Figure 3-7 ICapability Interface ......................................................................................... 29 Figure 3-8 The Program Code Generated Flow with ICapability ...................................... 32 Figure 3-9 Sample ICapability Interface Implementation Class ........................................ 33 Figure 3-10 Generated WSDL Elements Relation ............................................................. 34 Figure 3-11 Generated WSDL file ..................................................................................... 35 Figure 3-12 Request and Invocation Handler for Web Services ........................................ 38 Figure 3-13 Agent Internal Components............................................................................ 41 Figure 4-1 Web service create CoordinationContext from Coordinator service................ 48 Figure 4-2 Web Services Process Model ........................................................................... 50 Figure 4-3 Message Flow among Web Services ................................................................ 51 Figure 4-4 Message Flow with Service C Error................................................................. 56 Figure 5-1 Reference Architecture for EWSE ................................................................... 60 Figure 5-2 Management Applications Request WSDL...................................................... 62 Figure 5-3 Management applications invoke Start() .......................................................... 63 Figure 6-1 injection Overhead comparison ........................................................................ 68 . vi.

(9) Figure 6-2 Two Different Services Containers for Business Services and Technical Operations .......................................................................................................... 70 Figure 7-1 Disconnected Web Services Processes............................................................. 73 . vii.

(10) LIST OF TABLES Table 3-1 Data Mapping between Web Services and Java Class....................................... 36 Table 6-1 Comparison between Bottom-up and Top-down Approach for Technical Operations of Web services ............................................................................... 65 Table 6-2 Hook API Testing Environment ........................................................................ 67 . viii.

(11) 1. INTRODUCTION. Recently, Web services have become pervasive and critical to business operations in enterprise. They simplify interoperability and application integration. They provide a means for wrapping existing applications so developers can access those applications through standard languages and protocols. For the reason, many corporations make the effort to build the Enterprise Web Services Environment (EWSE), which integrates enterprise applications and supports business operations by using Web services technologies. In EWSE, enterprises can flexibly solve enterprise-wide integration challenges and thereby quickly address ever-changing business challenges and opportunities. EWSE contains not only Web services but also service interactions. Those interactions between Web services are the key to support business process. Once services and business processes become operational, their progress must be managed and monitored to offer a clear view of those services perform within their operational environments. Besides, those services and business processes should provide a way to perform control actions to modify and adjust their behaviors. Therefore, managers will know enterprise status and make response quickly. To archive the goals, it requires distributed management solutions for EWSW. Management in this case is defined as a set of capabilities for discovering the existence, availability, health, and usage, as well as the control and configuration of resources, where resources are defined as Web services, components of the Web services architecture, as well as roles undertaken in this architecture. It does not 1.

(12) only handle single service status, but also cover service interaction and business process. Although there are many Web services management standards, most of them cannot cover both single service management and services interactions. They usually define Web services management interfaces for management operations as well as message parameters. Because those management standards use Web services technology, different management applications and services can exchange information easily. However, those standards focus only on management protocols and functions. It means that both system designers and developers have to pay extra efforts for those management protocols and functions. Because management functions cannot solve business problems directly, some corporations may feel that developing those functions waste many resources. In the meantime, controlling and monitoring single service are not enough. Without handling services interactions properly, it is not easy to guarantee that they can deal with all requests accurately. Some industry products and standards provide functions to manage business processes, like Business Process Execution Language for Web Services (BPEL4WS). It defines application interfaces to develop a service and use an engine for business processes execution as well as services communications. Conforming to the standards, all Web services should follow the application interfaces and can only interact with the engine. The drawbacks of this architecture are that a Web service cannot be managed out of engine. Besides, developing a service becomes very complex because programmers have to follow the application interfaces. For the reason, it is necessary to develop a solution that can manage business process without complex developing.. 2.

(13) Because management in EWSE is quite different from traditional enterprise systems, it will have different requirements and solutions. It should solve the following problems: 1. A uniform management interface: a uniform management interface can manage all services from a single management application. It will define how to monitor service status and configure services to archive management goals. A uniform and standard interface can reduce system administrator’s effort. In EWSE, Web services technology is a good choice to create the interface. 2. Services interoperability monitor: services interoperability can composite complete. services. or. business. processes.. Tracking. and. handling. interoperability can show not only the status of each service request, but also the entire EWSE status. 3. Integration with existed environment easy: to add management functions, applications have to be modified many program code. For SOA, the program code is usually very complex. It is necessary to make it become easy. In this dissertation, a distributed management mechanism for EWSE is proposed. It provides management interfaces for each Web services and handles message flows among services with the minimal effort. Programmers can only create the management functions without writing Web services definitions and knowing several standards. Because the Web services definitions and codes are generated, programmers can more focus on management functions. On the other hand, using Aspect-Oriented Programming (AOP), the message tracking features can be added into existed system without modifying service code. At system run-time, because the management service and business service are separated, they will not influence each other. It can guarantee the performance of business services. Finally, we 3.

(14) provide reference architecture for adding management features in EWSE. Enterprise can use the management mechanism to build up better quality services and then enhance its productivity as well as competitiveness. The dissertation is organized as followed: Chapter 2 introduces the backgrounds and industry status. Chapter 3 shows our management architecture and components. Chapter 4 will discuss the interactions between Web services and monitor mechanism. Chapter 5 is the reference architecture and program examples. Chapter 6 will evaluate the system. Finally, Chapter 7 is the conclusion and future works.. 4.

(15) 2. BACKGROUNDS. 2.1. ENTERPRISE WEB SERVICES ENVIRONMENT Web services are architectural styles whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. The attractiveness of Web services is its open architecture. By defining standard invoking. methods,. different. services. with. different. implementation. heterogeneous platforms can be integrated together smoothly.. Figure 2-1 Relationship of Web Services and Three Fundamental Standards. 5. on.

(16) Web Services is based on XML [7] and defines three fundamentals standards, showed as Figure 2-1. SOAP (Simple Object Access Protocol) [14] can invoke other services; WSDL (Web Service Definition Language) [15] can describe the interfaces of a service; UDDI (Universal Description, Discovery and Integration) [31] can be used to find the location of the service that is needed. Web Services can also support several transportation protocols, such as HTTP and MOM (Message-Oriented Middleware). Because Web Services has those characteristics, it can be rapidly deployed on many different platforms and let them to work together. EWSE uses Web services technology to create the flexible information technology (IT) environment. Figure 2-1 shows its architecture.. Figure 2-2 Enterprise Web Services Environment. EWSE integrates enterprise application to support business operations. Top of the figure is business operations. Every corporation owns their business processes, 6.

(17) such as order process or manufacture process. Enterprise managers have to define those processes in some systems, execute them and monitor their performance. To perform a business process, many enterprise applications are involved. The middle layer of Figure 2-1 shows the interoperability. The services interaction will fulfills business process. The fundamental applications exposes Web services and are composed at this layer. Those applications are at the bottom of the figure. Because all applications use Web services technology and follow standards, EWSE provide good solution for message exchange to narrow the gap in integrations.. 2.2. MANAGED RESOURCES A managed resource is the management information which, from the management point of view, describes a resource to be managed, monitored, and controlled. In other words, a managed resource is an abstract representation of a real entity to be managed. The real entities in distributed systems (such as network devices, end-user applications, etc.) need to be captured and represented as managed resources. . A managed resource is an abstraction that is available to the manager and services. Some other mechanism, outside the scope of management architecture, maintains the relationship between the managed object and the actual resource.. . A single managed resource may represent a single resource or many resources.. . The same resource may be represented by a single managed object or by a number of different objects, each representing a particular aspect of the resource. 7.

(18) . Not all resources need to be represented by a managed resource. This does not mean that such resources do not exist, only that they are not available to the management system.. The concepts for describing objects and information relevant to management are collectively called information models. The information model approach used to described managed objects could be entity-relationship, data-type, or object-oriented. For example, Internet management uses simple data types (scalars and two-dimensional arrays of scalars) to represent managed objects. OSI management on the other hand uses an object-oriented approach for its information model. For each managed resource, the following items should be considered: 1. Identification: It describes basic information of a services and static management information, such as relationship of other services and standards that are supported. 2. Availability: A service should avoid system failures to response correct information to the client. 3. Metrics: Evaluate the performance and health of services. 4. Operations: Operations are all function of a service. They include business and technology functions. 5. Configuration: A service behavior will change if the service configuration is changed. 6. Events: By defined events, management system can notify system managers or other procedures to take this event.. 8.

(19) 2.3. MANAGEMENT STANDARDS There are many standards those define the communication protocol and what agent should have, such as SNMP (Simple Network Management Protocol) [1] DMI (Desktop Management Interface) [2] , CIM (Common Information Model) [3], WBEM (Web-Based Enterprise Management) [5] and WSDM (Web Services Distributed Management) [6]. All of them provide communication protocols and programming interface so that they can be used for most applications. The SNMP is an application layer protocol that facilitates the exchange of management information between network devices. It is part of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite. SNMP enables network administrators to manage network performance, find and solve network problems, and plan for network growth. SNMP is widely deployed in many systems because it is quite simple and easy to use. However, using SNMP, the interfaces should be defined during program compiling time. It cannot add and more a managed unit dynamically. The Desktop Management Interface (DMI) provides management protocol and architecture. Every computers and hardware are installed a single agent that can collect all management information. Unlike SNMP, it is unnecessary to install agent for each component and can add management functions dynamically. Although DMI can integrate management information on a single computer, it does not define methods to collect information from several computers in a distributed environment. CIM is developed to solve the problems. It has management interfaces and the models that describe the relationship between manageable components. Based on the model, each component can exchange 9.

(20) information and the whole system can be managed. Because those components in a model should be tied together, DMI is not suitable for those components that are loosely coupling. In other words, if a unit is unknown at design time, it cannot be managed by DMI. JMX provides a Java technology framework for building distributed, Web-based, modular and dynamic solutions for managing as well as monitoring devices, applications, and service-driven networks.. Its management standard defines a. complete management architecture for Java applications, including an API to instrument applications with manageability. JMX, an open technology suitable for management and monitoring wherever these are needed, is a standard expressly designed for adapting legacy systems, implementing new management and monitoring solutions and plugging into future devices. JMX standard enables Java applications to be managed without heavy investment, including an API to instrument applications with manageability. JMX also uses protocol adapters to enables Java to integrate with existing management solutions. On the contrary, WSDM is a set of management specifications from the WSDM Technical Committee in OASIS that provides more structures and semantics for a manageability interface than JMX does. WSDM contains two major specifications, Management of Web services (MOWS) and Management using Web services (MUWS). The WSDM specification defines how the manageability of Web service endpoints and resources exposed as Web services can be accessed via Web services. In order to achieve this goal, MOWS is based on the MUWS specifications, and the architecture, definitions and dependencies thereof MUWS. WSDM is suitable for heterogeneous environment. In most Web services, it is selected as management standard.. 10.

(21) Figure 2-3 Management of Web services concepts. MUWS uses Web services to achieve easier and formal management of distributed information technology resources. This is accomplished by providing a flexible framework for manageability interfaces that advantage key features of Web services and protocols. Figure 2-3 describes the concepts: the manager employs a Web service endpoint adapter for a resource. Currently, the focus of the MUWS specification is on how to provide access to manageable resources, which are the central element and focal point of the WSDM architecture. The message patterns encapsulate access to resources into manageable resources instead of exposing them to indirect access to resources through such as agents, proxies, or observers. MUWS benefits greatly from Web services technology, for example from isolation from implementation and easily understood representation.. 2.4. INDUSTRY SERVICE MANAGEMENT PRODUCTS Many software products provide management capabilities for enterprise software well, including commercial products and open source software. Since enterprise Web services environment is more and more popular, Web services management. 11.

(22) has became one of the most features for the software. Some famous software includes:. Tivoli [33] IBM provides a complete management product, Tivoli. It has business process management and control managed resources. It provides API for developing management applications. Tivoli also has a rich client that can monitor and control managed resources. Tivoli can be easy to integrated with IBM products and widely used in industry. Recently, IBM adds WSDM specification into the product so that it can communicate with other company products easier.. Unicenter products [30] Computer Associates sells a management product suite Unicenter, which contains the product WSDM. WSDM enables different management areas, predominantly performance and security. The monitoring modules (called management observers) and security enforcement points can be implemented as SOAP processing handlers inside application servers or as independent proxies. Both business activity monitoring and business-level agreement management are driven by policies defined with WSDM.. AmberPoint [29] AmberPoint has several products for WSM: Express, Management Foundation, Service Level Manager, and Exception Manager. These products address different management functional areas. The closest to my research is AmberPoint Service 12.

(23) Level Manager that enables definition (using Web forms), monitoring, and management of custom-made SLAs. Human administrators play the central role in these activities, particularly management. Monitoring is performed by agents, which can be plugged into provider Web services or executing between Web services as proxies or T-filters (T-filters observe the traffic, but do not act as intermediaries). The other two important components of the AmberPoint architecture are decentralized task-specific analytical servers that process management information and distributed management applications for interaction with human administrators. All of those products are devoted to provide easy-to-use and rich functions for application management. Although they have powerful functions, programmers still have to pay great efforts to develop management functions. Programmers should follow their architecture and APIs so that the service can be managed. If an existed service needs to be managed, extra code is needed and the service has to be rewritten. Besides, most of those products focus on single Web services management. However, one business operation usually needs cooperation of several services. In other words, if one service has problems, it will make the business operations failure. For the reason, a complete management system should control the whole enterprise service environment, not only single service.. 2.5. MANAGEMENT ARCHITECTURE The management model for enterprise Web services can be separated as six layers, showed as Figure 2-4. The lower four layers access managed resources and upper two layers are used for service cooperation. The former collects information from hardware resources or software application; the latter coordinate the information 13.

(24) and make those services co-work. Assuming that the interfaces between the layers do not change, the layered architecture allows changes to occur within the layer in relative isolation without affecting the other layers. This improves the scalability of the architecture as well as quality and testability.. Figure 2-4 Enterprise Web Services Management Layer. 1.. Physical Layer: The bottom layer or platform layer describes physical elements that are being managed. This includes such things as processors, disk drives, memory, controllers and sensors.. 2.. Logical Mapping Layer: This layer consists of software drivers and providers used to map logical representations to the physical elements within the platform layer. Communications with the physical elements such as software and firmware create logical elements that are associated to physical elements.. 3.. Aggregation Layer: The Aggregation layer is responsible for the aggregation of logical representations to various data models used to correlate and describe the managed elements. This layer creates static and dynamic. 14.

(25) elements that may be used to represent information to the logical mapping layer. 4.. Access Layer: The access layer passes control and monitoring information between the management system and the managed node. This layer decodes the requests and passes them to various lower layers.. 5.. Resource Management Layer: The Resource Management layer, within the management system, enables the system to request and parse responses for resource management functions. This layer establishes the connection, encodes the request, decodes the response, detects any request failures and then passes the response back to the management system.. 6.. Orchestration Layer: The optional Orchestration layer provides a higher level of capability to management systems. This layer provides a level of management as it enables policy-based management via a policy engine with defined services levels. This layer, which sits on top of the resource management layer, reviews information and events and perform automated actions based on sets of predefined conditions. Most management application and standards focus on layer 4 and layer 5, especially in distributed environment because the management application and managed resources are not at the same host. Agent-based is the most common solution architecture for communication between layer 4 and layer 5, showed as Figure 2-5.. 1. Management applications: the console provides management information that comes from managed units. It displays system status, usages, and related. 15.

(26) information. It can also set system configuration for each components. By management applications, the system administrator can control the whole system status.. Figure 2-5 Agent-based Management architecture. 2. Agent: the agents are installed at the managed resources. Agent is the bridge between management applications and managed resources. For each resource, the agent collects management information and sets configuration for this unit. It will also communicate with the management applications to send management information and get setting data. 3. Communication Protocol: the communication protocol defines the way to let agent and management applications to exchange information. The protocol will define how to initial the connection between the management applications and the agent. It will also define how to get information from agent and send configuration to agent. 16.

(27) In this research, the management system will focus on layer 3 to layer 6 and use agent architecture. It will try to plug management functions into Web services easy, provide necessary information to management applications and orchestrate business processes.. 17.

(28) 3. MANAGEMENT SERVICES. ARCHETUCTURE. FOR. ENTERPRISE. WEB. In this chapter, we will present the management architecture and system implementation. The discussion about message tracking and management mechanism are showed in Chapter 4.. 3.1. OVERVIEW To provide flexible and extendable management architecture in EWSE, the agent-based architecture is proposed. Agent can collect management information from managed resources and provide the information to the management applications using the predefined protocols. Then, system administrator can monitor and control the services. The proposed management system is developed in Java environment with JavaEE architecture. Although there are many Java-related implementation in this system, the same concept can be applied other architecture or programming language, for example Microsoft Web services architecture and C#.. 3.2. SYSTEM ARCHITECTURE The management system architecture is showed as Figure 3-1. In this architecture, several components are designed and mapped to the layers in Figure 2-4 so that each component has its major functions and can communicate with each other well.. 18.

(29) Those components include Management applications (Layer 5, 6), Agent (Layer 4), Management API/Hook API (Layer 3) as well as Policy & Configuration.. Figure 3-1 Management System Architecture. For each service, it will integrate Management API / Hook API. The two APIs are responsibility for monitoring Web services status and providing necessary information to agent. The APIs can monitor the whole process from invoking service to returning result. When a request is sent to the services, the APIs captures the request first. They will process the request and record necessary information. All messages in EWSE should contain an identification content added by other Management API/Hook API in the management system. The content is useful for message flow tracking. The two APIs will process not only incoming but also outgoing message. If a service issues requests to another service, the APIs will involve the request before the message is sent. They add message tracking 19.

(30) information into the message. Therefore, all messages flows in the management system are monitored. Agent is deployed between Management applications and services as well as exposes WSDM interfaces. It reads the system policy and configuration from the database, gets service status from Management API/Hook API, and communicates with management applications. Because Management API/Hook API exports configuration operations for services, Agent can get services status quickly and set parameters to services directly. On the other side, the management information will send to management applications when it requests. Management applications can also send service parameters to Agent to adjust service behavior. For each host, there is only one Agent deployed. In other words, each service would not have the WSDM interfaces. All managed resources only communicate with Agent but not management applications directly. Agent handles those interfaces. It will provide communication interfaces for both managed resources and management applications. Management API/Hook API collects information from managed resources and sends to Agent; on the other side, management applications can query or send data from or to Agent. Single management interfaces on Agent can reuse the similar management functions and coordinate resources needed for management purposes. If Agent is not here, management applications have to build several connections for each service and managed resources have to create management interfaces by themselves. On the contract, with Agent, the number of connection for a host is only one. Agent helps to reduce Web services implementation effort and improve system performance. For each Agent, Policy & Configuration database is deployed. It is the storage that Agent can read and save information. Because the policy or configuration is. 20.

(31) complex and consisted by many parameters, it is not easy that management applications set those parameters one by one, especially when parameters may affect each other. One error would cause service crash. Each Agent can save those parameters by themselves. If necessary, those settings can be retrieved quickly. It guarantees system stability and save configuration effort. Because there are many heterogeneous systems in an enterprise, it will become very difficult to manage them if each system has its own management methods. For example, if there are ten systems and each of them has specified protocol, the management applications should implement ten protocols. For the reason, a common communication protocol is necessary. The management applications can get information or set configuration from/to Agent by using the consistent protocol. Using standard protocols can let that Management applications developed by different vendors can communicate different Agents. For each component in this architecture, the invocation flow is showed in Figure 3-2. There are four operations in this flow: (1) Client invokes Enterprise Web Services. Every invocation is intercepted by Management/Hook API. The APIs will process the request SOAP message and resend it to the actual services. When the request is completed by the service and it will return data to the client, the return data is also intercepted by the APIs. The APIs will add management information into the return message. Finally, the APIs will return result to the client. During the processing, enhanced message is used between the client and the APIs. Therefore, management system can control message flow more precisely.. 21.

(32) Management Console. Agent. Management / Hook API. Enterprise Web Services. Services Client. InvokeService InvokeService ServiceReturn ServiceReturn ServiceStatusReport ServiceStatusReport ServiceConfigChange SetServiceParameter SetServiceParameter ActiveMonitor QueryStatus ReturnStatus CollectStatus Notify. Figure 3-2 Management Invocation Flow. (2) Management applications get services status from Agent. After invoking services, Management/Hook API will collect invocation information. The APIs will report that information to Agent. Agent will coordinate the information and save into database. When Management applications request the information from Agent, Agent will retrieve them from database and send to management applications. Agent has standard operations based on MOWS and MUWS for management applications to lookup services and get management information. For the reason, different management applications can communicate with Agent well. (3) Management applications send configuration to services. If system administrators want to adjust service behavior, they can specify configuration. 22.

(33) from management applications. The configuration may influence several services. Management applications will send parameters to corresponding services based on the configuration. After Agent gets those parameters, it will change services configuration using Management/Hook API. (4) Management applications are notified when events occurred. After Agent startups, it continues to monitor services status through Management/Hook API. The API can query services status. If there are any events, Agent will get the message. Then, it will send a notification to management applications. System administrator will recognize the events quickly.. For the traditional architecture, each service has to implement those management interfaces. It increases implementation efforts. Besides, once the management interfaces changed, all services has to be re-implemented. At the run-time, Management applications has to connect to each service by themselves. It will increase management overhead. While Agent controls all services on a host, not only management functions can be controlled but also the management overhead can be reduced. Before describing detail design for every component, a characteristic of the enterprise web services is introduced. Each service contains several operations. They can be distinguished as Business Services and Technical Operation roughly.. 3.3. BUSINESS SERVICES & TECHNICAL OPERATIONS Every service in enterprise is built for business purpose. It solves specified business problems. For example, a ProcessOrder operation in a service is used to. 23.

(34) handle order. Those operations can be mapped to business purposes. However, it is not enough if there are only business services. In distributed environment, some technical operations are also provided to support specified technical requirements. Most Web services export WSDL for service consumers to retrieve service description so that the consumers can know how to invoke the service. For the reason, technical operations are also important. A server that can perform business services well relay on those technical operations.. Figure 3-3 Enterprise Web Services Contains Business Services and Technical Operations. Generally, Business Services fulfill business requirements and those requirements are usually different. Therefore, only the different business requirements are implemented. If there are similar requirements at two systems, there will be only one implementation and the other will reuse it. On the other hand, Technical Operations at different services are similar. For example, if one service needs transaction support, it has to implement those technical operations and protocols of Web service transaction. Because those 24.

(35) requirements are similar, a reused program code can be created and all systems will use it. In the management system, there are several necessary PortType and context, showed as Figure 3-4. In the description, the OperationMetrics specify the complex property of operation metrics. For developers, each service has to implement OperationMetrics so that service metrics can be accessed. Otherwise, it cannot be accessed by the Management applications. However, the metrics operation is similar. It can be implemented once and other services re-use it to save the development effort.. Figure 3-4 Web Services Endpoint Operation in MOWS. On the other hand, it is not easy to plug the management technical operations into an existed service if they are not existed in a service. The general steps to add the management functions are showed as Figure 3-5. First, a WDSL file is necessary. It can generate the skeleton and stub for serve side and client side, respectively. Then, developers can develop the service using the generated code. Finally, the service has to be deployed at the server. The procedure takes a lot of time. For most managers, they do not accept to spend resource when the Business Service does not change. For the reason, an efficient way is necessary. 25.

(36) Figure 3-5 Implementation Flow from WSDM WSDL to Program Code. 3.4. MANAGEMENT API To access and configure services are the most fundamental functions in a management system. It is also the most important part. However, it usually costs a lot of time to develop those access and configuration functions. Although there are many management products, most of them provide APIs that focus on management protocol and management applications. Programmers still have to follow the management architecture and APIs carefully when developing a service. Otherwise, the service cannot be managed. In EWSE, it is necessary to define managed resources and provide concise software libraries for developers. Developers, then, can write the management code using those libraries. For the reason, an approach that can generate Web 26.

(37) services interfaces and add management capabilities into services is proposed. They are Management API. Management API provides functionalities those will get the status of managed resource. Programmers can export service status to agent using this APIs.. Figure 3-6 Managed Resources and Capability Object in Management API. Management API focuses on how to export managed resource status and management functions to the management applications. It contains management capabilities and management resource. Management capabilities indicate what kind of capabilities the resources are. One resource may contain several management capabilities. Their relationship can be showed as Figure 3-6. Those capabilities and resources are associated with a physical hardware or Web services.. 27.

(38) Those capabilities contain management information and operations those describe the status and operations of the back-end resources. The managed resources expose the capabilities to be used in management for Agent.. 3.4.1. ICAPABILTY INTERFACE. The capability represents management properties and operations for a service. It is atomic unit in the management system and contains the capabilities of a resource. Single capability shows one kind of management information for a resource. For the reason, a resource will have several capabilities. The capability is represented as a Java class and defines an interface for this kind of class. There is an interface class, ICapability, which uses both WS-Resource as well as WSDM specification and defines several methods, showed as Figure 3-7.. 1. import javax.xml.namespace.QName;. 2 3. public interface ICapability. 4. {. 5. // Capability lift-cycle control methods. 6. void initialize();. 7. void initializeCompleted();. 8. void shutdown();. 9. void shitdownCompleted();. 10 11. // Get properties for management based on WS-Resource Framework. 12. QName[] getPropertiesName();. 13 14. // Get operation names for management. 15. String[] getOperationNameforManagement();. 16. 28.

(39) 17. // Web Services specified methods. 18. String getNamespaceURI();. 19. String getNamespacePrefix();. 20. }. Figure 3-7 ICapability Interface. ICapability interfaces only use simple Java language features so that programmers do not concern about WSDM and WS-Resource specification. Programmers only create a capability class that implements the interface. They only indicate the management operations, properties as well as information of Web services for management.. Two. methods. of. the. interface,. getPropertiesName(). and. getOperationNameforManagement() shows properties and operations of resources respectively. In the implementation class, the getPropertiesName() will return all properties of this capability. The method uses WS-Resource specification and defines each property as QName. At the same time, the implementation should contain all getter and setter methods for all properties. Therefore, Management API. can. know. the. properties. of. the. capability. implementation. by. getPropertiesName() and access them by those getter/setter methods. Another method getOperationNameforManagment() is the similar and shows the operation names for the managed resrources. The different is that the getter and setter methods are not implemented but the methods in the returned names should be implemented. In this case, the capability can expose properties for management and operations to use. The properties and operations in ICapability implementation class should implement and provide management functions as well as information of a resource. The managed resource components will access them only through ICapability. 29.

(40) implementation class. For the reason, the properties and operations should use APIs of the resource to get the actual status. There are another two methods related to Web services: getNamespaceURI() and getNamespacePrefix(). The two methods define the namespace used in generated WSDL. file.. The. namespace. is. formatted. as. “http://schemas.xmlsoap.org/wsdl/soap/” and prefix is “http”. They are used to generate the namespace of XML schema in the WSDL file. The schema can describe the content so that elements and attributes in the WSDL are correct. To. handle. capability. life-cycle,. there. are. four. methods,. initialize(),. initializeComplete(), shutdown(), and shutdownComplete(). When the capability implementation class startup, the initialize() method is called. When all capability implementation classes associated with the same resources startup completely, the initalizeComplete() method will be called. The same for shutdown() and shutdownComplete(). When the capability class start to shutdown or the associated capabilities are shutdown completely, shutdown() and shutdownComplete() will be called, respectively. After creating ICapability implementation classes, Managed Resource components will process the interface definitions and expose those classes as Web services.. 3.4.2. MANAGED RESOURCES. Every ICapability implementation class should register itself with Managed Resource components. The Managed Resource component will take two major actions: 1. During deployment, Managed Resource will generate WSDM related files and classes. Those files include WSDL and resource description. Those classes will 30.

(41) have the Web services features classes those are corresponding to ICapability implementation class and WDSL file. At this phase, error detections are added. For example, if the getter and setter methods for a property are not found, a WS-Resource property error will be raised. 2. During run-time, Managed Resource will aggregate those ICapability implementation classes as management functions and expose them to Agent. Agent, then, can access the system information and manage it through Managed Resource components. Besides, Managed Resource components also take care the life cycle of every capability. It will invoke the four life cycle methods at right time.. Generate the Web services related files can simply developing complexity program and save implementation effort. The generated flow is showed as Figure 3-8. ICapability helps to generate the WSDM WSDL. The WSDL will produce the skeleton and stub as the traditional flows. After the generated program, a specified classes, Service Management Functions, is created, which will use the ICapability implementation classes. Because ICapability classes have implemented the management function, the Service Management Functions can use them directly without writing the program again. Programmers can only write the ICapability only when creating WSDM interfaces; on the contract, in the traditional program model, programmers have to create both management functions and WSDL by themselves. For the reason, the developing process is much simplify.. 31.

(42) Figure 3-8 The Program Code Generated Flow with ICapability. To generate the Web services files and classes, programmers only write the implementation class. Figure 3-9 shows the sample code for the implementation of ICapability. Parts of code, such as life cycle control methods, is omitted to save space. 1. package org.dcslab.wsdm;. 2 3. public class MailServerCapability implements ICapability. 4. {. 5. String NAMESPACE_URI = "http://ws.cis.nctu.edu.tw/org/dcslab/wsdm";. 6. String PREFIX = "http";. 7 8. public QName[] getPropertiesName() { QName[] PROPERTIES = {. 9 10. new QName(NAMESPACE_URI, "Name", PREFIX),. 11. new QName(NAMESPACE_URI, "Port", PREFIX). 12. };. 13. return PROPERTIES;. 14. }. 32.

(43) 15 public String[] getOperationNameforManagement() {. 16 17. String[] OPERATIONS = { "start","stop" };. 18. Return OPERATIONS; }. 19 20. public String getNamespaceURI() {. 21. return this.NAMESPACE_URI;. 22 23. }. 24. public String getNamespacePrefix() { return thus.PREFIX;. 25 }. 26 27 28. // Methods for management. 29. public void setName(String name);. 30. public String getName();. 31. public void setPort(int port);. 32. public int getPort();. 33 34. public void start();. 35. public void stop();. :. :. :. :. :. }. Figure 3-9 Sample ICapability Interface Implementation Class. In. the. MailServerCapability. class,. getPropertiesName(). and. getOperationNameforManagment() are implemented. Method getPropertiesName() will return two properties: name and port. Therefore, there are getter and setter methods for the two properties. As for getOperationNameforManagement(), two strings are returned, start and stop. So, there are two methods, start() and stop() in the class. Managed Resource components invoke the two methods to get properties. 33.

(44) as well as operations name and generate the WSDL file. Because the generated WSDL is too long to show, only the major elements and their relation are showed as Figure 3-10. It will have a PortType: MailServerPortType and many operations. The Bindings part indicates the binding type and operation encoding. Finally, the Services part shows the server location. Parts of the WSDL file is showed as. Figure 3-10 Generated WSDL Elements Relation. <wsdl:definitions name="MailServerResource" xmlns:tns=http://ws.cis.nctu.edu.tw/org/dcslab/wsdm ...> <wsdl:types> : <xsd:schema elementFormDefault="qualified" targetNamespace="http://ws.cis.nctu.edu.tw/org/dcslab/wsdm"> <xsd:element name="Start"/> <xsd:element name="StartResponse"/> <xsd:element name="Stop"/> <xsd:element name="StopResponse"/> : <xsd:element name="Name" type="xsd:string"/> <xsd:element name="Port" type="xsd:integer"/>  <xsd:element name="MailServerProperties"> <xsd:complexType> <xsd:sequence>  <xsd:element ref="wsrf-rl:CurrentTime"/>. 34.

(45) <xsd:element ref="wsrf-rl:TerminationTime"/> <xsd:element ref="tns:Name"/> <xsd:element ref="tns:Port"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> : </wsdl:types> : <wsdl:message name="StartRequest"> <wsdl:part name="StartRequest" element="tns:Start"/> </wsdl:message> <wsdl:message name="StartResponse"> <wsdl:part name="" type="xsd:anyType"/> </wsdl:message> : <wsdl:portType name="MailServerPortType" wsrf-rp:ResourceProperties="tns:MailServerProperties"> : <wsdl:operation name="Start"> <wsdl:input name="StartRequest" ....> <wsdl:output name="StartResponse" ....> : </wsdl:operation> : </wsdl:portType> : </wsdl:definitions>. Figure 3-11 Generated WSDL file. In the generated WSDL file, the properties and operations, defined in MailServerCapability class, are used to generate the XML schema, WSDL message and WSDL port type. Managed Resource components do not only invoke. 35.

(46) the two methods of the capability class but also analyze the properties and operations to get the data type of input parameters and return value. They are defined in the XML schema so that future invocation will use correct data type.. 3.4.3. DATA TYPE MAPPING. Data type mapping focuses on data transformation between Management / Hook API and Web services, and vice versa. In most enterprise environment, the data format for management is defined as static because it is seldom changed. Because system has to test data format and cast it to correct type, it will cost more resource at run-time if every data is always treated as dynamic. For the reason, the static Java object is used in the production environment. The mapping is showed as Table 3-1.. Table 3-1 Data Mapping between Web Services and Java Class Web services data type. Java Class. xsd:base64Binary. byte[]. xsd:boolean. boolean. xsd:byte. byte. xsd:dataTime. java.util.Calendar. xsd:decimal. java.math.BigDecimal. xsd:double. double. xsd:float. float. xsd:hexBinary. byte[]. xsd:int. int. xsd:integer. java.math.BigInteger. xsd:long. long. xsd:Qname. javax.xml.namespace.QName. xsd:short. short. xsd:string. java.lang.String. 36.

(47) When Managed Resources components generate WSDL from capability implementation class, those properties and operations can only use those classes in Table 3-1. In other words, programmer cannot define Java class as a property, operations parameters and return values. The reasons are: 1. The data class should be checked carefully so that it can be transferred. For Java, the data class must implement java.io.Serializable and follows serialization rules. 2. If programmers use data classes by themselves, the corresponding WSDL should contains XML schema for them. There will be a very complex <complexType> … </complexType> elements when the data class has many fields and methods. It will make a huge WSDL file. A huge WSDL file means huge SOAP message and causes bad performance. 3. For management applications, they have to discover the description of the data class from the WSDL or SOAP request/response. When WSDL changed, management applications have to recognize the change and product new client program so that it can access the management information. However, if there is only primitive data type, the process can be skipped. It can get the information from SOAP message directly.. Although there are only primitive data types, the management system still support complex data. Several capability classes can be associated with a single resource. A capability class is responsible for one management information. Using several capability classes can describe complete information for the resource.. 37.

(48) 3.5. HOOK API In enterprise, a business requirement usually involves several services. Those services have to interoperate and exchange information so that the whole the requirement can be satisfied. For the reason, it is common that one Web service invoke another service when it processes request. In enterprise environment, linking invocation chain helps to manage services. To monitor the activity of the service, all requests and invocation will be recorded for future query, showed as Figure 3-12.. Figure 3-12 Request and Invocation Handler for Web Services. The Message flow ID contains four elements: 1. ID: a unique id that represents the Message flow ID. 38.

(49) 2. Source: the Web service that sends the request. 3. Time_sent: the time that the source Web service sends the request. 4. Time_resp: the time that the source Web service gets the response.. Request Handler The handler will process request/response message to/from the service. When a message arrives, it will intercept and process the message. If a message flow ID is in the message, the handler will insert the message flow id in the Message flow ID Mapping Table. Otherwise, a new message flow id is generated and inserted into the table. Then, the message will be forwarded to the corresponding Web services implementation program. After the service completes the request, it will return result to the caller. The handler will intercept the message again and look up the corresponding message flow id in the table. It will insert Message Flow ID into message and remove it from the Message Flow ID Mapping Table. Finally, the response message will be returned to the caller.. Invocation Handler When the service invokes another Web services, the Invocation Handler will intercept the messages. The handler will do two things: (1) it will add Message Flow ID into the message. The Invocation Handler will look up Message Flow ID Mapping Table to get Message Flow ID. If there is existed ID, it will use it directly. Otherwise, it will create a new one. Invocation handler will put Message Flow ID into the SOAP message that is sent to the target service. At the same time, it will also append the Web services Port data of the destined Web services to that ID in 39.

(50) the table. (2) If necessary, it will redirect the message destination to another one. For example, when the destination service is down for maintenance, the request should be handled by another service.. Message Flow ID Mapping Table The table provides insert, query and remove functions. Besides, the table will keep all operations and request/response time for query services invocation status. The table can not only provide the response time of the service, but also present the correct time of message arrived and returned. Besides, several messages can be linked together with the message flow ID. It is useful to monitor the business activities in the Web service environment.. Under the architecture, if service A invokes service B and, then, service B invokes service C, they will all have the same message flow ID. From management perspective, the invocation flow is displayed and the relationship of those services can be known. The detail discussion is showed in section 4.2, 4.3 and 4.4.. 3.6. AGENT DESIGN Agent in the management system is the bridge between management applications and capability implementation class. It has the following features: 1. Web services interface: Agent exposes every Managed Resource as Web services. In the capability implementation class, the namespace URI is specified. The path of URI will be service location in Agent. Management. 40.

(51) applications will only use those Web services interfaces to communicate with resources. 2. Basic technical management information: Agent can provide basic metric information. For example, the response time of a service. 3. Service configuration: Agent can read configuration from the registry and send those configuration to the corresponding services. Besides, if there is configuration sent from management applications, Agent could also set the related Managed Resource. 4. Security: security features can guarantee that only authorized clients can access the information.. Figure 3-13 Agent Internal Components. 41.

(52) Agent internal architecture is showed as Figure 3-13. Inside Agent, there are one data component to handle WSDM description and four components to handle different requests. WSDM Description The data component saves the resource files, including registration file, WSDL and generated classes. Those files generated by Managed Resource components come from resource handler.. Web Services Interface The component provides Web interfaces and handles all requests. It reads WSDM description and creates service interfaces for each Managed Resources. When a request comes, it will process it and invoke Management Request Handler to process it.. Resource Handler Resource Handler controls life cycle of Managed Resources from installation, startup, shutdown, and un-installation. During installation, the component gets all WSDM files from Managed Resources. When system startup or shutdown, the components will invoke startup or shutdown procedure of Managed Resources, respectively. In the startup process, if there is configuration in the registry, the configuration will be retrieved and sent to Managed Resource. Finally, during un-installation, the component will remove the configuration from WSDM Description components. 42.

(53) Management Request Handler When it gets requests from Web Services Interfaces, it will process the requests and call the corresponding Managed Resource to handle it.. Event Handler Management Application can register notification so that it will get a notification when an event occurred. The event is associated with properties of resources. In other words, management applications may register “Property is equals 10” event. The Event Handler will handle those event requests, and continues to monitor resources. If the situation happens, it will notify Management Application by WS-Notification specification.. 3.7. MANAGEMENT APPLICATIONS & PROTOCOLS Management applications will access the information of resources and represent the information. They can also configure the resources so that the resources can perform better and are helpful in the enterprise environment. When there are specified events or situation happened, management applications can also get the events and response for it. Many industry products begin to support WSDM to manage Web services or use Web services to manage applications. Those products implements pre-defined service monitor and control functions. They define service metrics and use SLA (Service Level Agreement) to manage services. Besides, those products many only support some specified specifications. For the reason, in general, the management 43.

(54) applications can only communicate with those services used their management library. It violates the original idea of Web services. In our system design, Agent exposes Web services interface for management and uses MUWS as communication standards. Management applications can use the WS-Propriety to get propriety of a resource and use the management functions to control the service. Under such architecture, the management applications do not need to know pre-defined information. Using the standards, management applications can get management information quickly. For the management applications, the following protocols should support: 1.. WS-ResourceProperties - GetResourceProperty operation. 2.. WS-MetadataExchange - GetMetadata operation. 3.. WSN NotificationProducer - Subscribe and GetCurrentMessage operations, as well as WS-Topics properties. 4.. WSDM MUWS: Identity, Caption, Description, and Version properties, OperationalStatus property.. 44.

(55) 4. WEB SERVICES PROCESS MANAGEMENT. The software as a service model can overcome many limitations that constrain traditional software use, deployment and evolution [20]. Web services architecture constructs such service environment and provides a suitable technical foundation for making business processes accessible within an enterprise because of the standard interfaces as well as communication protocols. The architecture focuses on separating the possession and ownership of software from its use. It delivers software’s functionalities as a set of distributed services. Therefore, the business requirements can be fulfilled only when composing those services. Those composing Web services make up business processes that accomplish business requirements. For the reason, managing enterprise systems does not only monitor service status but also guarantee Web services process execution well.. 4.1. MANAGEMENT OF SINGLE SERVICE To perform Web services processes, it is necessary that every service can accomplish requests. Each Web service should accept the request and response correctly. Otherwise, the whole EWSE will be in abnormal status. For the reason, system administrator should monitor service status and take actions when there is something wrong. Using the management framework with ICapability interface can build up management mechanism quickly. By defining suitable management functions, programmers can develop those functions easy without knowing advanced WSDM 45.

(56) specifications. However, enterprise should define fundamental management functions those must be implemented by every service. It does great help for system management. Those functions include are listed in section 2.2. For example, all services should contain an ID to distinguish each service and define metric to evaluate performance as well as service health. Those functions can be defined as interfaces or abstract classes. When derivative classes implement them, Agent of the management framework will generate the related WSDM interfaces. If enterprise can defines general purposes functions, for example database and mail, management functions for those features can be added into enterprise framework and will be reused in many systems. ICapability interfaces and Agent provide an easy way to create consistent management functions to monitor Web services. They also provide a solution to reuse those management functions. Using the framework can build up the environment to control as well as handle services quickly and easily.. 4.2. SERVICE COMPOSITION The importance of service composition has been widely recognized in the distributed research community due to its high flexibility in allowing development of customized applications. Enterprise web services cannot exist along. They most co-operate with other services to accomplish business and technical needs. However, the two kinds of needs have different concerns.. 4.2.1. SERVICES COMPOSITION FOR BUSINESS NEEDS. 46.

(57) Web services are built to support business requirements. There are many concerns about services composition. For example, the selected service for composition should consider multiple criteria (e.g., duration, reliability) [18]. Some researchers define semantic Web services to help service selection [20][21][22]. After studying those researches, Web services composition should satisfy business requirements, including business functionalities and service quality. Although Web services architecture has flexibility to select suitable services, it does not define measure methods or standards. In other words, service clients have to handle and record the quality information by themselves. Enterprise IT systems should improve and adjust by current target and status [23][24]. Nowadays, more and more corporations build not only internal systems (e.g., ERP) but also external systems (e.g., CRM, SCM, and SRM). Those systems can earn more business opportunities or reduce cost. If IT systems can adjust for the change quickly, corporations can make the best response. Web services architecture has proven the adjust solution. The standard interfaces make the communication between heterogeneous systems possible and dynamically service composition. However, it is hard to find out the service bottle without proper tracing mechanism. When a request is issued into the Web services environment, the system should know all services involved in their order. Therefore, the system can know the detail information from management framework of the services and adjust services as they need.. 4.2.2. SERVICES COMPOSITION FOR TECHNICAL NEEDS. Many Web services standards defines inter-operations between services to fulfill technical needs. UDDI, one of three basic Web services standards, is for service 47.