[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WSDM Call time change till 11EST and Face to Face Minutes
Hi folks, sorry for the late distribution of these minutes (and thanks to John for all his volunteerism and diligence!). These are the 'raw' minutes with the discussions categorized into the agenda items. We'll approve them next week and then we'll post them. Please review for any misquotes. (See attached file: OASIS WSDM Face to Face.rawminutes.051303.htm) Here is my agenda presentation with the summary charts at the end for timelines, laisons, action items, etc. : (See attached file: Agenda.ppt) I want to thank everyone for the spirited sense of cooperation, it was a great first meeting of a lot of great minds. As a reminder! We moved our meeting to 8am PST/11am EST this week! Callin numbers: 719-457-0701, 888-808-7889, meeting id 100346 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-9572Title: 2003-05-14 OASIS WSDM Face to Face
2003-05-14 OASIS WSDM Face to Face This document contains notes from the WSDM Face to Face meeting in San Jose, CA, hosted by Novell. The official agenda is first, followed by a short summary, then the detailed notes. Agenda 1. Welcome and Introduction Winston WSDM TC Goals and Deliverables Status of current discussions Requirements documents format and organization 2. Management OF Web Services Requirements Review of Existing work: W3C MTF work - Heather 3.
Brainstorming, categorization, prioritization of requirements Identify
one or two use cases
Information modeling
techniques 4.
Management USING Web Services Requirements
Review of Existing Work GGF and CMM Ellen Stokes DMTF, Interop WG Andrea Westernian Application WG Karl Schopmeyer 5.
Brainstorming, categorization, prioritization of requirements
Identify one or two use cases 6. Work on
requirements and use cases in subteams. Any
issues that arose during the previous discussions 7. Wrap up
and planning
Liaisons
Conformance, Interoperability,
and Reference Implementations
Timelines for WSDM Work Milestones
for WSDM Review
and assignment of action items Planning
for next Face to Face Summary 1. Welcome and Introduction. The introductions and status discussion went quickly. 2. Management OF Web Services Review. There was still a lot of discussion based on the review of current work. Topics included the relevance of past work to current work, many discussions of the meaning of various terms, and other level-setting discussions. 3. Brainstorming, categorization, prioritization of requirements. The Brainstorming session for Management USING Web Services was well run. Everyone was given a chance to state a set of requirements to be added to the list. While there was discussion of use cases driving the requirements, no specific use cases were identified. At this time, there was no discussion of information modeling techniques. 4. Management USING Web Services Requirements Review. A lot of useful information was presented on activities in the Global Grid Forum (GGF), Distributed Management Task Force (DMTF) and The Open Group (TOG). There were also lively discussions of the applicability to the WSDM work, among other topics. 5. Brainstorming, categorization, prioritization of requirements. The Brainstorming session for Management OF Web Services was well run. Everyone was given a chance to state a set of requirements to be added to the list, this time in reverse order around the room. Afterwards, everyone participated in categorizing first the MUWS requirements, starting with the existing categories in the requirements document, and adding categories as needed. Then everyone participated in categorizing the MOWS requirements, using a new set of categories. Because two of the categories had a large number of requirements in them, there was discussion about setting up sub-categories at a later date. 6. Work on requirements and use cases in sub teams. There was not enough time to break into sub teams and identify requirements that would be in scope / out of scope, etc. 7. Wrap up and planning.
i. Winston and/or Heather will separately release the official timelines and milestones. The notes included here have items that were discussed but not officially approved.
i. Winston and/or Heather will separately release the official Action Items. Those details were not completely captured in the meeting notes.
i. The plan proposed was to meet shortly before or shortly after the Open Group meeting in Boston in July. Because of other conflicts, the consensus was to have another Ballot, among these three choices: 28-30 July (immediately after). 16-18 July (week before). 4-6 August (neither, but perhaps with fewer conflicts). ii. There was also discussion about planning future teleconferences. Due to the amount of work needed, the group proposed expanding to 2 hour meetings. iii. There was also discussion about having the meetings start later, to better accommodate the California majority. Detailed Notes Wednesday, May 14. 1. Welcome and
Introduction
2. Management OF
Web Services Review I got there late. They were on Slide 7 for E1014. Heather going through it. Question on the Management Concepts for Slide 8 better that it be considered manageability, rather than what you do with it trouble shooting, FCAPS, etc. Winston where is distribution? In this or outside the management? Heather focused more on real time, not on software distribution. Winston compare to W3C work on the subject. Discussion of Provisioning and relationship. Provisioning TC is a subset of Configuration, enabling the use of some service. Installing a router is not Provisioning, but giving a user an account, or a business partner access IS. X does this presuppose something is there? A- ordinarily, otherwise it may result in some other activities to make the capacity there. Ellen. Two pieces one is manageability, the other is management applications and functions that rely on the manageability information. This discussion needs to take place in one or the other framework. Heather what is GGF doing? Giving users access to resources, or managing them? We want to make sure that the Web Services do what is needed so that management can do what it needs to do. Provisioning in GGF is more making sure the resources are available as needed. How do you define what you want to do and how do you execute it. Interruption for introductions of late people. Disk Spellman of Sun on the phone model issues vs access issues. Veena of HP. Andrea of Cisco, who will give a presentation tomorrow. Heather continued on. Defined a Manager Role. Needed a model for what information would be available to the Manager. Manageability Capabilities. Includes Events, Operations, Attributes, etc. Q: Is the role, actions, operations of the manager outside the scope of this TC? Gil right to separate the information the managed system provides vs what the managed system wants to do. Not going to define the normative actions of the manager show of hands. Can tie requirements capabilities to Use Cases. Many capabilities are used for various management actions. Have to tie them to at least one Use Case. Thus, consensus that we don't need to define all the management actions. Need to capture key items in the Use Cases. Scope Slide 1. WS Manageability. 2. Management Applications. 3. Management USING WS. 4. Manager WS. Heather This TC has 1 and 3, but not 2 and 4. Looked at Slide 33 Manager Web Services, number 4. Example in WSTK talking to Tivoli Event Console, one that queries Inventory Data. The thought was to define Management scripts across an Enterprise. Could help identify details about Web Services to see if it is interoperable with you, what versions are installed, etc. The DMTF would define the object. This TC would transmogrify it into a Web Service Interface. Heather this is how you access a Management Application like Inventory. If we wanted common interface for Monitoring. John would querying status of SLAs be part of 4? Yes. But we need to have the WS Endpoints provide enough information for a Management application to compute, determine SLA. Winston trying to get down to an atomic level to make sure the building blocks are there. Andrea think some parts of SLA are in scope metrics, basic statistics that the resources are reporting, events they fire off, etc. Winston discussion of picture that Winston drew. There are Managed Entities that ask the Manager for information, to perform better. Basic information to enforce policies come from Managed Entities. Some Managed Entities may have Management capabilities. Also, it may not, such as how much should the Managed Entity know about access control and the user coming in? So such a requirement may not end up being the Managed Entity's requirement. Heather let us have consensus that we start with Use Cases. Concerned about scalability need to be able to address groups of things, not just end entities. Winston could have an interface that applies to an entire system, inside the system is middleware managed elements, can have process level interfaces. And we have talked about Managed Elements being proxies or agents for multiple other resources. Suggestion label it a Control Point for a Managed Element. Winston use the DMTF term Service Access Point. (Manageability Access Point). Slide 11 internal or external, plus firewalls, etc. Slide 13 views. Service Provider, Service Requester, Manager (more omniscient, perhaps). Slide 14 Management of Web Service Architecture. Web Service Endpoints. Did a lot of drill down there. Web Service Execution Environments. Haven't done much drill down there. Discovery Agencies. Service Requesters? Peer to peer, others. Intermediaries? Proxies, etc.? - not defined by W3C Architecture yet. Discussion what does Web Service Endpoint mean? How high a level? Heather at the Port level, using WSDL terms. Leads to discussion of stateful session oriented options. What about Execution Environment? Heather thought of it as a managed resource. Should this be Management OF WS? Heather yes. May be hidden, if you tell a WS to start itself. We should avoid talking about COTS application servers, though. Also want to avoid talking about the hardware and software that are part of the Execution Environment. Heather talked about it as its ROLE in the WS Architecture. There will be a set of pre- and post- conditions for Manageability. Winston Management OF a Web Service take the model of Service and extending it for Web Services CIM has a model of a Service. This is different from the Control Point or Service Access Point. Also, we need to be clear that entities have Functional SAP and Management SAP(s). Heather, the double triangle on Slide 16. Winston example of McDonalds Functional Service Access Point is the Counter. Management Access Point in the back, checking employees and supplies, etc. Execution Environment. Heather if you are having issues of Availability, may need to query Execution Environment. Need to be able to distinguish between the entity and the environment. Want to avoid the slippery slope of getting into the implementation. Management OF what is the model, relationships between them, etc. Slides that showed WSDL and different Ports to have different Interfaces logically different, not constraining the implementation. Noted that it allows the different port to redirect the user to another URL. Slide 18. Slide abstracts the W3C document. Discuss the source document. Operations meant to be the Control Handles, not specifically limiting to WSDL operations. Slide 19. This clearly says enables, not defines, management applications. These are good ideas for Use Cases. Slide 20. Manageability. Events and metrics, in context of state. Define states and lifecycles. And state transitions. And how requests cause state transitions. portType slicing by audience: Functional (authorize) Manageability (start, status, replicate) Administration (addUser, changePassword). Discussion of the terms here, and other terms used elsewhere. Especially OA&M. Operations, Administration, and Management. Telcos, large data centers, even BEA uses this term. Slide 21. Two states for Endpoint UP and DOWN. Then substates UP - busy and idle. Note that this can be counterintuitive DOWN can be saturated, even acting as designed, may be designed to take only 10 requests. Break. Winston. Agenda check 3:25. Plan to continue this discussion until 4:00. Brainstorming and Use Cases discussion at 4:00. Continuing substates of Down. Stopped, Saturated, Crashed. Diagram in W3C has full state transition diagram. All possibilities. Presentation of the States a Request can have, different from what the Web Service can have. Q: is there a state for the response having been sent back? A: No. Slide 22. Glossary from Web Services Architecture endpoints. Associated interfaces. Administrative Management Security Identification of Managed Service. URI WSDL URI Semantics URI. Slide 25 Metrics. Per Service and Per Operation. Includes context to identify the request. Q: is this optional? A: didn't address optionality in W3C yet. John time periods are in the original document. Planned to have configuration of metrics collection sliding window, etc. there was a lot of debate about whether the Endpoint or the Manager should have some of this information. Heather specified you must be able to shut off metrics collection. Slide 26 Events and Operations. Slide 27 highlighting agent - Resource Representative, vs real Resource. Slide 29 different views of the Manager. Don't have to reinstrument everything just some bridges, agents. Slide 30 USING Web Services. Manageability Capability portTypes Resource Representation portTypes Infrastructure portTypes Registry. Existing models for management information. Slide 31 hides the traditional Manager Agent. Managers always talk to the resources (endpoints). Even though it may be a smaller number of agents. De-couples Manageability from INTERFACES. Discussion that you may not always want to act as if you are talking to an individual resource. Jeff May want to talk to an agent that manages 15,000 endpoints and give it just one command to turn off metrics collection. Example of managing individual McDonald's stores vs managing the West Coast Region. Heather discuss further tomorrow. Winston need to handle it, don't forget the points. Slide 32 Why we need this. Same reason Web Services being used for other functions. Discussion of what Web Service means, several different views. Shel Notion of permanent single instance of a Web Service that everyone goes to. There can be transitory WS, can have multi-threading, multiple instances, etc. Heather services are transient. Manageability aspects of Endpoint - traffic that goes through that URL. Discussion of whether we care about EndPoints or just the Operations they have. Larry Proposal that we need a new term for Operations only. Only really care about the Operations and how they perform. Fred motivation was to fit into the Web Services Architecture. Winston a request may require multiple operations. So if you care about Requests, then you need a higher level of granularity. Fred not sure a Request ever matches directly to multiple Operations. Mark? - Confirmed that a Request is of an Operation that is exposed at an Endpoint. Shel need to think about consistency. Mark? - Endpoint was also defined as something you expose to people and defined in WSDL. This is what people send messages to, from consumer point of view. Fred real issue is providing the mechanisms, not the policy. Heather an Operation is a Managed Resource? Need to address this later. Note that Operations and Requests have one-to-one mapping. Shel real Web Services are sending an asynchronous Request, getting response right away without the data yet, followed by the full Response later. Heather have a requirement for asynchronous request support. Winston model this in CIM as a Job with Queues. Heather then went to the link for the Management Submission from W3C. MTF Web Service Instance 20030229.htm , from web site. The MTF did do a lot of work on defining terms. Propose we use these terms. Section 3. Section 1.3.1 Management Capabilities Categories. Homayoun is Security a Management Capability of an Endpoint? Many said no. Winston can look at it as having configuration parameters, etc. two interfaces, etc. Or you can treat it as a special case. Would like to delegate the responsibility for a Security Access Point to another group. This group is concerned with enabling management, including configuration. Fred there are other groups working on Security, and potentially how it is to be managed. Sufficient to say that there is a Management Access Point for Security, as defined elsewhere. Security OF the Management, the Architecture, not Security of the Endpoint. John could have a Request Rejected state for a Request, and count it. Heather Security groups addressing this. They have security policies. Hal no one addressing the administration of security. WSI not doing it. W3C not doing it. John one of my bugaboos is extensibility. Want a core set, enabling things, that other standards bodies can extend for their environments. Winston may not need Security as a Capability, but we can still address it. Hal a minimum item is configuring security services. Like configuring how to look up security tokens, for example. Again, Use Cases can highlight. Homayoun more fundamental item, may need it as a core Capability. How we model it may take longer. Ellen much of the security policy comes under USING. Pankaj - Use cases can illustrate how this needs to be done. Associations, section 3.2.1.3, separate WSDL discovered through the Management interface. Or separate URIs. Separate Security interface, relationship, mentioned here. Winston chaining capability to go to other interfaces is important. Jeff? - Configuration is on the list, but not Administration. Why not? Heather Administration was more functional. Only place it shows up in W3C MTF document, is as an association, like Security. Lots more discussion. Discussion of QoS. Management Application realm, though it may require special operations or information at the Endpoint Management Control Point. MTF group was chartered to address management items in the WS Architecture. this is for Management OF Web Services that was the charter of the group. May want something a little different for Management USING Web Services. 3. Brainstorming, categorization, prioritization of requirements. MOWS. Larry Winston asked everyone to silently write down requirements for Management Of Web Services. Brainstorming. Winston no comments from the crowd until all are captured. Heather captured the requirements. Put them as Appendix B. Brainstorming, in the MOWS Requirements Document. Winston time to start discussing the Brainstorm session. Thursday, May 15. 4. Management
USING Web Services Requirements Review Presentations today. Ellen (GGF), Carl (), Andrea (DMTF) Ellen.
GGF Update. There is work going on in GGF that applies to WSDM. Two groups in particular OGSI OG Services Infrastructure. The other is CMM Common Management Model. OGSI WG people are confused about grid. Divided into two pieces. 1. High performance computing, resource sharing, etc. 2. Infrastructure piece. Essentially a set of extensions to the current Web Services world. Set of extensions should be viewed as the next logical step for moving Web Services forward. Defined a set of properties and portTypes that move stateless WS to statefull Web Services. People ask why they aren't doing this through W3C or OASIS? Should look at it as an incubator project. And many GGF items have been taken to W3C. Needed portType inheritance, and now part of WSDL 1.2. this past week, proposal from GGF for Service Data concepts presented to W3C, asked to commission a Task Force for this. OGSI Specs of interest to us. Identity handles and references (URIs). Service Data add properties and attributes to portTypes and corresponding Operations. LifeCyle or LifeTime attributes. Narrow definition when is a Service Instance valid? Sort of like Time To Live. With operations available to extend it. time that the information is valid. Fred like a kind of lease. Ellen and it can be updated as needed. Often applied to cached data. Service Groups. Set of constructs you can then use to form specific Registry information. Can aggregate as you see fit. Factory. Notification. Service Locator. PortType inheritance. The OGSI spec has gone out for last call, with not much discussion. Pretty good shape. Recommissioning the Group at next GGF (8). Tasked with a Primer on how to use it. Lot of interest in taking these services and allowing them to operate in WSDL 1.1 world that is deployed today. Move to flatten the Grid Services WSDL that extends 1.1 into 1.1 using the Open Content model. GSRs. Handle Schemes to go into a separate document. Public statements to avoid conflict with other groups, want to establish liaisons. CMM WG Common Manageability Model. Just started out. BOF recently. Idea that you have to manage the Grid, which requires an additional set of Services that need to be there. Can be looked at as an extension to OGSI. Need to define a Relationship Service. Not just applicable to Management. Will have to get pushed to W3C or OASIS. More information, more portTypes, for items like Life Cycle, for example. They will not be creating another Information Model. Focusing on higher level abstracted services. Intent is to get the appropriate IM owners, such as DMTF, to express them in WSDL 1.1 or real XML format that can be used. Outputs. 1. more port types, like Life Cycle, Relationship. 2. canonical portTypes. Operational Port type, for example, defining basic set of services start , stop, etc. 3. small set of XML schema extensions necessary for management. More detail on life cycle and change control. 4. Best Practices document. This is how you need to manage. GGF 8 Charter is pending approval, should be approved this week. Updated CMM document from BOF held in March. Outline for Best Practices document. Ellen is chairing, with co-chair from Hitachi. Q&A Winston observation. Appears that work going on in GGF is pushing new concepts to finish out WS definitions, languages, architectures. Because they are implementing grid. Ellen yes. Expect much of this to be broadly applicable to Web Services. View it as next logical extension of WS. Winston recently formed a liaison between DMTF and GGF. Ellen will need one between OASIS and GGF. Winston see GGF paving new area. Ellen behooves all of us to think about what are the right working relationships and liaisons that need to be defined. Make sure work is complementary instead of conflicting, overlapping, competing, duplicating. Makes it harder for vendors and customers. Winston. Talks to the press a lot. Network World asked for interview today. They love to ask why there are all these standards groups. All standards groups function differently. Look at them as different engineering groups, with different specialties. Showed petal diagram. Ellen don't forget Open Group. Hal have a group with an urgent need looking at subset of problem, adds extensions. If they implement, how does convergence work? Ellen GGF has a track record, though, OGSI spent time with W3C to get stuff into WSDL 1.2. Hal Liberty Alliance is another case. Just an observation, not a criticism. People with urgent needs tend to not want to wait for the general solution to come out. Shel strategy to converge is good. Things in OGSI good for WSDM. Things asked for yesterday covered in OGSI. Like sessions, statefull. And it was mentioned about WS-Addressing, etc. Winston good that there is communications between the various groups. Winston is fairly optimistic. Shel backwards compatibility is extremely difficult and customers want it. Just because it is tough, should not avoid it. Heather the reasons for these presentations is to highlight other standards groups efforts. Avoid duplication. Jim is the scope of the CMM just the information model? Ellen really focused on the set of broadly applicable portTypes and Services needed for management. Think of the current work as not domain specific. Jim expect other GGF groups to address management, or have all of that done in CMM WG? Ellen not sure how GGF views it. Have left the Charter open that additional canonical services may fall in here. Also, could be recharted at the next GGF number. Karl Schopmeyer Work on Managing Applications. DMTF and Open Group. DMTF Application Work Group. Application life cycle model. Application runtime model. CIM Metrics WG. Unit of Work Metrics. Base Metrics. Finished work. UoW Model. Nested transactions. Capture information as transaction goes through the system and correlate. Version 4 now. 3 was Java. 2 a client. Service Level Management coming together with this. CIM Base Metric Model. More general information than the Unit of Work. Application Lifecycle Model. Work Today. Application Model Overview. Application Lifecycle. 4 states. Deployable, installable, executable, running. With transitions. Applies to lowest level component (file in .ZIP file, e.g.) RunTime Application Management Requirements. (SAP has 40-50 people working in CIM committed to it.) Application Management. Fault. Configuration. Performance. Management Processes change process management. Service Level Management Business Level Management. Manageability Requirements. RunTime Model must: (see list in presentation). Not the physical model. Inherently Distributed, not local. Requires relating the Unit Of Work information to the runtime structure. Application Architecture. There was no good definition of Application. Views and Elements. RunTime Model Structure revisited. Model Concepts. Hal can you integrate other models into this? Karl yes, designed this way. Could have an Oracle model that links in, for example. Not really there today, but Customer needs to do this. Metrics dynamic extension to Metadata. Uses the Decorator Pattern (Definition Class and Value Class). Late binding. Unit of Work. Tied to ARM. Base metric. Single measurement metric. Current work. Metrics manipulation (aggregation, Correlation, etc.) Group working in several different areas. To use this. Q: Jim looks like similarity between WSDM and this work. Karl believer in Models. Want the basic Information Model for management. Want Web Services to be a subset or component. Winston see us as providing some extensions to the model, where we come up with items that aren't already covered. Andrea goes across almost all the DMTF groups, like Support, Diagnostics in System, etc. Open Group chair of Enterprise Management Forum. QoS Task Force 2 years work. Got trapped between Network and end-to-end QoS. Application Quality / Resource Forum (AQRM) focus on Application QOS. - large, distributed applications. ARM Application Response Measurement. Transaction Response Time Management. API that sets the model for a lot of start-stop time measurements. Updates AQRM. QOS management, not just QOS monitoring. Just in startup stage. Started 2 weeks ago, 10-15 on telephone, 15 in room. Came from Customer Concerns, as much as anything else. We still can't manage QoS end to end. Applications really drive QoS. Not just the host or network. Applications have to drive the model. ARM. Started as an API. Become part of a model on measuring response time. First versions had poor acceptance hard to instrument. Interest in marrying ARM to RunTime model. From both Applications WG and ARM. V4 still requires instrumentation of the Application. Also need real support from the OS. But seeing some movement in the Tools Vendors to put this in. Also have seen more support from OS vendors. Discussion of getting apps instrumented. For example, with JMX now in the standard SDK, makes it easier to instrument. Andrea Westerinen. DMTF Technical Overview. DMTF VP of Technology. Presentation uploaded to OASIS WSDM documents. Technical Organizations Support group concerned with Trouble Tickets, Help Desk, use XML. Policy WG looking at automated management, self healing. Depends on operations and information in the model. Can use the whole infrastructure. Interoperability Events WG Interop. how do I manage the infrastructure, the Management services themselves. Events how do I send events, do I have the right information, goes across MIBs IETF, ITU, etc. IETF DisMan group has been working on coordinating alerts and alarms reported. Have combined them. Applications and Metrics. Karl worked on. Networks wireless, wired, etc. Security Protection and Management group (SPAM). Standardize events, virus notifications, etc. Notice OASIS to kick off Web Application Security group, doing similar things. OS group can I notify that the OS can't get running? Basic hardware actions and notifications. User/Security Ellen chairs. Can I do basic White Pages stuff, plus authentication and authorization. Tie credentials to privileges, and infrastructure support. Database how do I manage and operate databases. Systems and Devices pieces of computer systems, racks, chassis, cards, things contained in other things, etc. Core Model capabilities, statistics, settings, general systems, services, Service Access Points. Diagnostic model Common Diagnostic Model (CDM). Will never have a common diagnostic tool, but could have diagnostic services tell about their status, etc. working in conjunction with COMDIA (Common Diagnostic tools group). Technical Deliverables. Development Process. Five Phases, ending in Final Standard. All additions come as Change Requests from the appropriate WG and then forwarded to the Technical Committee. Technical Collaboration. Want vendors to be manageable as an asset. Showed the petal diagram. DMTF has expertise in Modeling, bringing in the data semantics. Change the view of management to interoperable data. One, unified model. Examples, change a config, restore a config - if there is not standard data in each of these, consistent data, then those operations are not useful. Customers don't really care about protocols, either, as long as they aren't something special and hard to implement. Need concept of diagnostics, based on the information and relationships. Mentioned that people think that one unified model is impossible. Homayoun proposed that there may not be a good reason to make one unified model, like CID (?) in the telco world vs. CIM. Everyone is happy with the separation. Andrea there have been discussions on aligning CID and CIM. Hal how do you feel about independent, non-overlapping models, would that be progress? Andrea it would be progress. Don't care that much about rendering, only care that everyone calls the same thing by the same name. They do need to fit together when the Customer gets it. Model Unification need to understand the problem and what you are trying to do. Then look at CIM and fit it into the bigger picture. If you start with CIM, you lose the benefit of understanding the problem. Karl problem, requirements, model, CIM. DMTF Standards. WBEM overarching for accessing data. CIM 2.x and 3.0 WBEM Technologies. CIM-XML today XML DTD and HTTP CIM-SOAP WG as Interoperability sub-team XML-Schema from the DTD that exists. DTD is very high level, things like Property in the XML DTD. Will do tags that actually mean something. What should it run over? XML-Schema and SOAP. XML-Schema and WSDL. XML-Schema and UDDI. Needs to fit into what OASIS, GGF, etc. are doing. Q: Winston Classes and Properties? A: Karl 991 classes. Winston 2500 Properties? Karl at least. Winston DMTF is holding a conference in June, Silicon Valley Convention Center, just down the road. Representation from OASIS, GGF, etc. Want to make this a conference dedicated to Management as a whole. 5. Brainstorming, categorization, prioritization of requirements Management USING Web Services. Brainstorming session on requirements. (Only got 146 from the MOWS session yesterday.) Have some requirements from the past, MP TC. Take 5-10 minutes for MUWS Requirements. Homayoun definition of MUWS? Heather rely on Web Services platform to be able to develop MUWS. Like schemas of management characteristics or lifecycle or portTypes. Other things like notification mechanism, ways to describe relationships, may be more general than just management. Want to be careful about things that are specific to management and avoid infrastructure improvements. Heather captured the requirements in the MUWS requirements document as an appendix as we went around the room to capture the requirements. Started with IBM requirements. Then went around the room in the opposite direction. Mention of when outputs from this group need to arrive to be useful. Categorized the MUWSA requirements. Caught in the document itself. 2.1 Functional Requirements (A) 2.1.1 WSA Compliance 1, 2, 3, 4, 6, 11, 12, 15, 16, 22, 25, 28, 45, 48, 50, 71, 76, 104, 105,125, 128 (B) 2.1.2 Message Exchange Patterns 38, 90, 142 (C) 2.1.3 Conformance/Consistency with Other Standards 11, 12, 20, 23, 25, 39, 57, 71, 125, 130, (D) 2.1.4 Distributed Management multiple managers, hierachical 18, 24, 32, 33, 42, 43, 53, 85, 98, 101, 103, 111, 114, 117, 126, 132, 133, 135, 136 (E) 2.1.5 Security 19, 25, 30, 34, 41, 70, 74, 82, 83, 99, 112, 115, 116, 139 (F) 2.1.6 Model Neutrality 36, 56, 68, 97, 122 (G) 2.1.7 Model Exposure 5, 7, 8, 9, 10, 21, 23, 33, 50, 65, 76, 89, 91, 104, 115, 122, 124 (H) 2.1.8 Manageable Resources 29, 31, 46, 60, 64, 73, 79, 80, 81, 93, 94, 95, 103, 106 (I) 2.1.9 Life-cycle Management 26, 92, 131 (J) 2.1.10 Miscellaneous 35, 44, 51, 63, 94, 112, 120, 121, 122, 129, 143 2.2 Non-Functional Requirements 2.2.1 (K) Interoperability 14, 40, 47, 57, 67, 75, 123 2.2.2 (L) Evolvability 103, 108, 109, 125, 127 2.2.3 (M) Extensibility 9, 10, 13, 17, 49, 54 2.2.4 (N) Scalability 24, 32, 33, 69, 72, 86, 88, 110, 119, 137 2.2.5 (O) Useability 14, 55, 62, 84, 107 2.2.6 (P) Internationalization 66, 87, 134 New (Q) Semantics 16, 21, 53 (R) Performance Impact 27, 113, 118 (S) Self Management. 29, 58,102 (T) Federation. 32, 53, 100, 103, 133, 140, 141 (U,V) Coexistence 37, 50, 51, 59, 61, 77, 78, 84, 13 Winston talked to Network World, they are doing an update, follow up article on Management of Web Services. Told them he is co-chair with Heather. Management OF Web Services Categorization of Brainstorming Requirements for MOWS A. Manageability Model 1, 2, 5, 7, 10, 11, 13, 14, 17, 18, 21, 22, 23, 25, 26, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 40, 45, 46, 47, 54, 55, 59, 62, 64, 67, 68, 69, 75, 77, 78, 81, 82, 84, 86, 88, 90, 91, 92, 94, 95, 96, 98, 103, 104, 108, 109, 114, 117, 118, 119, 120, 122, 125, 126, 127, 128, 133, 135, 138, 142, 143, 144, 145, 146, 147 A.1. Identity A.2. B. Web Services Infrastructure 15, 16, 26, 35, 42, 44, 54, 58, 60, 61, 79, 87, 88, 107, 115, 116, 119, 131, 132, 134, 139, 141 C. Secure 43, 57, 61, 74, 80, 136 D. Interoperability. 31, 34, 44, 76, 101, 106, 107, 116, 131, 134 E. Access to Model. 11, 12, 15, 56, 69, 70, 71, 73, 98, 100, 102, 106, 121, 127, 142 F. Extensibility. 4, 63, 66, 105, 123, 124, 130 G. Management Things (Applications, Scenarios, etc. ) Enabled. 6, 7, 8, 17, 18, 19, 20, 21, 23, 25, 26, 27, 30, 33, 37, 39, 46, 47, 48, 50, 51, 52, 53, 58, 69, 82, 85, 90, 93, 94, 95, 110, 111, 112, 146 H. Miscellaneous. 3, 83, 97, 129, 140 I. Discoverability. 12, 24, 28, 41, 89, 126 J. Usability 49, 72, 99, 113, 137, 148 7. Wrap up and planning Action Items 1. Update MOWS Requirements Larry, Veena, Heather. Before next call, for all to review. 2. Update MUWS Requirements Pankaj, Veena, Heather, John, Nic. Before next call, for all to review. 3. Review Categories ALL, for next call. 4. Categorize and Prioritize and Eliminate Requirements ALL, for next call. 5. Investigate Formal Liaison Procedures Chairs Heather and Winston. 6. Process for ... Liaisons discussion of Contacts v. formal liaisons. Discussion of conflict of interest, depending on role of person in each group. Discussion of whether needed based on current activity. Keep in contact with (contacts): GGF CMM and OGSI. (Ellen as Contact). OASIS Provisioning (Darren Rolls), WS Security (Hal Lockhart), WS Addressing, WS Policy, BPEL (Sanjeev Kumar) DMTF (Andrea Westerinen and Karl Schopmeyer) OpenGroup (Karl Schopmeyer) W3C WS Architecture, Management Task Force subgroup (Heather Kreger). W3C WSDL 1.2, 1.3. (Igor Sedukhin) IETF NetConf watch for activity (Andrea). Nothing clearly going on to impact or be aware of right now. Watch DISMAN for acitivity. JCP JMX and JSR 077. watch for activity (Guru Bhat, Karl Schopmeyer via DMTF). Second round will add in Web Services as an element, like EJBs. JSR 160 being standardized right now, too. WS-I. - basic profile implications. Manageable profile in the future. WSDM responsibilities for Conformance, Interoperability, and Reference Implementations. Winston OASIS process. We can approve it for a Committee Spec. 30 day window to submit it as general Spec. 60 days total to do: 2 weeks to go through submission process, 30 day public review, 2 weeks to vote. Winston 3 companies committed to using it. Hal they have to attest that they are successfully using it. Don't have to implement it. If they implement it, they attest they have satisfied any IPR licenses. TC can specify more details, like what successfully use means. No OASIS requirement to demonstrate interoperability. Get IPR lined up. Ensure spec is implementable and clear enough for intereroperable implementations. Winston would like some implementations before 1.0, or else 1.1 will be needed right away. Shel will we come up with one spec or two? Winston try to work together as much as possible. At some point will need to focus down. Have not yet decided on final specification being one or two. Having two makes it easier for the person who is just a manageable Web Service, for example, and implementations will probably do just one or the other. Winston propose doing an Interoperability Demonstration before submitting a Specification. Timelines for WSDM work, including Milestones. January 2004 for a Committee Specification. Part of Charter. May face revisions before submitting as OASIS spec. Scope of Specification. Plan for 2 specifications: OF and USING Draft Specifications October 2003. Reference Implementations November 2003. Interoperability Testing November January 2003. Agree on Requirements and Use Cases, with Specification Outline - by next Face to Face in July 2003. Discussion of driving forward, to make it easier for the specifications to be used. Possible need to extend current meeting time by another hour. Homayoun group should vote on it. And the exact time, because too early for California. Maybe start at 0800 PST (1100 EST). John need to have a parallel activity of identifying all the Models to start with, then we can focus on the extensions we need in WSDM. Discussion of USING v. OF. Should OF use the CIM model? Larry need multiple bindings for USING. Start with a binding to CIM. Shel what is meant by using CIM model? Winston there is a lot in there, services, resources, metrics, units of work, etc. Shel can be 1- part of internal representation we should not dictate that. 2 using CIM as part of messages being used, brings up CIM-XML issues. 3 actual systems being managed by CIM. Winston common semantics. Heather want to draw the pictures in UML, etc. Use CIM for this, using the Base Classes. Shel you mean it should be a basis for building a conceptual model? Heather yes, one possibility is to build it, extend it, and submit back to DMTF. Discussion of whether WSDM needs to have a model or not. John don't we have to have a WSDM model? Homayoun -not sure we need to build one. Fred need to have a common vocabulary. Veena there is a lot of baggage associated with CIM, if we start with CIM, it will be hard to get rid of unnecessary baggage. Mark should develop a logical model from scratch. John are you saying that starting with CIM and extending/removing is harder than starting from scratch? Veena don't have to start from scratch, can reuse much of CIM without starting with CIM. Heather a lot of work has gone into CIM and other models. Think it is perfectly reasonable to get our requirements and pull things out of CIM that are needed. Need to avoid being defensive about technologies. For instance, OMI has less than CIM, many things are exactly the same. Veena as long as it works naturally. Sanjeev let us decide on Standard UML, not CIM UML. Karl remember that Web Services will not control the entire world. Key is to avoid having many different management models, with every new technology. Mark managing Web Services will drive more than just managing Applications more distributed, etc. Richard when you look at a Web Services environment, what is new? Nothing, really. Integrating legacy applications, exposing them in a new way. CIM has addressed a lot of the infrastructure. Veena we want to define our model, and then address the existing models. Identify whether it fits or not. Winston if we keep battling the issue of models, we are doomed. We need to drill down on the required data, but we don't need to create a completely new model. Shel we are in violent agreement here. John we can build the high level model, independent of payloads, naming, etc. Then we need to bring in details from existing models. Planning for next Face to Face. Winston Karl talked about this being around the Open Group in July in Boston. Many in this group will be there. July is a good timeframe. 21-25th July is OpenGroup. WS Architecture 28 July -30. WS Description 30 July 1 August, in Toronto. Winston How about July 16, 17, 18. (W-F). (Igor and Fred can't make this week.) Hal BEA could host in Burlington. John possibility for MITRE to host in Bedford, 3rd choice have to go through security. Shel Sun may be able to host, if BEA can't. 2nd choice. Hal how many? Winston Plan for 20-30. Online Ballot, like this time. Options: 28-30 July. 16-18 July. 4-6 August. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]