- From: Sedukhin, Igor <Igor.Sedukhin@ca.com>
- Date: Wed, 25 Sep 2002 21:38:56 -0400
- 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>
- Message-ID: <87527035FDD42A428221FA578D4A9A5B844405@usilms24.ca.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 UTC