OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [soa-rm-ra] [SOA-RA] Feedback and recomments on SD


I agree with Jeff about section 4.1.2.2 and Fig.25. However 4.1.2.2.2 and 4.1.2.2.3 have additional important info.I would like to write on these topics ( as one of possible variants ) but would like to get a common agreement on understanding of the relationships between Service Description-Service Contract-Service Execution Context-Services Interaction.
 
I apologise for going in loops on this but hope they are really spiral 'loops'.
 
Here is my understanding:
 
1. Why: we need a mechanism to announce and define an available SOA service to the potential customers; the Service Description is the announcement document.
 
2. What: the Service Description comprises
    2.1. description of the real world effects produced during (if any) service executions and as the service results,
    2.2. references to all policies applied/required by the service provider to the service invocation ( interaction ) and execution
    2.3. all references to the service interfaces (including logical and physical ones) in the Service Registries/Repositories (where description of the service operation may be found among other information)
    2.4. description of all service execution contexts where the service has been tested in (including both technical and business contexts) and provider can guarantee QoS
 
3. How: the Service Description may be accessed programmatically, on-line, or off-line for the purpose of making decision whether service capabilities meet consumer needs and, if they do, for deriving Service Contract from the Service Description
 
In turn, Service Contract is expressed in the form of agreed policies that include invocation/communication, behavioural ( functional and non-functional) and environmental ( execution contexts and dispute resolution) policies.
 
 
I am asking for the agreement because I have started to interpret SOA service as an entity which is accessible via interfaces but can produce real world effect not necessary visible through the interface, i.e. the service has its body or instance. That is, Service Interaction is not only a space between consumer's call point and service's interface receiver point, it is also the service body execution. Interesting that SOA RM has dual definition of execution context but we use only one. In particular, in one place RM says:
"551 In support of the dynamics of interacting with services are a set of concepts that are about

552 services themselves. These are the service description, the execution context of the service and

553 the contracts and policies that relate to services and service participants."

while in another place it talks about "the execution context of a service interaction" as of the communication channel only.

Kind regards,

Michael Poulin

Senior Solution Architect, EMF Solution Management

Fidelity Investments International

' +44-173-783-6038
* michael.poulin@uk.fid-intl.com 
@    
http://www.fidelity.co.uk/

Important: Fidelity Investments International (Reg. No.1448245), Fidelity Investment Services Limited (Reg. No. 2016555), Fidelity Pensions Management (Reg. No. 2015142) and Financial Administration Services Limited (Reg. No. 1629709, a Fidelity Group company) are all registered in England and Wales, are authorised and regulated in the UK by the Financial Services Authority and have their registered offices at Oakhill House, 130 Tonbridge Road, Hildenborough, Tonbridge, Kent TN11 9DZ. Tel 01732 361144. Fidelity only gives information on products and does not give investment advice to private clients based on individual circumstances. Any comments or statements made are not necessarily those of Fidelity. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any computer. All e-mails sent from or to Fidelity may be subject to our monitoring procedures. Direct link to Fidelity’s website - http://www.fidelity-international.com/world/index.html


From: Jeffrey A. Estefan [mailto:jeffrey.a.estefan@jpl.nasa.gov]
Sent: 04 April 2008 21:52
To: soa-rm-ra@lists.oasis-open.org
Subject: [soa-rm-ra] [SOA-RA] Feedback and recomments on SD

Ken (and RA editors),
 
Below are my recommendations and comments on the Service Description Model based on Wed's discussion:
 
1. Please drop Fig. 20 (Service Interface Model) from Section 4.1.1.2.1.
 
2. Work with Danny to update Fig. 21 (the Service Reachability Model).  It is currently not correct in many ways.  For example,
a) there shouldn't be and aggregate between Service Reachability and Protocols without Endpoint being involved, b) there should be a the named association between Action and Message to be a named association called "denotes" with the arrow going from Message to Action, c) there should be a new class called "Bindings" or "Protocol Bindings" and draw a named association between this new class and the Endpoint class labeled "maps to", and d) there is no association between Service Reachability and Service Interface and there needs to be.   Of course, the supporting text would also need to be updated.
 
3. May seem extreme, but I recommend dropping ALL of the material described in Sections 4.1.2.2 through 4.1.2.2.3 as well as Fig. 25, which is incorrect.   That material is very verbose, overly complex, and introduces a number of additional concepts (both dynamic and static) centered around action that weren't even suggested in the RM; further, it is not consistent with how we define and use action (more specifically, joint action) in the other models (Business via Services View and Interacting with Services Model).  Finally, while there is a great deal of elaboration around Action, there is no mention of Event.  I would encourage all editors and other active participants in the RA to weigh in on this portion of the Service Description write-up so that we can put this to bed soon.
 
Cheers...
 
 - Jeff


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]