[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:
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 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]