[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]