W3C home > Mailing lists > Public > www-ws-arch@w3.org > September 2002

RE: [MTF] Updated WS Management Architecture concepts

From: Sedukhin, Igor <Igor.Sedukhin@ca.com>
Date: Wed, 25 Sep 2002 21:38:56 -0400
Message-ID: <87527035FDD42A428221FA578D4A9A5B844405@usilms24.ca.com>
To: "Mark Potts" <mark.potts@talkingblocks.com>, "Heather Kreger" <kreger@us.ibm.com>, "Eckert, Zulah Karen" <zulah_eckert@hp.com>, "Willits, Jim" <jim.willits@hp.com>, "Colleen Evans" <colleen.evans@sonicsoftware.com>, "Husband, Yin-Leng" <Yin-leng.Husband@hp.com>, "Sandeep Kumar" <sandkuma@cisco.com>, "Prasad Yendluri" <pyendluri@webmethods.com>
Cc: <www-ws-arch@w3.org>, "Mark Perreira (E-mail)" <mperr@ix.netcom.com>
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.
 
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.
 
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. 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. 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.
 
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.

-- 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 
Received on Wednesday, 25 September 2002 21:39:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:06 GMT