[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm-ra] execution context and service description
+1 to If we model EC in SD via externalised document/file similarly to XML Schema (available via URI and not explicitly embedded into an XML document), we may have a pattern for EC, SLA and service contracts. Work that I’ve done on description templates have a lot of links. If external documents have sections or other identifiable chunks clearly marked, we could build tools to bring in the referenced material and create a snapshot of the current description without being dependent on a network to follow links. Ken From: mpoulin@usa.com [mailto:mpoulin@usa.com] I am not sure that service description (SD) has to contain all SLA, policies and all elements of EC as is; instead, they may be stored and managed in dedicated repositories and referred from the SD. In this way, we can have an EC-document similar to 'tech. requirements' of any SW product in the market but extended by the set of applied policies and tested/certifired compliance to regulations. If it is more or less clear that technical EC might be the same in Africa and Europe (machines, OS, networks, etc.), it is not true for business policies: every locale may have its own laws and related policies even in the countries of EU or US States (example: a local law about personal data in California vs. other States). So, all business policies applied to the service have to be mentioned as well. If we model EC in SD via externalised document/file similarly to XML Schema (available via URI and not explicitly embedded into an XML document), we may have a pattern for EC, SLA and service contracts. (A service has to have as many SLA as the number of its public interfaces including communication protocols). Since it is a commonly recognised need that the service policies better be stored in special Policy Repository, we can either use this Repository for EC or propose a dedicated EC Repository. What do you think? - Michael -----Original Message----- Our call today did not achieve quorum but we did have several useful discussions. One is captured in the informal minutes (to be posted when mp3 link is available) that follows: Discussion that we never modeled execution context and it would have been better to have taken that on long ago. What is relationship between execution context and service description? Certainly, a lot of the content in the description feeds the specifics of the execution context. Should the description feed “all” EC elements? A description could say Policy A is default and Policy B is available and the EC identifies whether A or B is currently in play. It is unlikely someone currently has sufficient cycles to take on EC modeling. The conclusion was we should start an email thread that tries to identify points we’d want to make wrt EC modeling and, if we converge on the important elements, we’ll see if someone is willing to take ownership. Feel free to add your thoughts. Ken --------------------------------------------------------------------------- Dr. Kenneth Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]