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: Re: [soa-rm-ra] Follow-up to 7-5-08 Telecom

To Frank: I agree that service message security unrelates directly to the execution context.
However, your comment is exactly what I do concern of - service message security is NOT ENOUGH to call it 'security in depth'.  Security of the service execution, i.e. service execution (not only communication) context is the 'security in depth' to me.  

To Ken (I believe you beat the circumstances): let me rephrase what I said above  when I talked with different people about execution context (RM), many were sure it was about COMMUNICATION only, i.e. execution context relates to the communication to/from the service interface ONLY. Moreover, that was taken as a conformance that OASIS means SOA Service as the service interface only (classical Web Service concept though it may be CORBA or RMI or DCOM interface). 

How we can clearly demonstrate your interpretation of the services interaction - My interpretation is that THE SERVICE being used is an element of the interaction ?  Do we need a diagram for this? 

With my poor English, interaction is rather a synonym to communication than to communication and service execution. I have walked through all 109 references to interaction in the Public Review Draft 1 and became quite sure that interaction is about communication and invocation only; I have found only 6 places where interaction is clearly interpreted as a service execution, not only as a communication to the service.

Thus, I propose to replace Figure 40 with following diagram (uploaded) and adjust related paragraphs:

1882 For purposes of this SOA Reference Architecture, the authors have committed to the use of message
1883 exchange between service participants to denote actions against the services that cause a real world
1884 effect, and to denote events that report on real world effects that arise from those actions.


1887 A Message denotes either an action or an event. In other words, both actions and events are realized
1888 through messages.

To me, the last sentence is incorrect. Both actions and events may be not REALIZED through messages but INITIATED; the actions and events are realized through the service only.  If accept that actions and events are realized through the message, the service MAY NOT do anything that is not visible through the messages, which is far from reality. The real world effect may be totally invisible through the service messages and interface. Limiting realisation by communication messages is a pure Web Service mentality.  Here is another real-life example.

{A team of quantitative  developers decided to improve calculation of the credit risk and increased calculation accuracy in the formula. They provided calculation results through the Web Service interface and, following its concept, changed the implementation behind the interface with no changes to the interface (including messages). Because of that, they did not inform business users about the change (the communication with the service left exactly the same as it was before). As a result, the business operation was almost put down for a day because well-known credit models started changing their risk categories and confused analysts a lot.}  

Actually, this is another example that service body is equally important to the service communication, and service interaction has clearly state this (following Kens interpretation).

-	Michael

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