[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsdm][UPlat] namespaces and versioning
Apologies, to Scott. My original e-mail is a reply to BrianC :). Jet-leg...
I have something for you, Scott, as well :). You said [I do not believe the bad practice of namespace birthdays or evolution schemes should be promoted by a standard.]
Well, XML standards e.g. XML Schema, WSDL, BPEL, etc, all follow exactly that "versioning" approach by defining a namespace e.g. http://www.w3.org/2000/10/XMLSchema. So, why is it bad to promote? Is there a better approach?
-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
-----Original Message-----
From: Scott Hinkelman [mailto:srh@us.ibm.com]
Sent: Thursday, November 06, 2003 11:05 AM
To: Sedukhin, Igor S
Cc: Brian Carroll; homayoun@hp.com; wsdm@lists.oasis-open.org
Subject: RE: [wsdm][UPlat] namespaces and versioning
Igor,
Where did I say that?
Scott
------------
Scott R. Hinkelman, Senior Software Engineer IBM Software Group Emerging Technology Strategy - Industry Initiatives
Office: 512.823.8097 (TL 793.8097)
Cell: 512.415.8490
|---------+---------------------------->
| | "Sedukhin, Igor |
| | S" |
| | <Igor.Sedukhin@ca|
| | .com> |
| | |
| | 11/06/2003 09:10 |
| | AM |
|---------+---------------------------->
>----------------------------------------------------------------------------------------------------------------|
| |
| To: Scott Hinkelman/Austin/IBM@IBMUS, "Brian Carroll" <Brian.Carroll@merant.com> |
| cc: <homayoun@hp.com>, <wsdm@lists.oasis-open.org> |
| Subject: RE: [wsdm][UPlat] namespaces and versioning |
>----------------------------------------------------------------------------------------------------------------|
Scott,
You said
[My concern about the use of targetNamespace is because that scheme is used to provide a version number for an XML document.]
This is NOT so. We should not be mixing xmlns="aaa" and targetNamespace="aaa". The former is the one you're referring to, the later is NOT. targetNamespace is used to denote where do the elements declared in that document belong to.
For example, targetNamespace of a XML Schema or WSDL document is marking the elements (or concepts) that are being defined, not the document itself.
<schema xmlns="XML Schema" targetNamespace="My Data Types" ...
This is what is expressed in the specs.
[But many of the aspect we will want to version, such as port type, message, etc. can be expressed in 1 or more XML documents, such that there is not an obvious 1-1 mapping between a targetNamespace and each of these aspects of a web service.]
The documents in which declarations are expressed have nothing to do with the actual targetNamespace. One could safely express multiple concepts (e.g. interfaces and services, etc.) with the same targetNamespace and import them as necessary. The namespace of those documents will always be the same -- the standard WSDL namespace.
-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
-----Original Message-----
From: Scott Hinkelman [mailto:srh@us.ibm.com]
Sent: Thursday, November 06, 2003 8:52 AM
To: Brian Carroll
Cc: 'homayoun@hp.com'; wsdm@lists.oasis-open.org
Subject: RE: [wsdm][UPlat] Meeting Agenda
Hi Brian,
>..........[While I have reservations about the use of the namespace for
versioning (on the grounds that namespaces are intended to represent the notion of ownership, not versioning),........
I agree, as I think you are aware. I do not believe the bad practice of namespace birthdays or evolution schemes should be promoted by a standard.
Scott
------------
Scott R. Hinkelman, Senior Software Engineer IBM Software Group Emerging Technology Strategy - Industry Initiatives
Office: 512.823.8097 (TL 793.8097)
Cell: 512.415.8490
|---------+---------------------------->
| | Brian Carroll |
| | <Brian.Carroll@me|
| | rant.com> |
| | |
| | 11/05/2003 11:54 |
| | PM |
|---------+---------------------------->
>----------------------------------------------------------------------------------------------------------------|
|
|
| To: "'homayoun@hp.com'" <homayoun@hp.com>,
wsdm@lists.oasis-open.org |
| cc:
|
| Subject: RE: [wsdm][UPlat] Meeting Agenda
|
>----------------------------------------------------------------------------------------------------------------|
Homayoun,
I regret I will be unable to attend the meeting tomorrow, but wanted to send you a few comments on versioning in section 2.1.2.
1. I concur with Andrea's comments suggesting a 3 level xxx.yyy.zzz version number. That is a fairly common scheme and probably appropriate for a publicly consumable release. For tracking the version tree of source code, we actually use an n-level (no fixed maximum number of levels), and allow strrings rather than sequence numbers for any but the last (rightmost) branch names. That is probably overkill, however, for web services releases.
1.a On a somewhat pedantic note, the revision numbers do not form a linear "sequence", but rather a tree (or in some cases, a graph). That is a maintenance release of an older version of a service (say, 1.6.1) might be release after the 2.0 version is released.
2. I am concerned with the comment on line 135 about using the targetNamespace. [While I have reservations about the use of the namespace for versioning (on the grounds that namespaces are intended to represent the notion of ownership, not versioning), I will concede that that is the mechanism commonly used, and accept the fact that defining a replacement scheme is out of scope for WSDM.] My concern about the use of targetNamespace is because that scheme is used to provide a version number for an XML document. But many of the aspect we will want to version, such as port type, message, etc. can be expressed in 1 or more XML documents, such that there is not an obvious 1-1 mapping between a targetNamespace and each of these aspects of a web service.
Regards,
Brian
-----Original Message-----
From: M. Homayoun Pourheidari [mailto:homayoun@hp.com]
Sent: Wednesday, November 05, 2003 6:00 PM
Cc: wsdm@lists.oasis-open.org
Subject: Re: [wsdm][UPlat] Meeting Agenda
Folks,
Here is the agenda for our next uplat call tomorrow.
Topics:
1. Addressing and Name Resolution Discussion (Heather)
2. Versioning - Andreas and Andrea
3. Attributes - William and Heather
The latest rev. of the uplat document is attached.
Cheers,
H.
--
M. Homayoun Pourheidari wrote:
Folks,
Here are the logistics for the uplat 'extra edition' meeting
tomorrow.
Topics:
1. Uplat Document Template (Homayoun)
2. Notifications (Igor)
3. Addressing and Name Resolution (Heather)
4. Transactions (Andrea)
Time:
11:00 am EST / 8:00 am PST
Call In Info:
Toll Free: 866-639-4730
Toll: 574-948-0377
Code: 4475012
A proposed document template is attached.
Regards,
H.
---
Andreas Dharmawan wrote:
Here is an updated list based on what we have discussed
till 11/3/03.
I am working with Homayoun will get this into the OASIS
template doc.
In the mean time, you may use this to prepare for
tomorrow's meeting.
Change since last time:
- Added Transaction to Medium priority section above cut
line
- Modified Versioning based on input from Bryan and Igor
- Added definitions and description to Security from John
DeCarlo
- Added Notification from Igor
-----
High:
-----
* Identification:
- Definition(s):
Identification is a way to represent that one element
is same or
different than the other without necessarily looking
at the
contents or definition of the element. Applied to Web
resources
in general, as defined by W3C, a Uniform Resource
Identifier
(URI) can be used to represent the identity of a Web
resource.
Applied to Web services, every element which Web
service
description is composed of (service, interface,
endpoint,
location, etc.), is required to be identifiable by a
URI.
Such URI must be unique by definition. Identity is
not required
to be an addressable location, so a dereferencing
mechanism
may be required to actually locate the corresponding
resource.
- Management Need(s):
Manageable resources need to be uniquely identified
for
the manager to tell one from the other and also to
consistently refer to. Therefore a standard
representation of
a unique identity is required.
* Versioning:
- Definition(s):
Versions: A sequence of copies of (Functional and
Manageability)
Webservices incorporating new modifications. Each
version is
identified by the version information, following a
certain
specified format signifying the major version number
and the
release number, embedded in the targetNamespace of
the resource
(no need to invent another mechanism in WS).
Typically an increment in the major version signifies
a
substantial increase in the function of the
Webservice or a
partial or total re-implementation.
Whereas the release number increases each time the
Webservice
is changed in any way and re-released.
Versioning information must also contain change
description
that describes what has changed in a revision
compared to
the previous one.
All (functional and manageability) resouces can be
versioned
to enable maximum flexibility and to anticipate
future uses.
The versionable resources are: interfaces, endpoints,
and
services. So a service may contains functional and
manageability endpoints and interfaces. The versions
of
functional and manageability endpoints and interfaces
may
be different due to partial upgrades.
- Management Need(s):
1. Version numbers are useful so that the manager can
know
if the manageable Webservice interfaces have
changed
(bugs have been fixed or new functions added)
since she
obtained her copy. She could also learn whether a
bug
report relates to the current version.
2. A manager of manageable resources must have the
ability to
query the available endpoints' revisions along
with the
corresponding change descriptions such that the
manager
can discern the most appropriate and compatible
interface of
a particular manageability function that her
management
client can use.
* Attributes:
- Definition(s):
Schema to describe attributes of a Web service and
portType
operations to access and set the attributes.
Attributes should be
introspect-able at design time and runtime. Attribute
is
synonymous with property. For manageability, a
property is a name,
type, value triple that is part of the advertised
manageability
interface for a resource. An attribute can be used to
represent
configuration values, metrics, identifiers, etc.
* Metadata:
- Definition(s):
Attribute Metadata - schema that defines how to
describe metadata
about attributes, operations, events, or interfaces
of a Web
service. This metadata for attributes could include
includes units,
volatility, modifiability. Metadata about operations
may include
idempotency, endState. Metadata should be
introspect-able at design
time and runtime.
Note that metadata applies to more than just
attributes.
Operations and events. And interfaces.
Do we need a definition of metadata? Should it
include policies?
WSDL documents? Is it settable? "Data about data".
"Definition of
data that provides information about what is being
managed."
Don't want to include metadata that is "related" to
the data,
just the metadata that is "about" the data. Or
Definitional.
From Dictionary.com:
<data> /me't*-day`t*/, or combinations of /may'-/ or
(Commonwealth) /mee'-/; /-dah`t*/ (Or "meta data")
Data about
data. In data processing, meta-data is definitional
data
that provides information about or documentation of
other data
managed within an application or environment.
For example, meta-data would document data about data
elements or attributes, (name, size, data type, etc)
and
data about records or data structures (length,
fields,
columns, etc) and data about data (where it is
located, how it
is associated, ownership, etc.). Meta-data may
include
descriptive information about the context, quality
and
condition, or characteristics of the data.
* Addressing:
- Definition(s):
Addressing is the ability to reference an identified
entity
so that it can be accessed. In the case of a web
service,
"being accessed" means getting hold of its WSDL
description
and any extra information that might be needed to
route
messages to the service.
Addressing is the ability to reference another
entity. One
examples of where a reference is required is in a
relationship
to refer to the entities that have an association
with each other.
Another example is to refer to the Web service where
asynchronous
notifications should be sent. In general, the Web
service
exposing the manageability interfaces for a resource
may need
a reference to the resource. Since not all resources
are Web
services, a reference must be defined such that
non-Web service
entities can also be referred to. The special case of
referring
to a Web service entity should refer to the WSDL for
the Web
service such that a manager can choose which Web
service endpoint
it wants to send messages.
- Management Need(s):
Addressing is required to provide references to other
entities.
Other entities may include resources, Web services,
WSDL documents,
policy descriptions, as well as other documents and
services.
Addressing defines the mechanism used to specify the
reference.
Management using Web services requires a standard
mechanism for \
referring to other entities.
* Notification:
- Definition(s):
Notification is a method of conveying information
from a source to
recipients that expressed interest in that
information. In terms
of Web services it means delivering an XML message
from the source
to addressable recipients. An interest in receiving
those messages
must be established by the recipients, or by third
parties on behalf
of the recipients. When registering interest,
address(es) of
recipient(s) must be provided (see Addressing).
- Management Need(s):
Manageable resources need to convey information to
the managers.
In certain cases, it is unreasonable for the manager
to explicitly
poll (request) the information, and it has to be sent
to the
manager by the resource. For example, a manager may
be interested
when a service receives a new message. The resource
representing
the service has to notify the manager when it happens
(event).
The resource needs to know which managers are
interested in which
information and what are the deliverable addresses of
the managers
to send the notification message when an event
occurs.
When considering requirements on the platform with
regards to
means of notification, it is important to separate
capability of
simple message exchange for the purposes of
notification from the
complex event processing (CEP). The former may be
achievable with
a little effort and the later is a discipline of its
own and
usually requires a lot of supporting infrastructure
that has
nothing to do with means of notification, per se. To
be concrete
simple notification is required to efficiently
provide
manageability of resources. CEP can be built on top
of simple
notification and may be considered out of scope for
now.
To make simple notification possible the folowing has
to happen
1. recipient has to know how to register
interest with the
source of information
2. source has to know how to deliver
information to recipient
3. recipient needs to know that is it being
notified ans also
by which source
Assuming that both the source and recipient are
implemented and
run on Web services platforms with Web services
tools. Assume
that both source and recipient want to implement
notification
using Web services. Web services tools/platforms are
designed
to facilitate easy creation and deployment of a
client and a
service type of applications, in which case,
traditionally, a
client is an initiator and a service is the responder
in the
interactions. To make it possible, service provides a
description how it expects the interaction to happen
and client
understands it. The interesting difference is that
both
recipient and the source have to be initiators and
responders
to be able to implement the three requirements
outlined above.
Therefore both recipient and source need to provide
descriptions how the interactions need to happen.
Each side
can only provide descriptions of interactions it will
respond
to. The source can provide description of how a
recipient
needs to register its interest in available
information, and
the recipient can provide description how a sourc can
deliver
information to it. Definitely, both sides need to
have an
apriori agreement on (and knowledge of) both of the
descriptions to allow the bidirectional interaction
to happen.
The claim is that if the above three requirements are
satisfied
by a standard, that is both recipients' and sources'
side
descriptions are standardized, it is possible to use
existing
Web services tools and platforms to implement
recipient and
source as Web services. In that case each Web service
is
actually a client and a service to the other one, but
both
are aware of ecah other's abilities as a recipient or
the
source.
Such standard would have to define source's side
description
with
- how to register an interest in
an identifiable
information (e.g. name, QName, URI, etc.)
- how to convey address of a
deliverable recipient
(e.g. WS-Addressing, URL, etc.)
- how to verify registration of
the interest
- how to cancel registration of
the interest
- how a source can notify of the
unilateral
cancellation of the interest recipient's
side
description with
- how to deliver infromation and
identify that
it is a notification
- how to tell what source it
came from and possibly
what is the context at the source "
* Relationship:
- Definition(s):
schema to describe relationships between resource
types,
resources, interfaces, and endpoints; including
portType
operations to get and modify the current set of
relationships
from a participant in the relationship. Static
relationships and
relationships between types and interfaces should be
introspect-able at design time and runtime. All
relationships
should be introspect-able at runtime.
- Management Need(s):
- design vs. runtime.
- "Static relationships should be introspect-able at
design time."
----------------------
Medium above cut line:
----------------------
* Security:
- Definition(s):
Information/Computer Security. There are many ways to
categorize
information security, but the most common today is
represented
by the letters C, I, A: Confidentiality, Integrity,
and
Authentication. Additional concepts that can be
arguably kept
separate are: Access Control, Nonrepudiation,
Availability,
and Privacy.
Confidentiality: Preventing unauthorized entities
from accessing
information or resources.
Integrity: Making sure that when authorized entities
access
information, it is either not changed or any changes
are
detectable.
Authentication: Making sure that entities are
who/what they
claim to be.
Access Control: Making sure that entities can only
access
services, resources, or information that they are
authorized
for.
Nonrepudiation: Making sure the sender of a message
can not deny
having sent the message.
Availability: Making sure a service or resource can
be accessed
by authorized users. While this goes beyond
security, security
is expected to address denial of service attacks.
Privacy: Making sure that information on entities is
used only
for the express purposes allowed.
Primarily the issue with Security is that while the
requirement
for Security within manageability is extremely
important, it is
not unique to manageability. All the same issues
arise with
any other Web Services endpoint. Every manageability
endpoint
and many business endpoints will have requirements
for
confidentiality, integrity, and authentication, as
well as
access control, availability, and privacy (see the
definition
of Security).
Also, there is the issue of location. Security may be
implemented in various ways. For example, there
could be a
security filter/proxy in front of every Web Services
endpoint
(including the manageability endpoint) that only
allows
messages through that are valid, authenticated,
authorized,
and have no integrity problems identified. Or all of
those
functions could be performed by the endpoint itself.
Thus, the main concern for Security is that the
specification
allow for external Security infrastructure mechanisms
that are
composable on top of the manageability exposed via
Web Services.
This will require examining other standards like
WS-Security
to ensure nothing done in the specification precludes
the
composability of Security.
Another external effort is to work with standards
groups
developing interoperable Security infrastructure
mechanisms.
It is desirable that these mechanisms provide
manageability
exposed via Web Services.
- Management Need(s):
Resources have to be manageable in a secure way (see
definition
of security). Security is composable on top of the
manageability
exposed via Web services, similar to securing any
other
capability of a resource exposed via a Web service.
For example,
access to a manageability operation can be granted to
only
clients that present "manager's identity" in a
request message.
Security must be manageable, preferably via Web
services.
For example, identity or access assertion can be
verified by
issuing a request to a security Web service.
* Registration/Discovery:
- Definition(s):
Registration is a method of advertising an existence
of an element
so that it can be discovered. Discovery is a method
of locating an
existing element so that it can be used or operated.
Discovery
can be based on a selection criteria or simply a name
or identity
of an element. Location is a method of obtaining an
address of an
element.
For example, location may mean translating an
identity of an
element into an address of an existing useable
element. In the
Web services sense, registration, discovery and
location can be
represented by a set of operations and schema which
may be
implemented by a Registry. A Web service can register
itself or
can be registered by a third party by sending a
request to the
Registry. A Web service can be discovered by sending
a request
to the Registry. The Registry can return the
description of a
Web service with location address included in a
description or
it may return the location address directly.
- Management Need(s):
1. Manageable resources have to be discoverable by
the managers.
2. Manageable resources exposed via Web services can
be registered,
discovered and located via a Registry.
* Policy:
- Definition(s):
1. is a course of action, guiding principle, or
procedure
considered expedient, prudent, or advantageous for
a given
condition or event.
2. describes a broad range of service requirements,
preferences,
and capabilities.
3. provides a set of requirements to a manageable
resources
in a specific context.
There are various policies that can be specified to a
manageable
resources (Webservice functional and manageability
endpoints) via
MUWS such as: authentication, access control,
privacy, non-
repudiation, service level agreement, quality of
service,
routing, content inspection, auditing, etc. policies.
- Management Need(s):
MUWS must leverage as much as existing Webservices
specifications and technologies in applying policies
to the
manageable resources. MUWS should endorse a list of
such
specifications and technologies, and should specify
the
compatibility and interoperability requirements (i.e.
must meet
WS-I).
* Transaction:
- Definition(s):
A "unit of work" that consists of multiple actions
against a
single resource, the same action applied to multiple
resources,
or multiple actions against multiple resources. The
"unit of
work" should be executed once and only once, even if
due to
transmission failures or other errors, the request
may be
received multiple times.
- Management Need(s):
Grouping actions against resources and assuring their
execution/
failure is very valuable. Activities such as IETF's
NetConf
discuss "transactions". The goal is for MUWS to be a
superset
of the functionality in NetConf - avoiding the need
for multiple
protocols/solutions in implementations.
Manager may request to perform multiple operations on
the
manageable resource and integrity of combined request
may need
to be preserved. Also that transactions are part of
regular WSs
and implementations of manageability merely makes use
of those
existing capabilities of WSs.
----
Low:
----
* Collection:
- Definition(s):
A collection is an entity which acts as a proxy to
zero or more
other entities. A manager can send a single request
to a
collection where the result is that zero or more
members of the
collection are acted upon as specified in the
request. The
members of a collection are managed entities in their
own right
and have their own management interfaces. The result
of a
manager sending a single request to a collection must
be the
same as a manager sending a separate message to each
of the
selected members of the collection individually. It
is not
necessary that the collection actually send separate
messages
to each of its members, only that the result to the
members
is the same. A collection provides a mechanism to
perform the
same action on many managed entities at once, and
acts
as one scalability mechanism in a management system.
- Management Need(s):
As the number of managed resources grows, it becomes
more
important for a management system to provide a
mechanism to
allow a manager to perform the same action on many
resources
at once. For instance, with a collection a manager
can query
for the state of all resources in the collection at
once
rather than one at a time. Also, it is possible for a
collection to reset the state of metrics for the
resources
in the collection using a single request. A
collection
provides the ability for a management system to scale
much
better than a system not supporting collections.
Also, there
are cases where the exact membership of a group is
better
known by an entity, such as a collection, that may be
closer
to the group than a manager. This allows the manager
to defer
to the collection to determine the exact entities to
act upon.
* (Work)Flow:
- Definition(s):
the capability to describe a sequence of web services
interactions, where each interaction is fully or
partially
determined by the sequence description and the result
of
previous interactions in that sequence.
* Negotiation:
- Definition(s):
Negotiation is the act or process of arranging for or
bringing
about through conference, discussion, and compromise.
For Web
services, negotiation refers to the process of coming
to agreement
on the advertised aspects of a service (e.g., quality
of service).
- Management Need(s):
Negotiation of QoS for a manageability interface
seems far off
in the distance from the current work of this group.
* Relationship Service:
- Definition(s):
A relationship repository or registry which may be
responsible
for creating, inventorying, tracking, and validating
relationships. This service is not a participant in
the
relationships. If relationships are rule based, then
it would
also be responsible for altering relationship members
based on
the rules. This would include portType operations for
querying,
adding, finding, and validating relationships. This
service
would build on the Relationships schema above.
* Logging:
- Definition(s):
Logging is the action in which message producers
generate log
artifacts, i.e., atomic expressions of diagnostic
information,
that may or may not be used at a later time by other,
independent, message consumers. Secure logging is
required for
audit trails needed to fulfill judiciary and
organizational
policy requirements, to reconcile security related
inconsistencies, and to provide for forensic evidence
both
after the fact and real-time.
* Policy Decision Point:
- Definition(s):
A program with a repository that stores and
calculates various
(overlapping) policies that can be applied to various
(associated) manageable resources.
* Policy Enforcement Point:
- Definition(s):
A program that enforces various set of policies on
(associated)
various manageable resources.
----
TBD:
----
* Lifecycle:
- Definition(s):
Lifecycle is a set of states that a resource can be
in and the
valid transitions between those states. A resource
goes
through a set of states and transitions throughout
its life.
Lifecycle provides the capability to manage the
actual
operational state of a resource, operations to
influence a change
in the state of a resources, and events indicating
when a
state change has occurred. An application or
management tool
uses the lifecycle information for a resource to
better manage
that resource.
For example, valid operations or valid property
values of a
resource may be determined through introspection of a
resource's
state to aid the application or management tool in
doing
those actions only in the state in which those
actions are valid.
This is important in autonomic systems where actions
taken do not
expect exceptions to be thrown.
* Name Resolution:
TBD
To unsubscribe from this mailing list (and be removed
from the roster of the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgroup.php
.
--
M. Homayoun Pourheidari
Web Services Management Operation
HP OpenView Division
408.447.5012
homayoun@hp.com
To unsubscribe from this mailing list (and be removed from the
roster of the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgroup.php
.
--
M. Homayoun Pourheidari
Web Services Management Operation
HP OpenView Division
408.447.5012
homayoun@hp.com
Notice: This email transmission and/or the attachments accompanying it may contain confidential information belonging to Merant. The information is only for the use of the intended recipient. If you have received this transmission in error, please notify the sender immediately by reply email, and then destroy all copies of the transmission.
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgroup.php
.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]