OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [UPlat] Spec updates






Andreas,
Please replace section 2.1.5 with:

1.1.1 Addressing
1.1.1.1     What?

An address or reference is the data structure to refer to a unique Web
service with sufficient information to be able to locate and invoke it
given that the supported messages are already understood. The reference
must include the ability to locate the description of the service. In this
context address and reference are used synonymously.

1.1.1.2     Why?

It is necessary for management because we need to be able to refer to
manageability services and manageable services in relationships, events,
and operation signature in an interoperable manner.

1.1.1.3     How?

WS-Addressing


WSDL Service Element – per WSDL WG, William to write up


WSDL  1.0 URL - Hommayun





Please replace 2.1.14 with


1.1.1 Name Resolution

1.1.1.1     What?
Name resolution service - A service which accepts an identifier (URI) and
returns an address/reference.
?? Is it also necessary to accept a reference and return the identifier for
it? ??



1.1.1.2     Why?
It is necessary for management because resources and manageability services
have identifiers (from existing instrumentation and technologies) and it
will be necessary  to be able to get a reference for that resource
identifier so that the manager can interact with a resource through its

manageability interface.

Heather Kreger
STSM, Web Services Lead Architect for SWG Emerging Technologies
Author of "Java and JMX: Building Manageable Systems"
kreger@us.ibm.com
919-543-3211 (t/l 441)  cell:919-496-9572



"Andreas Dharmawan" <andreas@westbridgetech.com> on 11/03/2003 07:06:51 PM

To:    <homayoun@hp.com>
cc:    <wsdm@lists.oasis-open.org>
Subject:    RE: [wsdm][UPlat] Meeting Agenda




Homayoun:

I sent  you wsdm-uplat.doc this afternoon. I transferred the aggregated
list
of  definitions into the template.

Here I  attached it again. It may be easier to read on the .doc than email
text.
-----Original Message-----
From: M. Homayoun  Pourheidari [mailto:homayoun@hp.com]
Sent: Monday, November 03,  2003 4:00 PM
To: Andreas Dharmawan
Cc:  wsdm@lists.oasis-open.org
Subject: Re: [wsdm][UPlat] Meeting Agenda


Folks,

Here are the logistics for the uplat 'extra  edition' meeting tomorrow.

Topics:

   Uplat Document Template (Homayoun)
   Notifications (Igor)
   Addressing and Name Resolution (Heather)
   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 boh
    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 expsed 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 e 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.5012homayoun@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
.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]