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: 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-9572
Title: 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. 

    1. Liaisons.  The consensus was to identify points of contact (POCs) with different standards groups and to investigate the formal establishment of liaisons.  Individuals were identified as POCs.
    2. Conformance, Interoperability, and Reference Implementations.  There was discussion of the formal OASIS process for creating Specifications.  The consensus was that the January 2004 goal should be to have a Committee Specification, hopefully close to being ready to submit as an OASIS Specification.  There was also discussion that implementations are key to checking any specification.  Consensus was achieved that an Interoperability Demonstration would be needed before version 1.0 of the specification would be finalized.  As to whether one specification is needed or two (MOWS and MUWS), the consensus was that the TC could wait and decide that later, as work progresses.
    3. Timelines and Milestones for WSDM Work.

                                                               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.

    1. Review and assignment of action items.

                                                               i.      Winston and/or Heather will separately release the official Action Items.  Those details were not completely captured in the meeting notes.

    1. Planning for next Face to Face

                                                               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

  • I missed this.

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. 

 

Agenda.ppt



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