FW: [MTF] Updated WS Management Architecture concepts

FYI -- My latest responce to Mark's comments and a 100K HTML/PNG/ZIPped
doc is attached.
 
PS. I've tried www-archive@w3.org for the same 100K doc and it just
didn't work for me. It's been a few hours and my doc is still not there.

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

-----Original Message-----
From: Sedukhin, Igor 
Sent: Thursday, September 26, 2002 11:44 AM
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,
 
I think I got it. So, the "Abstract" Service will represent functional
semantics (e.g. a submission of purchase order) and Service Instance
will represent operational semantics (e.g. protocols to use, required
security headers, etc.). We can stick all the business metrics and other
common stuff on the "Abstract" Service (e.g. "how much money all your
Service Instances made for me").
 
I have attempted to incorporate the above into the concepts and
conceptual models in UML. Attached is the new doc (ZIP, as it is
becoming too large). I named "Abstract" Service, just the Service.
 
A few things that I had to make sure:

*	Service has a one-to many navigable binary association to its
Service Instances. I don't think aggregation would reflect the reality
and generalization certainly won't do it as well. Navigable associations
are very good for management models. I specifically didn't want to make
Service Instance a kind of a Service (i.e. extension) because then for
every Service Instance "operable object" you would have a separate
Service "functional base" and that would preclude management of the same
"functional base". 

*	Clients communicate to Service Instances, and therefore the
proper association stays there. 

*	I still think that Proxy Service is a kind of Hosted Service
that is a kind of Service Instance that knows about the other Service
Instance it represents. :) 

*	Note that Proxy Service can represent multiple other Service
Instances (association in the model is one to many). This gets you to
the service aggregation and root cause analysis at the level where
knowledge of process management is not necessary. The choreography
engine could therefore merely point out what service instances were
aggregated without the specific knowledge of the process flow. 

*	I think your notion of a Host is actually an Execution
Environment in what we've agreed upon earlier with the TF. In other
words EE is that abstract hosting environment that contains any kind of
Service Instances. Those Instances can be kind of anything you derive
from Service Instance. Therefore Intermediary is a kind of EE. Someone
could extend the basic EE and define things like Application Server, or
what have you.

 

-- 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 10:18 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; MarkPerreira
Subject: 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