RE: [MTF] Updated WS Management Architecture concepts

Igor, thanks for the response  - comments inline:

-----Original Message-----
From: Sedukhin, Igor [mailto:Igor.Sedukhin@ca.com]
Sent: Wednesday, September 25, 2002 6:39 PM
To: Mark Potts; Heather Kreger; Eckert, Zulah Karen; Willits, Jim; Colleen Evans; Husband, Yin-Leng; Sandeep Kumar; Prasad Yendluri
Cc: www-ws-arch@w3.org; MarkPerreira
Subject: RE: [MTF] Updated WS Management Architecture concepts

Mark,
 
Thanks for your comments.
 
I had this abstract service in my first cut, but I got rid of it for the following reason. May be you could help me bring it back.
 
If we look at services from client<->service interactions (which are the basis of it all), then abstract service really means everything, but the <service> tag in the WSDL contract. In other words it is sort of service type really. The abstract service does not exist without a service (not for a client, not for discovery purposes!) and does not manifest itself anywhere. It is such a design-time concept that it would be very hard to put any meaningful management to it at runtime.
[Mark Potts] 
I agree a service cannot exist in terms of management without at least one instance. As for its role as an element of management I don't quite agree, maybe this is a definition problem in what each of perceives the service to actually be. My point is that the management and measurement in terms of performance and availability will be driven from 2 perspectives  - one the client itself and the second the provider of the service. From the clients perspective they are dealing with a service ( defined in the contract they consumed )  - they should not be aware if it is a proxy or an instance  - all they know is the service has been offered and they are consuming it ( perhaps under some defined SLA also). This is important when in some cases there are multiple versions/ instantiations of the service (instances) under the umbrella of a single service (abstract)). From this perspective the reporting, management, and less likely control is at the abstract level.
 
When we talk about the perspective of the provider (the ultimate provider, an instance) then they want management of the instance that may well give the same information as the abstract service but it will be for a specific instance The Service as an abstract element may not be able to give all the information that an instance can  - e.g. CPU usage, memory, but it non-the less has to be capable of offering management interfaces in terms of P&A, however they are resolved
 
I had placed abstract service as part of a drill down of the Contract. I guess that would be proper place for it. Client or Discovery Agency could locate services by contract equivalence based on understanding of the abstract service.
[Mark Potts] Yes and my point is that management as well as  discovery can be done at the abstract level  - maybe not control but aspects of management that cover performance and availability. Management will have to be supported at this level for the case where services or intermediaries resolve their dependencies on other service dynamically.
 
I agree on the "represents" for Proxy->Service, but "aggregation" to the Abstract Service would mean more the design-time pattern. So, it won't matter at runtime if WSEE hosts just a coded service or a process-aggregated one. 
[Mark Potts] I can sort of buy that - but if the dependencies are not to be visible and a service that happens to be process is managed exactly the same way as a service that represents an activity that is part of that process, but I can see times, from a management perspective for "root cause analysis" especially, where the resolution of endpoint for service types is dynamic you want to see the dependencies of a service with other services as a management capability. I would also add that I think the management capabilities in terms of the WSEE would be different if one were a "container" (I know were are not allowed to use that term but humour me for now) or a state machine - i.e. a provider platform or a Process engine.
 
 We'd need to get to process management/choreography to figure out anything more detailed about an aggregated service, which we probably don't need to do right now. It won't really matter how service has been created -- is it a coded service or a workflow. 
[Mark Potts] My concern is that if the dependencies are not to be visible and a service that happens to be process is managed exactly the same way as a service that represents an activity that is part of that process,  from a management perspective I have little help in terms of "root cause analysis", especially where the resolution of endpoint for service types is dynamic. In this case you want to see the dependencies of a service with other services as a management capability. 
 
On the other hand, we do need to take care of management of Intermediaries and relay-sorta proxies because this is part of SOAP 1.2 basic MEPs.
[Mark Potts] Agreed  - I think dynamic resolution mentioned above is also a problem.  
 
In other words, for management architecture we probably need to focus on everything that is valuable, operable and measurable at runtime. The conceptual model that we build should easily lay out into the management components and their semantic links (named relationships). I would leave other concepts for more generic, service-design/development/business architecture.
[Mark Potts] I agree this should be the goal -  overall you will see that I think that there is a lot that is eaningfuland measurable and valuable in terms of abstract services (i.e. the service as described by its definition, not its implementation). My view is often skewed however as I live in the world of intermediaries and proxies!
 
Hope this makes some sense.
 
Thanks Mark

-- Igor Sedukhin .. (igor.sedukhin@ca.com) 
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788 

-----Original Message-----
From: Mark Potts [mailto:mark.potts@talkingblocks.com] 
Sent: Wednesday, September 25, 2002 6:16 PM
To: Sedukhin, Igor; Heather Kreger; Eckert, Zulah Karen; Willits, Jim; Colleen Evans; Husband, Yin-Leng; Sandeep Kumar; Prasad Yendluri
Cc: www-ws-arch@w3.org; Mark Perreira (E-mail)
Subject: RE: [MTF] Updated WS Management Architecture concepts


Igor
 
Looks really good at first pass my only concerns is around the relationships between Services, Service Instances, Hosted Services, Intermediary. There are probably many ways to model the relationships between these but I think that Service needs to be treated as an abstract in every sense.
 
A Service (always abstract) can either be a Service Instance, or Service Proxy The relationship from Proxy -> Service is on of "represents" (in the true proxy pattern), while the relationship from Service Instance -> Service is one "aggregation" (in the shape of a composite pattern, to either proxies or instances).
 
That leaves a relationship between Service (abstract), to Host (again abstract), where Host can be either a WSEE or an Intermediary.
 
To be clear the rationale for the an aggregation relationship between Service Instance and Service, is that WSEE could be a container or be a process engine where the process  - again a Service aggregates other services abstract and executes the process.
 
Just my thoughts  - 

-----Original Message-----
From: Sedukhin, Igor [mailto:Igor.Sedukhin@ca.com]
Sent: Wednesday, September 25, 2002 1:04 PM
To: Heather Kreger; Eckert, Zulah Karen; Willits, Jim; Colleen Evans; Husband, Yin-Leng; Sandeep Kumar; Mark Potts; Prasad Yendluri
Cc: www-ws-arch@w3.org
Subject: [MTF] Updated WS Management Architecture concepts



I have updated the document I sent earlier with an informal use case diagram and text. It provides place for for things like Management Protocol, Interfaces, etc.

<<WS Management Architecture Concept.doc>> 

PS. I'm cross-posting to the WS-Arch list. May be some of the basic concept UML diagrams could be used in the architecture document that the outer group is working on.

-- Igor Sedukhin .. (igor.sedukhin@ca.com) 
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788 

	 -----Original Message----- 
From:   Sedukhin, Igor  
Sent:   Wednesday, September 25, 2002 12:40 PM 
To:     Heather Kreger; Eckert, Zulah Karen; Willits, Jim; Colleen Evans; 'Husband, Yin-Leng'; Sandeep Kumar; 'mark.potts@talkingblocks.com'; Prasad Yendluri

	Subject:        WS Management Architecture concepts 

	I took an AI at our last MTF call to formalize some of the basic concepts of management of the WS Architecture. Attached is my attempt to do so. First set of diagrams and text explain management of the WS-Arch "traingle". Second set of diagrams and text formally expresses it in UML.

	 << File: WS Management Architecture Concept.doc >> 

	-- Igor Sedukhin .. (igor.sedukhin@ca.com) 
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788