(WS-Manageability)
2 Version 1.0 3 September 10, 2003 4 5 Authors 6Mark Potts, Talking Blocks (mark.potts@talkingblocks.com) 7
Igor Sedukhin, Computer Associates (igor.seduhkin@ca.com) 8
Heather Kreger, IBM (kreger@us.ibm.com) 9
Contributors 10
Ellen Stokes, IBM (stokese@us.ibm.com) 11
12
Copyright 13
Copyright © 2003 by International Business Machines Corporation, Computer Associates 14
International, Inc., Talking Blocks, Inc. All rights reserved. 15
16
The Web Services Manageability - Concepts 1.0, Web Services Manageability - 17
Specification 1.0, and Web Services Manageability - Representation 1.0, 10 September 18
2003 (the “Specification”) was developed by IBM, Computer Associates International, 19
Inc., and Talking Blocks, Inc. (each an "Author"). The Authors hereby contribute the 20
Specification to the OASIS Web Services Distributed Management Technical Committee. 21
In addition to the rights and representations provided for in the OASIS Policy on 22
Intellectual Property Rights, the Authors make the following grants and commitments. 23
24
Permission to copy, display, perform, modify and distribute the Specification, and to 25
authorize others to do the foregoing, in any medium without fee or royalty is hereby 26
granted for the purpose of developing and evaluating the Specification. 27
28
IBM Corporation, Computer Associates International, Inc., and Talking Blocks, Inc. 29
(collectively, the “Authors”) will each grant a royalty-free license to third parties, under 30
reasonable, non-discriminatory terms and conditions to certain of their respective patents 31
that they deem necessary to implement the Specification. 32
33
DISCLAIMERS: 34
35
THE SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO 36
REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, 37
BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A 38
PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE 39
CONTENTS OF THE SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR 40
THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY 41
THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. 42
43
THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, 44
INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF 45
48
You may remove these disclaimers from your modified versions of the Specification 49
provided that you effectively disclaim all warranties and liabilities on behalf of all 50
copyright holders in the copies of any such modified versions you distribute. 51
52
The names and trademarks of the Authors may NOT be used in any manner, including 53
advertising or publicity pertaining to the Specification or its contents without specific, 54
written prior permission. Title to copyright in the Specification will at all times remain with 55
the Authors. 56
57
No other rights are granted by implication, estoppel or otherwise. 58
59
Status of this Document 60
This document is provided as a submission to the OASIS Web Services Distributed 61
Management Technical Committee and to the Web service community in general. 62
63
Abstract 64
As Web services become pervasive and critical to business operations, the task of 65
managing Web services and implementations of the Web services architecture will be 66
imperative to the success of business operations. Web services manageability is defined as 67
a set of capabilities for discovering the existence, availability, health, performance, and 68
usage, as well as the control and configuration of a Web service within the Web services 69
architecture. This implies that Web services can be managed using Web services 70
technologies. The importance of a standardized management model for Web services and 71
the promise of Web services as a management integration technology has driven industry 72
leaders in Web services and management technologies and applications to form a technical 73
committee in OASIS called the Web Services Distributed Management (WSDM) Technical 74
Committee. 75
76
The WSDM TC is chartered to develop the specifications for defining how to use Web 77
services to manage any IT resource – the “WSDM Management Using Web Services” 78
specification. They are also charted to define the manageability model for a Web service as 79
an IT resource and how to access that model using Web services – the “WSDM 80
Management OF Web Services” specification. WS-Manageability defines the later, the 81
manageability model for a Web service and how to access that model using Web services. 82
WS-Manageability does not provide a “Management Using Web Services” specification. 83
But it does provide insight, illustration, and input into how “Management Using Web 84
Services” should be developed to support Web services and Grid services communities 85
through a concrete use case: Managing Web services. 86
87
WS-Manageability 88
WS-Manageability is composed of three documents, a concepts document, a normative 89
specification, and renderings listing. These documents are summarized below: 90
specification. It provides an overview of Web services architecture and implications for 93
management of that architecture. The Concepts document further defines the role of the 94
manager in the Web services architecture and provides practical information on 95
manageability implementation patterns and discovery considerations. 96
97
The WS-Manageability - Specification begins by introducing the general concepts of a 98
manageability model in terms of manageability topics, (identification, configuration, state, 99
metrics, and relationships) and the aspects (properties, operations and events) used to 100
define them. These abstract concepts apply to understanding and describing the 101
manageability information and behavior of any IT resource, not just Web services. We use 102
these concepts to organize our approach to Web services manageability. 103
104
The manageability model for Web services endpoint is defined as concrete models in UML 105
using the topics and aspects concepts, without implying any particular implementation or 106
locus of implementation. Appropriate manageability interfaces are defined based on the 107
UML manageability models. While some parts of this model may be useful for modeling 108
the manageability of any IT resource, this specification is focused exclusively on the 109
requirements of Web service endpoints and does not propose a complete generic resource 110
manageability model. The WSDM “Management Using Web Services” specification may 111
incorporate these more generic models. 112
113
The WS-Manageability – Representation document provides the interface definitions 114
based on the model as WSDL 1.1 and GWSDL renderings. These definitions are meant to 115
show how the topics and aspects concepts along with concrete models can influence the 116
development of consistent Web services interfaces for accessing the manageability 117
information of Web services. The interfaces illustrate how the manageability model for 118
Web services can be divided into aspects of topics that apply to all manageable resources 119
and aspects of topics that apply only to the manageability of Web service endpoints. The 120
interfaces that may apply to all manageable resources may be incorporated into the 121
“WSDM Management Using Web Services” specification. The details of these WSDL 122
interfaces specific to managing a Web service endpoint may change to remain consistent 123
with the “WSDM Management Using Web Services” specification when it is available. 124
125
This specification depends on Web services as a distributed platform. There are several 126
common functions which are required for management using Web services that are not 127
specific to management and not yet available as standardized Web service technologies. 128
Interim solutions have been proposed in this specification which will be replaced by 129
suitable standards when they become available. It is not expected that the WSDM TC will 130
continue specification of or standardization of the interim solutions. 131
132
This specification defines the manageability model for Web services, and then uses Web 133
services as a ‘worked example’ of how manageability interfaces in general, as well as Web 134
services manageability interfaces, may be rendered based on one approach to management 135
using Web services practices. 136
“SHOULD,” “SHOULD NOT,” “RECOMMENDED,” “MAY,” and “OPTIONAL” are to 140
be interpreted as described in RFC-2119 [RFC 2119]. This is not yet done consistently. 141
This specification uses namespace prefixes throughout; they are listed in Table 1. Note that 142
the choice of any namespace prefix is arbitrary at this time and not semantically significant. 143 144 Prefix Namespace soap http://schemas.xmlsoap.org/wsdl/soap/ crm http://www.gridforum.org/namespaces/2003/17/crm wsdl http://www.w3.org/2002/07/wsdl gwsdl http://www.gridform.org/namespaces/2003/gridWSDLExtensions sd http://www.gridforum.org/namespaces/2003/serviceData ogsi http://www.gridforum.org/namespaces/2003/OGSI http http://www.w3.org/2002/06/wsdl/http xsd http://www.w3.org/2001/XMLSchema xsi http://www.w3.org/2001/XMLSchema-instance cbe http://www.ibm.com/AC/commonbaseevent1_1
Table 1: Some standard prefixes and namespaces commonly used in this document. 145
146
Unresolved issues with the submission are interspersed in appropriate locations through 147
this specification, are highlighted in yellow. 148
Table of Contents 150
1. INTRODUCTION... 6 151
2. REQUIREMENTS, DEFINITIONS AND SCOPE... 7 152
2.1. MANAGEABILITY OF WEB SERVICES... 7
153
2.2. SCOPE OF WORK... 7
154
2.3. DEFINITIONS... 8
155
3. BASIC WEB SERVICE ARCHITECTURE... 9 156
3.1. WEB SERVICES ARCHITECTURE... 9
157
3.2. IMPLEMENTATION OF THE WEB SERVICES ARCHITECTURE... 10
158
3.3. ANATOMY OF WEB SERVICES IMPLEMENTATIONS... 13
159
3.4. WEB SERVICE RELATIONSHIPS... 17
160
4. THE ROLE OF MANAGEMENT IN THE WEB SERVICES ARCHITECTURE ... 19
161
4.1. ANATOMY OF WEB SERVICE MANAGEABILITY... 20
162
4.2. WEB SERVICES MANAGEMENT ARCHITECTURE... 21
163 4.3. MANAGEMENT PATTERNS... 22 164 4.3.1. Consolidated Interfaces ... 22 165 4.3.2. Associated Interfaces ... 23 166
4.4. MANAGERS AND MANAGEABILITY INTERFACES... 24
167
4.4.1. Implementing the Manageability Interface... 24
168
4.4.2. Multiple Managers Considerations ... 24
169
5. DESCRIPTION AND DISCOVERY OF MANAGEABILITY ... 27 170
5.1. DESCRIBING THE MANAGEABILITY... 27
171 5.1.1. Consolidated Interfaces ... 27 172 5.1.2. Associated Interfaces ... 28 173 5.2. DISCOVERY OF MANAGEABILITY... 29 174
5.2.1. Discovery of Manageable Web Services... 29
175
From functional Web Service endpoint to its manageability endpoint ... 29 176
From manageability endpoint to the functional Web Service endpoint... 30 177
5.3. DISCOVERY OF MANAGEABILITY CAPABILITIES... 30
178
6. SUMMARY ... 31 179
7. REFERENCES... 32 180
1. Introduction
181182
The emergence of Service-Oriented Architectures (SOA) [1] and industry commitment to 183
Web services and Grid computing [2] requires new management capabilities in order to 184
truly achieve the visions and goals of these initiatives. Because, both Web services and 185
Grid environments, leverage the loosely coupled nature of services, deployed across 186
heterogeneous platforms and ownership domains and can dynamically discover and interact 187
with each other during solution design or execution, the manageability of such 188
environments is more critical and challenging to the business they support. Web services 189
can also cross administrative domains leading to multiple aspects of control requiring a 190
greater emphasis on declarative and real-time management through the use of management 191
policies and service level agreements. 192
193
This submission details a manageability model and architecture that form the basis for the 194
Management of Web Services. It directly addresses the requirements for manageable Web 195
service architecture implementations identified through the work of the W3C Web service 196
architecture group (WSAG) and it’s Management Task Force (MTF). This submission also 197
takes into account and leverages the work completed and underway in other management 198
domains, including the DMTF’s Common Information Model (CIM) and the Global Grid 199
Forum’s Open Grid Services Infrastructure specifications and Common Management 200
Model (CMM) proposals. 201
202
This document is structured as follows: Section 2 introduces the Manageability 203
Requirements defined by the W3C and the Management Task Force, the scope of this work 204
and potential future work. Section 3 gives an overview of the Web service architecture and 205
the role of management within that architecture. Section 4 defines the Management 206
Architecture within which we define manageability of Web services Section 5 introduces 207
the principles of description and discovery of manageable Web services. 208
209
The concepts are used in the “Web Services Manageability – Specification” which defines 210
and details the Web services Manageability Model. The specification provides the 211
representation of the manageability model in WSDL 1.1, and Grid WSDL. It explains how 212
this document’s material pertains to the work completed in this area for the Grid, 213
specifically the Common Management Model (CMM). 214
215
Note: Even though SOAP is used throughout the document for clarity and examples, Management
216
capabilities can be exposed through other protocols including any protocol capable of supporting the XML 217
infoset. 218
219
Note: The techniques used to express the Web services manageability model in schema, WSDL and
220
GWSDL descriptions are techniques chosen based on their availability at the time of this draft. These 221
techniques may need to evolve based on new specifications, best practices and techniques for expressing 222
manageability information in WSDL 1.1, WSDL 1.2, and GWSDL. 223
2. Requirements, Definitions and Scope
2242.1. Manageability of Web services
225
As Web services become pervasive and critical to business operations, the task of 226
managing Web services and implementations of the Web services architecture will be 227
imperative to the success of business operations. Management of Web services in this 228
case is defined as a set of capabilities for discovering the existence, availability, 229
performance health, usage, control and configuration of resources within the Web 230
services architecture. Like other Web Services, manageable Web services architecture 231
implementations need to be secure, including support for authentication, 232
authorization, integrity, and confidentiality. 233
234
The W3C Web Services Architecture Group has identified a set of requirements 235
specific to the management of Web services architecture and Web services. For 236
convenience, the Manageability Goals from the Requirements document [3] are 237 restated here; 238 239 240 2.2. Scope of Work 241
This submission is initially limited in scope to the definition of a sufficient set of 242
management capabilities for the architectural element Web services endpoint (Web
243
service definition, endpoint definition). We do expect that the scope of this 244
D-AC018 The Web Services Architecture must enable the management and provisioning of Web Services.
• AC018.1 Ensure that implementations of the Web Services Architecture are manageable. o AR018.1.1 Define a base set of standard metrics for architectural components
and their interactions accompanied by guidelines for measurement. o AR018.1.2 Define a base set of standard management operations for Web
Services Architecture implementations. Management operations includes, but is not limited to, support for configuration control and lifecycle control.
o AR018.1.3 Define a base set of management events to be issued by the Web Services Architecture implementation.
o AR018.1.4 Define a standard methodology for accessing management capabilities from the Web Services Architecture implementation.
• AC018.2 Ensure that implementations of the Web Service instances are manageable. o AR018.2.1 Define how a web service should expose web service specific
metrics, configuration, operations, and events.
o AR018.2.2 Support the discovery of web service management capabilities. o AR018.2.3 Define a standard methodology for accessing management
capabilities of a Web Service through the Web Services Architecture implementation.
• AC018.3 Ensure that at least the following types of management aspects are supported: Resource Accounting, Usage Auditing and Tracking, Performance Monitoring, Availability, Configuration, Control, Security Auditing and Administration, and Service Level
submission will be expanded to define the manageability of the other elements of the 245
Web service architecture. 246
As a result of these requirements for Manageable Web services the W3C introduced 247
the role of the Manager (see Web Service Architecture and the Management Role) 248
which uses the manageability information and capabilities provided by manageable 249
resources. The definition of the Manager role, beyond the information model offered 250
to it and how it interacts with the existing roles of the Web services architecture, is 251
outside the scope of the W3C Web Services Architecture draft and therefore also 252
outside the scope of this submission. 253
254
The work also has given considerations to the Grid initiatives that also have similar 255
management requirements for Grid services (themselves Web services). Management 256
of Web services is not purely a technical or physical perspective on management but 257
a service perspective and directly ties into the business objectives of the provider and 258
concerns of the consumer. 259
2.3. Definitions
260
These definitions are derived from the W3C definitions surrounding the management 261
architecture. 262
¾ Web service endpoint is an association between a Binding and a network 263
address, specified by a URI that may be used to communicate with an instance 264
of a Service. 265
¾ Manageable implies that a Web service can be managed by a management 266
system. 267
¾ Managed implies that an entity is actively being managed by a management 268
system. 269
¾ Management capabilities include identification, configuration, metrics, 270
status, operations, and events offered by manageable entities for management 271
purposes. 272
¾ Manageability implies the existence of a sufficient set of management 273
capabilities such that an entity is manageable. 274
¾ Management is the utilization of the management capabilities by the 275
management system. 276
¾ Manageability interface is that interface through which manageability 277
capabilities are offered. 278
¾ Management endpoint is the Web services endpoint offering the 279
manageability interface for management purposes. 280
We define one additional term. 281
¾ Manageable resources include the subset of components specific to the Web 282
service architecture (Web services, Web service endpoint Web Service 283
Environment, Clients, Client Environments and Web service Descriptions) 284
and roles defined in a Web service architecture (Discovery Agency, 285
Requestor, Provider, Manager). 286
3. Basic Web Service Architecture
2873.1. Web Services Architecture
288
W3C defines a Web Service as a software system which functions can be accessed 289
via standard internet protocols by exchanging structural data (XML) messages. 290
291
Although architectural concepts, constraints and relationships are defined in the W3C 292
Web Services Architecture, this document outlines some of the basic principles of the 293
architecture in a more concrete manner to facilitate understanding Web services 294
manageability. We have used the WS-I Basic Profile [4] for Web services, to help 295
explain Web services using XML, WSDL, SOAP, and HTTP technologies. The 296
concepts here still apply when other interaction technologies besides SOAP and 297 HTTP are used. 298 Requestor Provider Client Service WSDL SOAP Discovery Interaction 299
Figure 1: Web Services Architecture 300
301
Figure 1, represents an abstract architecture with elements such as roles, activities and 302
artifacts. Roles are named sets of activities. Activities are named sets of procedures 303
(steps, invocations, or interactions). Artifacts are named sets of data (information). 304
Every named element has its associated meaning described in detail below. 305
306
When actually implemented, an element of a software system may take on one or 307
more roles and therefore be responsible for activities associated with both of those 308
roles. 309
310
In most practical cases, a Web service (also referred to as a service in this document) 311
is owned by a provider. A provider is a role that could represent a legal entity e.g. 312
business or a person owning or willing to provide/offer access to certain functionality 313
via software. A provider has to describe its service in a machine processable manner, 314
that is, in a Web Services Description Language (WSDL) document (artifact). A 315
provider is also responsible for establishing and maintaining an endpoint for a 316
service. An endpoint is an addressable location where data messages could be sent to 317
request execution of some function from the service. The location address, transport 318
details, etc. are usually part of the service description, e.g. a WSDL document, but 319
can also be defined as a references that is resolved at run-time. 320
321
A requestor is a role that accesses and uses the functionality of the service offered by 322
the provider. The requestor first discovers the service and understands its 323
requirements and functions by finding and inspecting its WSDL document. A 324
requestor is then able to realize its intent by sending messages (artifacts) carrying 325
structured data (XML) representing the request to the service endpoint. Similar reply 326
messages may then be delivered in response. 327
328
For interoperability, an endpoint must support a SOAP (WS-Interoperability) binding 329
for its WSDL interface. The endpoint may also offer additional bindings. 330
331
The understanding of the provider’s intent to offer certain functionality as a service is 332
encoded in the WSDL document. The requestor’s intent to use that functionality is 333
encoded in the messages sent to the service endpoint. 334
335
The service and the client in Figure 1 are abstract representations of the entity 336
realizing the functionality and of the entity intending to use the functionality. An 337
example of a client could be a Windows application used by a human. An example of 338
a service could be a piece of software returning a stock quote by accessing 339
information in a database. 340
3.2. Implementation of the Web Services Architecture
341
The abstract architecture may not present enough details for those actually planning 342
or designing (architecting) Web services-enabled software applications in any 343
organization. For this reason, this document briefly outlines a deployable 344
implementation of the Web Services Architecture and the resulting Services Network 345 (Figure 3). 346 347 Environment Environment Discovery Mechanism Messaging Find /Publ ish Find/P ublis h Service Contract Service Contract Message Implementation Service/ Client Implementation Service/ Client 348
Figure 2: An Implementation of the Web Services Architecture 349
Note: The depiction above shows the simplest scenario for a Web services architecture but could
351
include and does not preclude support of the concepts of intermediaries and proxies, playing both 352
roles of client and service, between ultimate requester and service provider. 353
354
This implementation (Figure 2) builds on the abstract Web Services Architecture and 355
closely resembles other known enterprise software architectures. 356
357
When a Web service application is conceived, it has an implementation that is 358
deployed to a suitable environment. An implementation is the code that executes, and 359
it is controlled by the environment to which it is deployed. Environments can be 360
viewed as purely software (e.g. a platform such as .NET, J2EE) or hardware (e.g. a 361
server) or both. It is likely that many implementations will be deployed to disparate 362
environments but all interact regardless of the vagrancies of the platforms or 363
implementations. 364
365
The implementation, often in conjunction with the environment, exposes its 366
functionality as one or more services and, in turn, can consume other services as part 367
of the execution of its functions. For example, an order fulfillment service may use a 368
shipping service to obtain a package tracking number. 369
370
Therefore, one implementation could realize abstract service and client roles 371
simultaneously. The service and the client are both abstractions representing exposed 372
and consumed functionality respectively. It is a responsibility of the provider to 373
describe exposed functionality and access details in one or more Service Contracts. 374
Service contract is, in many cases, just a WSDL document, but may additionally 375
contain other machine processable markup such as security requirements and policies, 376
e.g. WS-Policy. 377
378
The provider is also responsible for publishing service contracts (all pertinent 379
information, technical and business, required for usage of the service) via a chosen 380
Discovery Mechanisms. It could use centralized corporate UDDI registry, WSIL files,
381
public search engines, or a peer-to-peer discovery mechanism such as the one found 382
in Open Grid Services Architecture. The presence and use of a discovery mechanism 383
is a key to any sensible implementation of the Web services architecture. 384
385
The ability of implementations to dynamically discover and use functionality as 386
Services is one of the great advantages of Web services. Service contracts that define 387
access to abstract functionality could be established independently of its actual 388
implementation or the runtime environment. Properly designed and built Web 389
services applications are loosely-coupled and can be flexibly changed. This enables 390
the logical parts of applications to be dynamically replaced or re-implemented to 391
accommodate new business requirements and changing circumstances. 392
393
Service implementations that interact form a logical network of services layered over 394
the infrastructure (e.g. software environments, servers, etc.) and the physical 395
connectivity network. This logical network is also commonly called a Services 396
Network (see Figure 3). As a Services Network grows, its existence and performance 397
becomes highly relevant to the main line of business, just like other critical IT 398 resources. 399 400 Server service Server service Server service Server service Server service Server service Server service Server service 401
Figure 3: Web Services Network 402
3.3. Anatomy of Web Services Implementations
404
Within the Web services architecture the focal elements are the service and the client. 405
The abstract idea of a service, once conceived, has to be defined, implemented, 406
deployed, and offered (not strictly in that order) such that it can be utilized by clients. 407
A requestor has to recognize the need for a service, discover it, and implement the 408
client to use the service. 409
410
Figure 4 depicts the organizing principles and relationships between the elements of 411
the Web Services Architecture that provide for the materialization of a service 412
concept into an invokable service. The functional definition of a service or, in other 413
words, an interface of a service is what determines the service type. A particular 414
instance of a service type is described as a Web service endpoint and includes the 415
information required to invoke the service. Definition of a service endpoint includes a 416
service access point that defines the network location at which the service can be 417
invoked. In terms of the WSDL, the logical service type is described in the interface, 418
the service endpoint is an endpoint or port, and the service access point is the address 419
(location). 420
421
422
Figure 4: Abstract anatomy of a Service Definition 423
424
The process for defining, implementing, offering, and potentially publishing a service 425
can be seen in more detail below (Figure 5). The initial business concept of a service 426
materializes in the logical and physical architecture as shown. Some elements are 427
logical in terms of the service being offered, and some are physical in terms of the 428
implementation. These elements may well be the responsibility of different parties. 429
431
Figure 5: Anatomy of a Service Lifecycle 432
433
The same perspective can be used to look at the anatomy of a client. Figure 6 shows 434
how a business need for a service materializes by discovering WSDL, implementing a 435
client (requesting application), and using the client to interact with the service. 436
437
438
Figure 6: Anatomy of a Client Lifecycle 439
The anatomy of the service and client can be viewed even more concretely by looking 441
at the implementation and deployment of both elements. Figure 7 depicts the anatomy 442
of a service within the provider. 443
444
445
Figure 7: Provider perspective on services 446
447
Each service has an implementation (service implementation). It is the code or logic 448
that implements the functionality offered by the service. It is exposed as a Web 449
service through a service endpoint or potentially multiple service endpoints. Each 450
endpoint is essentially a listener for protocol specific messages at the given URL (via 451
a service access point). The URL may provide access to one endpoint or many 452
endpoints. 453
454
The service itself is the logical element that represents the offered functionality, 455
which is implemented by the service implementation. 456
457
The service endpoint is the representation of the access mechanisms to the service. A 458
service endpoint may be supported by several service implementations for scalability, 459
differentiated service, or SLA enforcement. 460
461
A service access point is the logical element that represents the URL at which 462
endpoints receive messages and to which requestors send messages. A URL may be 463
shared by multiple endpoints. In such sharing cases, message dispatch happens based 464
on the content of the messages and their context. For example, the header of the 465
message can identify the exact recipient of the routed message. 466
467
The environment hosts or executes service implementations and provides for service 468
access points. It provides support for a stack of protocols and infrastructure involved 469
in offering a Web service. For example, it may include HTTP over TCP/IP listeners, 470
SOAP processor, XML marshalling/de-marshalling, etc. The Environment can be 471
perceived as a software platform, a hardware server, or an entire data center. 472
474
Figure 8: Requester perspective on Clients 475
476
In Figure 8, the anatomy of a client is portrayed within the requestor role of the Web 477
services architecture. It also shows the requester implementation and its environment. 478
479
A requestor implementation utilizes the formal description of a Web service which it 480
reads from the WSDL document. 481
482
The client represents the capabilities natively to the requester implementation such 483
that the Web service can be invoked. For example, a requester implementation may 484
be a Windows GUI application and the client is the part that encapsulates the 485
particular knowledge about a given service, such as how to marshal parameters into 486
XML representation and how to pack a SOAP message properly to the service. 487
488
The environment hosts and executes requester implementations and acts as the 489
dispatch point. The dispatch point sends messages assembled by the client to one or
490
more providers of the service. It then receives the response from the service. The 491
client further processes it into a form that the requester implementation expects (e.g. a 492
set of Java objects). 493
3.4. Web Service Relationships
495 496
Intrinsic relationships exist between elements of the architecture (e.g. services, their 497
implementations and the environments they are deployed to), and between Web 498
services themselves. The latter represents the business/functional semantics of the 499
services rather than the way services are realized in the architecture. 500
501
Web services interact with each other to offer new composite Web services, and the 502
interactions form the logical networks of services. 503
504
The relationships, important to managing Web services, can be summarized into four 505
distinct categories: 1) relationships between Web service interfaces, 2) relationships 506
between Web service endpoints, 3) relationships between Web service endpoints and 507
other architectural elements specified in the Web services architecture, and 4) 508
relationships between Web service endpoints and other manageable resources outside 509 of the WSA. 510 511 Web Services Architecture (WSA) Web Service Environment Managed Web Service Supporting Infrastructure Web Service Environment Managed Web Service Managed Resources Managed Resources
Relationships between Web service interfaces Resources 1 3 3 4 4 1 2 3
Relationships between Web service endpoints
Relationships between Web service endpoints and other WSA resources Relationships between resources outside of the WSA
4 4 Interface Interface 4 2 512
Figure 9: Web service Relationship Categories 513
514
The relationships defined for a Web service in this document fall into the first two 515
groups – the relationships between Web service interfaces and Web service 516
endpoints. The continued work surrounding the management of the Web services 517
architecture and the underlying infrastructure will no doubt lead to additional 518
relationships currently outside the scope of this document. 519
520 521 522
Web service relationships are declared in two ways - at an interface level or at a 523
service endpoint level. Declaring relationships at the interface level allows for 524
visibility into the relationships even where the actual Web service endpoint is 525
resolved dynamically at runtime. Interface level relationships can be defined 526
declaratively in the WSDL document describing the Web service, or they can be 527
made available by the Web service endpoint itself via manageability interfaces. 528
Service endpoint relationships are only made available by the Web service endpoint 529
via manageability interfaces. 530
531
532 533
4. The Role of Management in the Web Services
534Architecture
535To help represent manageability of the Web Services Architecture, a manager role was 536
introduced (Figure 11) by the W3C Web Services Architecture Working Group. A 537
manager is responsible for management of the manageable resources in the architecture 538
(see definitions). 539
540
541
Figure 11: The Manager Role 542
543
Various resources of the architecture may have different manageability capabilities, 544
and the manager is essentially the “user” of those capabilities (see Figure 12). A 545
manageability capability could be something as simple as enabling/disabling certain 546
function of an element. For example, it could stop acceptance of all requests by a Web 547
service. Manageability capabilities are realized through a manageability information 548
model that represents the manageability of resources and manageability information
549
concerning those resources (state, configuration, relationships etc). The model can be 550
accessed by managers which may retrieve information and exert control. For example, 551
semantics of the manageability of a certain resource can be expressed in a UML model, 552
and access to those specific manageability semantics may be described in WSDL 553
interfaces and XML Schema data types. Managers adhering to both standardized access 554
and semantics may manage those resources in an interoperable manner. 555
557
Figure 12: Web service Manageability Capabilities 558
559
Some elements of the architecture are directly managed. This means that a manager can 560
exercise manageability capabilities offered by that element directly. For example, a 561
manageability interface may be exposed by the element itself. In the Web services 562
architecture, a service endpoint is an element that can be directly managed. 563
564
The manager is also aware of other elements of the architecture that are indirectly 565
managed. Indirect management means the manager can request or subscribe to the 566
information about those elements but doesn’t directly access the element for the 567
information. For example, SOAP messages can be recognized, counted, and related to 568
the managed Web service, yet a manager cannot invoke an operation on a SOAP 569
message. 570
571
There is also information important to manageability beyond that provided directly or 572
indirectly by elements of the architecture. This manageability information is inferred 573
through analysis of the information provided. For example, a SOAP message header 574
can contain a digital certificate of the client’s identity. A manager would have to extract 575
that information and translate into the client’s identification that could be used for 576
management purposes later on (e.g. counting SOAP messages sent to a particular Web 577
service by a particular client). 578
4.1. Anatomy of Web Service Manageability
579
The anatomy of a Web service discussed in section 3.3 can be categorized according 580
to the type of manageability available. Service endpoints (following through to 581
services) are directly manageable by any actual implementation that assumes the 582
manager role (e.g. a management system). The SOAP messages and WSDL 583
documents are indirectly manageable. Manageability of client and service concepts is 584
inferred. 585
586
587
Figure 12: Anatomy of the Web Service Manageability 588
4.2. Web Services Management Architecture
589 590
A Web service is manageable if its manageability capabilities are exposed via 591
standard manageability interfaces. The manageability interfaces must be accessible in 592
a way compliant with the Web Services Architecture. In other words, manageability 593
interfaces are exactly similar to the functional interfaces exposed by a Web service, 594
only that they bear management related semantics and are used by the manager and 595
not by the client. Figure 13 illustrates manageability interfaces exposed by a 596
manageable Web service and accessible by the management system that assumes the 597
role of the manager. A WSDL document exists that describes the manageability 598
interfaces and the endpoints to which messages with management related payloads 599
could be sent. 600
601
Note: An application might assume the role of the client and the role of the manager simultaneously.
602
In this case, the application might exercise business functions of the Web service and manage it at 603
the same time. 604
Requestor Application Service Implementation Client Service WSDL SOAP Discovery Interaction Management System Manager SOAP Interaction WSDL Discovery Functional Interfaces Management Interfaces 606
Figure 13: Manageable Web Services 607 608 609 4.3. Management Patterns 610 611 4.3.1. Consolidated Interfaces 612
In the first management pattern (Figure 14), one WSDL document describes one 613
service with an endpoint whose implementation supports both functional and 614
manageability interfaces. Messages carrying functional requests and management 615
requests can be sent to the same endpoint, and the implementation will do the proper 616
task depending on the content of the message. The endpoint will provide access 617
control and authorization to the operations in the manageability and business 618
interfaces. 619
620
This pattern is applicable when a Web service provider intends to offer business 621
functionality and its manageability within a single description of the service. This is 622
the simplest method for implementation and use of the business functionality and its 623
manageability. It is similar to security policies and enforcement mechanisms being 624
described along with the service they apply to. The drawback of this pattern is the “all 625
or nothing” nature it brings to visibility. Whoever discovers and uses the business 626
functionality also discovers the manageability capabilities associated with the service. 627
It does not mean that manageability capabilities can automatically be used by the 628
same clients that use business functionality; access control policies may only allow 629
certain known clients to use the manageability interface. 630
631
634 635
4.3.2. Associated Interfaces 636
In the second management pattern (Figure 15), the manageability is implemented and 637
offered completely separately from the service itself. For example, it could be a 638
management agent implanted into the hosting environment, or it could be that the 639
environment itself provides manageability capabilities. In this case, two WSDL 640
documents may exist: one that describes the functional Web service endpoint and 641
another one that describes manageability interfaces exposed via an endpoint 642
(manageability endpoint). A referencing mechanism associates the two endpoint 643
descriptions and makes it possible to manage the Web service endpoint. Possible 644
referencing mechanisms are outlined in the Describing and Discovering
645
Manageability section later in this document. 646
647
This pattern is applicable when a Web service provider needs to separate visibility of 648
the service from its manageability. It may be complex to implement, deploy, and use 649
for the managers, but developers of the service implementation and client applications 650
are not impacted directly with the manageability description and publication. It 651
becomes fully the responsibility of the deployment and management activities. If a 652
client needs to be aware of the manageability, such as it may need to query if service 653
is up, then the client needs to be developed such that it is aware of both interfaces. 654
655
656
Figure 15: Associated Interfaces Management Pattern 657
4.4. Managers and Manageability Interfaces
659 660
4.4.1. Implementing the Manageability Interface 661
It is important that the manageability defined in this document be implementable in 662
an easy, flexible, and interoperable manner. Many implementation and deployment 663
techniques must be supported, and manageability must be achievable across many 664
disparate solutions. 665
666
Figure 16 outlines three major methods of making a Web service manageable. First, a 667
Web service implementation itself can offer manageability interfaces. This would be 668
an explicitly manageable Web service implementation. Second, an intermediary can 669
add the manageability interface to a Web service it represents. An intermediary in this 670
case is used as a generic term for a service proxy or a service agent that is capable of 671
interjecting itself between a service and a client. And, finally, an environment can 672
offer manageability interfaces for the Web services it hosts. The latter two methods 673
delegate provision of the manageability of a Web service to that other element (the
674
environment or the intermediary). 675 676 Web service Environment Web service Intermediary Web Service Service Mana ge abil ity In te rfa c e Mana ge abil ity In te rfa c e M a na ge a b ilit y Int e rfac e Service ServiceWeb service Web service Manager Service Identifier Service Identifier Manageability Manageability 677
Figure 16: Delegated Manageability within the Web services Architecture 678
679
4.4.2. Multiple Managers Considerations 680
In large-scale enterprises where manageability capabilities and interfaces are 681
standardized, individual services can be managed by multiple managers. Two 682
common multiple manager scenarios are (1) separation of responsibilities between 683
managers (i.e. one does performance monitoring and another one takes care of 684
deployment changes) and (2) installations with management software from various 685
vendors. The manageability interface and the manageability model must enable 686
operational consistency. The provider of the manageability must ensure consistency 687
of simultaneously executed operations, and managers must ensure there are not 688
executing conflicting operations. 689
690
As outlined earlier (Scope of Work), this document and the related Web Services 691
Manageability Specification do not prescribe precisely how to implement 692
manageability of a Web service or how to implement a manager. Only the agreed 693
information model, access mechanism, and architecture are described for the purposes 694
of the interoperability between manageable Web services and managers. Although 695
manageability information model itself does not preclude multiple managers, actual 696
implementation of the manageability of a Web service or a manager may or may not 697
be capable of properly supporting multiple simultaneous managers. 698
699
Implementers and product architects supporting multiple manager environments 700
should consider the following recommendations: 701
702
¾ Proper access control to the manageability capabilities of a Web service must be 703
in place. The authentication and policy awareness/enforcement mechanisms must 704
be compliant with Web Services Architecture. For example, a requirement for a 705
WS-Security with X.509 certificates acquired from an identity authority could be 706
stated by the security policy included in the description of the manageability 707
interface (e.g. a WS-Policy statement). 708
709
¾ An implementation of the manageability capabilities of a Web service and the 710
implementation of the manager must be aware of common and manager specific 711
information in the manageability model, For example, if a Web service endpoint 712
is not accepting any new requests, its state is ‘DOWN’ for all managers (common 713
data). However, a set of event conditions about transitions or properties which an 714
individual manager is interested in are specific to that manager. 715
716
¾ An implementation of the manageability capabilities of a Web service should 717
provide a mechanism to establish affinity with between the service and the 718
manager. For example, a session/context mechanism such as WS-719
SecureConversation [7] could be used. A Manager may be required to establish a 720
context that expires over time. Alternatively, a context mechanism described in 721
WS-Coordination [6] may be used or any other preferred standard method. 722
723
¾ Managers should be capable of making themselves aware of the changing 724
situation around the manageable Web service. For example, if a particular state
725
transition, configuration property or performance metric is important to a 726
manager, it has to subscribe to events with respect to that information. Since other 727
managers may cause state changes, the manager cannot assume that it will be the 728
origin of all state changes for the manageable Web service. 729
730
¾ To avoid conflicting operation of the manageability of a Web service, managers 731
must coordinate and negotiate usage amongst themselves. Coordination strategies 732
should a) happen among peers – federation based on negotiation, b) happen in a 733
delegated manner – a trusted third party coordinates usage, or c) happen by direct 734
command – a hierarchy of managers. Standards must be used to coordinate and 735
negotiate usage of the manageability. For example, federated coordination may be 736
supported by WS-Agreement [5] and delegated coordination by WS-Coordination 737
[6]. 738
5. Description and Discovery of Manageability
740A manageable Web Service (as described in section 4) has to provide machine processable 741
description of the manageability capabilities and the manageability must be discoverable by 742
the managers. Both the description and discovery must be conformant to the Web Services 743
Architecture. 744
5.1. Describing the Manageability
745
The Web Services Management Architecture requires a Web service to have a 746
description of its manageability capabilities in a WSDL document. The WSDL 1.2 747
definition of the principles of describing services, interfaces and endpoints is 748
available at http://www.w3.org/TR/wsdl12/#intro_ws. Similar information about 749
WSDL 1.1 is available http://www.w3.org/TR/wsdl#_introduction. 750
751
The manageability interfaces in this work are described in WSDL 1.1 (or in a WSDL 752
with Grid extensions, i.e. GWSDL (see WS-Manageability Specification). These 753
interfaces have to be made available for (or associated with) a given functional Web 754
Service endpoint. According to the earlier requirement and to the WSDL itself, the 755
manageability interface must also be offered via a Web Service endpoint. 756
757
The principles of describing the manageability of a Web Service and its endpoints are 758
defined following a set of manageability patterns suggested in section 4.3. 759
760
5.1.1. Consolidated Interfaces 761
WSDL 1.2 draft proposes an interface composition mechanism directly in the 762
language. A WSDL 1.2 fragment that represents consolidation of interfaces may look 763 as follows. 764 765 <definitions name=”AConsolidationOfManageabilityExampleInWSDL12” 766 targetNamespace=”http://www.oasis-open.org/wsdm/example/3” 767 xmlns:tns=”http://www.oasis-open.org/wsdm/example/3” 768 xmlns:wsdm=”urn:wsdm:webservice:endpoint:manageability” … > 769 770 <import namespace=”urn:wsdm:webservice:endpoint:manageability” 771 location=”http://www.oasis-772 open.org/wsdm/ManageableWebServiceEndpoint.wsdl”> 773 [. . .] 774
<interface name=”myBusinessFunction”> … </interface>
775 [. . .] 776 <interface name=”myServiceInterface” 777 extends=”tns:myBusinessFunction wsdm:ManageableEndpoint”/> 778 … 779
<service name=”myService” interface=”tns:myServiceInterface”>
780
<endpoint name=”myEndpoint” binding=”tns:SecureSOAP”>
781 <soap:address>http://mycorp.com/myService</soap:address> 782 </endpoint> 783 </service> 784 </definitions> 785 786
WSDL 1.1 does not have interface composition mechanism as part of the language. 787
Therefore, consolidation of interfaces is only possible by composing (appending) 788
operations of the manageability interface directly into the functional interface. The 789
appended manageability operations must then be bound to endpoints in the same way 790
that other functional operations were bound. The following WSDL 1.1 fragment 791
represents consolidation of interfaces. 792 793 <definitions name=”AConsolidationOfManageabilityExampleInWSDL11” 794 targetNamespace=”http://www.oasis-open.org/wsdm/example/4” 795 xmlns:tns=”http://www.oasis-open.org/wsdm/example/4” 796 xmlns:wsdm=”urn:wsdm:webservice:endpoint:metrics:data” … > 797 798
<import namespace=” urn:wsdm:webservice:endpoint:metrics:data”
799 location=”http://www.oasis-800 open.org/wsdm/ManageableWebServiceEndpointMetricsData.wsdl”> 801 [. . .] 802 <portType name=”myServiceInterface”> … 803
<operation name=”myBusinessOperation”> … </operation>
804
<operation name=”getRequestCounters”> … </operation> …
805
</portType>
806
[. . .]
807
<binding name=”mySecureSOAP” portType=”tns:myServiceInterface”> …
808
<operation name=”myBusinessOperation”> … </operation>
809
<operation name=”getRequestCounters”> … </operation> …
810 </binding> 811 [. . .] 812 <service name=”myService”> 813
<port name=”myEndpoint” binding=”tns:mySecureSOAP”>
814 <soap:address>http://mycorp.com/myService</soap:address> 815 </port> 816 </service> 817 </definitions> 818 819
Note : In the case of consolidated interfaces there is no need to identify at runtime which endpoint
820
manageability applies to. It is the same endpoint that exposes both interfaces. The functional 821
interface and management interface are associated by being defined in the same service 822
description. They can be defined in the same interface by using inheritance from business and 823
manageability interfaces or by implenting the operations directly in the endpoint’s interface. 824
825
5.1.2. Associated Interfaces 826
There could be various mechanisms to associate the interfaces. Following are the 827
mechanisms that are most likely to be used. 828
¾ Associating at “design time” by embedding a reference in the WSDL 829
document. 830
¾ Associating at “runtime” by an interface method that returns a reference. 831
¾ Associating by external “discovery” of manageable elements. 832
833
Associating at runtime and by discovery is outlined in the section 5.2. The method of 834
association at design time using WSDL extensions is outlined in section 1.2 of the 835
Web Services Manageability – Relationships document. 836
5.2. Discovery of Manageability
838
In order for a manager to make use of the manageability of a Web service endpoint, it 839
needs to: 840
¾ Understand that a Web Service endpoint is manageable 841
¾ Understand what manageability capabilities are supported by a Web service 842
endpoint. 843
844
The process of discovery of the manageability is required to be compliant with the 845
Web Services Architecture. 846
847
5.2.1. Discovery of Manageable Web Services 848
Manageable Web Service endpoints can be discovered by managers in the following 849
ways. 850
¾ Use any standard Web Services discovery mechanism (e.g. search engine, 851
UDDI registry, peer discovery such as WS-Inspection, etc.). Then locate 852
manageability endpoint (consolidated or associated). 853
¾ Discover manageability endpoint via management discovery mechanism 854
(proprietary or Web Services Architecture compliant, e.g. a UDDI registry). 855
Then request identification of the Web service endpoint it applies to. 856
¾ Follow relationships of a manageable Web service endpoint to locate other 857
related elements. Some of the related elements may be other Web service 858
endpoints which also have manageability endpoints. 859
860
Basically, either way, after discovering a Web service endpoint or manageability 861
endpoint, the manager has to understand which one is which. Following is the brief 862
outline of how to locate the manageability endpoint having discovered a Web service 863
endpoint and vice versa. 864
From functional Web Service endpoint to its manageability endpoint
865
When a manager discovers a Web service endpoint it must have the WSDL document 866
that describes it. To determine if the given Web service endpoint is manageable, the 867
manager must interrogate the WSDL document first. It must understand whether 868
consolidated interfaces or associated interfaces patterns are used. 869
870
To determine if consolidated interfaces pattern was used, the manager simply finds if 871
the endpoint offers standard manageability operations. It finds those operations by the 872
input/output message definition QName. For example, a sufficient indication that an 873
endpoint offers standard metrics data is an operation which the input message is 874
{urn:wsdm:webservice:endpoint:metrics:data,getRequestCountersIn}. This 875
approach works equally well for WSDL 1.1, GWSDL and 1.2. 876
877
In case of WSDL 1.2 there is a simpler way to determine if an endpoint is 878
manageable in a consolidated manner. The manager could simply look up the 879
“composition” line of an interface which the endpoint offers. The “composition” line 880
is formed by taking wsdl:service element which contains the given endpoint 881
description as wsdl:endpoint element and then recursively looking up wsdl:extends 882
attribute of every interface that the service implements (wsdl:implements on 883
wsdl:service). For example, the manager may be looking for the 884
{urn:wsdm:webservice:endpoint:manageability,ManageableEndpoint} interface 885
QName or by inheritance from known manageability interfaces to determine if the 886
endpoint is manageable. 887
888
To determine if associated interfaces pattern was used, a manager could use the 889
WSDL extensibility mechanism described in section WS-Manageability specification 890
document. A few XML tags from urn:wsrl:webservice:endpoint:relationship 891
namespace appearing in the WSDL document would point the manager to the 892
manageability endpoint. 893
894
The associated manageability endpoint could be established using the discovery 895
mechanism such as UDDI registry. For example, a registry could contain an entry for 896
a service (business service) and then two implementation entries (tModels). One 897
tModel could contain a reference to a WSDL that describes the functional Web 898
service endpoint, and another could contain a reference to a WSDL that describes the 899
associated manageability Web service endpoint. The registry could control the 900
visibility and only allow appropriate parties to see the second tModel pointing to the 901
manageability endpoint description. 902
From manageability endpoint to the functional Web Service endpoint
903
A manager may know about a manageability endpoint. It may have established such 904
an endpoint using a management-oriented discovery or by following relationships of 905
manageable elements, etc. The manager, then, may need to find a description of the 906
Web service endpoint which the manageability is provided for. For example it may 907
need to know what functional operations are available, or it may want to send a 908
synthetic transaction request to the functional endpoint. 909
910
Manageability interface declares access to the identification information of the 911
endpoint it provides manageability for. A manager may use this information to locate 912
the description of the functional Web service endpoint. Access to the identification 913
must always be provided by the manageability endpoint that is used in the associated 914
interfaces pattern. 915
916
Note that in case of consolidated interfaces pattern, manageability endpoint is the 917
same as the functional endpoint and, therefore, may choose not to provide access to 918
the identification information. Determining this is trivial for the manager, though. A 919
manager must assume that if a manageable endpoint does not provide access to the 920
identification information, it is a case of the consolidated interfaces pattern. A 921
manager must then use a standard Web services discovery approach to determine the 922
functional capabilities of the endpoint if that becomes necessary. 923
924
5.3. Discovery of Manageability Capabilities
925
A manager may need to know what capabilities a given manageability endpoint 926
offers. There are two ways to determine that: (1) by interrogating the endpoint 927
discovered only from the description, and certain others can only be determined by 929
asking (sending request at runtime). 930
931
For example, to determine if a manageability endpoint offers request counters data, a 932
manager would simply lookup the description document if there is an operation with 933
the input message 934
{urn:wsdm:webservice:endpoint:metrics:data,getRequestCountersIn} QName. 935
This way most other principal capabilities described in the composable, standard 936
manageability interfaces can be determined. 937
938
An example of when a manager has to ask the manageability endpoint could be when 939
determining the availability of a particular metric. In this case, a manager must send a 940
request to retrieve the list of available metric QNames. It then has to check the 941
returned list if a metric it is interested in is actually provided by the given 942 manageability endpoint. 943 944
6. Summary
945This document has outlined the fundamental concepts of Web services architectures, how 946
the architecture is realized, and how the realization influences the manageability of Web 947
services. Patterns for supporting manageability interfaces and discovery are outlined here 948
to provide guidance during the development of manageability specifications. The WS-949
Manageability – Specification builds on these concepts to define the manageability model 950
for Web services in an implementation agnostic manner. The WS-Manageability – 951
Representations document renders the manageability model into interfaces expressed in 952
WSDL 1.1 and GWSDL. 953
954 955
7. References
956957
[1] SOA – Service Oriented Architecture:
http://www.w3.org/TR/2003/WD-958
ws-arch-20030808/#service_oriented_architecture 959
[2] Grid: http://www.globus.org/research/papers.html#Overview%20Papers - 960
[3] Web Services Architecture: http://www.w3.org/TR/wsa-reqs
961
[4] WS-I Basic Profile:
http://www.ws-i.org/Profiles/Basic/2003-962 08/BasicProfile-1.0a.htm : 963 [5] WS-Agreement: 964 http://www.globus.org/research/papers/OGSI_Agreement_2003_06_12.pdf 965 [6] WS-Coordination: http://www-106.ibm.com/developerworks/library/ws-966 coor/ : 967 [7] WS-SecureConversation: http://www-968 106.ibm.com/developerworks/library/ws-secon/ 969
