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

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

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


Subject: Re: [soa-rm] Re: [soa-rm-ra] SOA-RAF Editors' Draft 17 Jan 2011; somesuggestions and recommentations for action


Peter, here are my answers. I'll try to be as concrete as possible.

To your request " [Peter:] Can you explain?": ">>Although a SOA-based system is essentailly an
597 IT concern, it is nonetheless a system engineered deliberately to be able to function in a
598 SOA ecosystem. 
In the meeting we have agreed that SOA-based system is not en essential IT concern, it is the concern of the entire enterprise, i.e. it is the essential concern of the business as well. I mentioned 'a compromise' because I could interpret service in old definition as a business thing as well as an IT thing (though RM said it is about SW, in RAF we have to extend this scope to the ecosystem with business manual services or service parts).

To your "[Peter:] Not at all " - my comment is based on the statement that "a SOA-based system is essentailly an IT concern", which we discussed alredy.

To "[Peter:] The text in 1067-1069 took Boris’ definition,", I am not sure but Boris' definition might be not the one we agreed with Ken before. Again, I am not sure and I cannot check this out now. Please, verify it.

To " but I think it is correct to say that a (single) interaction is with a (singular) interface, no?" Well, in majority of cases, YES. However, there are known cases where the requester asks to respond via different communication channel or via different end-point. Example: in messaging the response may be requested to go via specified message destination, which may belong to different interface...

To "[Peter:] I don’t necessarily disagree with you but I’ve been editing based on input. It would have been helpful to have had this a few weeks ago. L" I think I started with this several weeks ago but, probably, did not write in these exact words. Sorry ("nobody is perfect")

Finally, have you accepted my comments about 'Contract'? 


After recent message exchange, I think that "Service Activity
1210 Service activity is the coordinated set of actions involving the efforts of two or
1211 more actors to achieve a real world effect" is incorrect IF RWE is ONLY PUBLIC thing. Service Activity returns Result to the service internally and, then, the Result may be transmitted back to the consumer in private. There may be no public visibility into the Service Activity. HOWEVER, if we accept that RWE is not only public but includes the change of the World that is consumed privately, we may be fine with this definition as it is now. 

Thank you for your attention to these comments.

- Michael

-----Original Message-----
From: Peter F Brown <peter@peterfbrown.com>
To: mpoulin@usa.com; soa-rm-ra@lists.oasis-open.org; soa-rm@lists.oasis-open.org
Sent: Wed, Jan 19, 2011 9:32 pm
Subject: RE: [soa-rm] Re: [soa-rm-ra] SOA-RAF Editors' Draft 17 Jan 2011; some suggestions and recommentations for action

Michael:
Some quick responses inline below
 
Best regards,
Peter
From: mpoulin@usa.com [mailto:mpoulin@usa.com]
Sent: Wednesday, 19 January, 2011 05:04
To: peter@peterfbrown.com; soa-rm-ra@lists.oasis-open.org; soa-rm@lists.oasis-open.org
Subject: [soa-rm] Re: [soa-rm-ra] SOA-RAF Editors' Draft 17 Jan 2011; some suggestions and recommentations for action
 
Actually. I had a chance to read through the proposed changes (though not with 1005 of attention, unfortunately).  So far, I have found quite a few places where I cannot agree with the statements presented. I consider these issues important and list them with the context and proposals below ( with a slight hope somebody would read them):
 
>>1.4.2 System ViewRealization of a SOA Ecosystem viewpoint
289 This viewpoint focuses on the infrastructure elements that are needed to support the
290 construction of SOA-based systems. From this viewpoint, we are concerned with the
291 application of well-understood technologies available to system architects to realize the
292 SOA vision of managing systems and services that cross ownership boundaries.
293 The stakeholders are essentially anyone involved in designing, constructing and
294 deploying a SOA-based system.<<
 
This view gives only one-side perspective from technology standpoint. If SOA is in Business and Technology, where is the business part of Realization of a SOA Ecosystem?
[Peter:] I think Chris has addressed this. We maybe need some clearer wording, I don’t disagree,
 
 
>>Although a SOA-based system is essentailly an
597 IT concern, it is nonetheless a system engineered deliberately to be able to function in a
598 SOA ecosystem. In this context, a service is the mechanism that brings a SOA-based system capability together with stakeholder needs in the wider
599 ecosystem. This is
600 explored in more detail in Section 3.2.2 below. <<
This statement about the service totally compromises prior global definition of service: [Peter:] Can you explain? I don’t see this at all
 
services as ―the mechanism by which
577 needs and capabilities are brought together…. The role of a service in
584 the SOA context is to enable effective business solutions in a distributed environment.
585 SOA is thus a paradigm that guides the identification, design, and implementation of
586 such services.
This locks the door for Business SOA and for SOA in Business (and cuts off all my daily work from this standard). Thus, I propose different text for this fragment:
Although a SOA-based system originated from Technology, it is nonetheless a system structured and engineered in both business and technical parts to be able to function in a
598 SOA ecosystem. In this context, a service is the mechanism that brings a SOA-based system capabilities together with stakeholder and consumer needs in the wider
599 ecosystem
[Peter:] I have no problem with your wording changes, although I may express it slightly differently
 
Also, further definition of Actor:
>> 723 Actor
724 An actor is a participant or delegate capable of action
725 within a SOA-based system. <<
allows only technical Actors if SOA-based system is IT thing only.
[Peter:] Not at all – how do you make that conclusion? It states “participant or delegate” – participant is always a person
 
I strongly disagree with this approach: Actor may be not necessary a technical agent. [Peter:] Agree I’ve thought we have passed this issue long time ago.
Similar problem exists with:
>>Participant
A participant is a person10 730 who is both a stakeholder in the SOA ecosystem and
731 an actor in the SOA-based system. <<
-      if SOA-based system is IT thing only ( [Peter:] it isn’t!) , a Participant cannot be a natural/human person “in the SOA-based system
[Peter:] A SOA-based system has human actors (operators, users, etc), we say that – maybe not clearly enough…
 
In another place, service definition is modified afain in different way than we discussed before. The offered text is:
>> Service is therefore the
1068 implementation of such business functionality and accessible through a defined
1069 interface. <<
The text that, IMO, is more accurate is (implementation differs from realisation in that the latter does not catty technical connotation that obviously and leaves the room for manual implementation):
Service is therefore the
1068 realisation of such business functionality and accessible through a defined
1069 interfaces.
If we use ‘interface’ in the singular form, this sends a message that the service may have only on interface, which is incorrect.
[Peter:] I think that you are right on this, thanks – that was included in the ‘raw definition’ that I used at the end of today’s call
 
 
What has happened with the definition of the service constructed by Ken, Boris and me?!
[Peter:] The text in 1067-1069 took Boris’ definition, suitably cleaned up. With the single comment above (replace implementation with realisation – which I agree with), we have captured what you have argued for. We need to check the rest of the doc for any other uses or definitions that contradict this.
 
Next group o comments for the fragment:
>> The idea of a service in a SOA ecosystem combines business functionality with
1075 implementation, including the artifacts needed and made available as IT resources.
1076 From the perspective of software developers, a SOA service enables the use of
1077 capabilities in an IT context. For the consumer, the service (combining business
1078 functionality and implementation) produces intended real world effects. They are not
1079 concerned with the underlying artifacts which make that delivery possible.<<
Propose: “The idea of a service in a SOA ecosystem combines business functionality with
1075 realisation…, including the artifacts needed and made available as IT resources.– see my comments above regarding ‘realisation’. Again, SOA anchored to IT – this is wrong. We have to change out mindset regarding this issue.
Also, the statement is not accurate: >> For the consumer, the service (combining business
1078 functionality and implementation) produces intended real world effects <<  because even in IT the RWE may be not intended and consumer of the service/RWE may be not the one who requested the service (if we stick with that the RWE is only shared/public service result). That is, the text may be like this: “For the consumers, the service (combining business
1078 functionality and realisation) produces intended real world effects
 
(―I want to but that
1082 book)           è        (―I want to buy that
1082 book)
 
I disagree with the definition of Capability:
>> Capability
1107 A capability is an action or set of actions real-world effect that a service provider
1108 is able to provide execute in order to provide a real world effect that responds to
1109 a service consumer‘s need. <<
[Peter:] Syntactically this is a dreadfully crafted phrase – Capability is a something that someone is able to execute in order to provide a something that responds to a something – UGLY, I agree…but it doesn’t say that a capability is an action! ;-)
Capability is not an action but ability to produce particular result. Result is more than a RWE because one part of it may be private and returned to the requester only. Also, the result/RWE is provided by Service not by Service Provider. Again, if RWE is shared and public only, it may be responding to the service consumer needs. Example: a program asks a service to store a credit card information in the database. Result of this is returned confirmation while RWE is the information in the database which may be stolen by an intruder (another consumer of the service’s RWE), which does not fit with the program needs
[Peter:] I don’t necessarily disagree with you but I’ve been editing based on input. It would have been helpful to have had this a few weeks ago. L
 
Again, singular interface for SOA service is unacceptable wording:
[Peter:] The standard for standards definitions and modelling is always to use the singular unless it is manifestly incorrect. We accept that any implementation can and may have several interfaces and interactions, but I think it is correct to say that a (single) interaction is with a (singular) interface, no?
1113 3.2.2 Services Reflecting Business
1114 The SOA paradigm often emphasizes the prescribed interfaces through which service
1115 interactions are  is accomplished. While this enables predictable integrations in the sense of
1116 traditional software development, the prescribed interfaces alone does not guarantee that
1117 services will be composable into business solutions.
 
Change in the definition – actions vs. interactions:
>>< Business solution
1119 A business solution is a set of defined inter actions that combine implemented
1120 or notional business functionality in order to address a set of business needs. <
 
Inherited problem: initially we considered that everything a service results in is RWE. Now, we say that only shared/public part of the service results is RWE. In this case, the definition of Service Activity is incorrect. Service Activity must satisfy consumer first and return requested results, if the will be a RWE, it is OK too but Service Actions are about producing results to be returned first of all while RWE is a possible companion.If you disagree with this interpretation, we have to return previous meaning of RWE as everything produces by service including private and non-shared results. :-) 
Service Activity
1210 Service activity is the coordinated set of actions involving the efforts of two or
1211 more actors to achieve a real world effect. It is the activity in which participants
1212 deliver a service or a part thereof.
 
Final comment about Policies and Contracts: in the section 3.3.6 Policies and Contracts, the Contracts are practically absent. I propose to add following statements:
 
· Agreements Contract are constraints 1504 agreed to
o Contracts often need to be enforced by mechanisms of the social structure
· Contracts have owners
o The right to establish contracts is an aspect of both service provider and service consumers.
· Contracts may not be different from one another
o Contracts are private matters if otherwise is not agreed by both service provider and service consumer. Stored contract have to be protected to preserve confidentiality and integrity
 
 
In 2011, it does not make sense producing another technical SOA standard that does not look further than IT. IT is already isolated and SOA is the only hope to restore the trust between IT and Business. 
[Peter:] This message is clear and needs to be clearer in the text.
 
Thank you for your time,
- Michael
-----Original Message-----
From: Peter F Brown <peter@peterfbrown.com>
To: soa-rm-ra@lists.oasis-open.org; soa-rm@lists.oasis-open.org
Sent: Wed, Jan 19, 2011 4:57 am
Subject: [soa-rm-ra] SOA-RAF Editors' Draft 17 Jan 2011; some suggestions and recommentations for action
Dear all:
After last week’s SC meeting and a further round of discussions on several issues and concepts, we now have a new editors’ draft, uploaded at:
 
It is sent without any expectation that members will have time to go through it before the morning’s SC meeting! ;-)
 
However…
-          It does not incorporate edits to sections 4 or 5, except some minor ones from the section 3 editors (alignment of terms, etc). I would hope that the next revision will pull in all the other edits done by the other section editors;
-          There is still “connective tissue” missing – because we have chopped away at many orphan phrases and re-arranged parts to flow more logically, there is still an effort to be made in providing wording that helps the reader move from idea to idea more easily – I plan to work on this early next week;
-          We took on the task of changing ‘communicative action’ to ‘communication’ and changing ‘service action’ to ‘action’. This didn’t map easily and threw up some additional issues:
o   We weren’t happy with such a loaded word as ‘action’ being used in such a clearly defined context within a system. To express that concept, we have used the term ‘service activity’. In doing so, the more ‘atomic’ level of action is lost in a more general activity. This may still work. If not, I would suggest we roll back to ‘service action’ and use ‘action’ where appropriate.
o   he Critical Success Factors section and may need to be revisited, as it too uses the term ‘action’;
o   We occasionally use ‘activity’ generically, which is OK in our context but given that it has been defined to death in other specifications, we may need to be careful;
o   Communication is something going on in the ecosystem (and the system), whereas service activity is only system-level. But, we never define system; and service activity is defined only late on in section 3. We may need to address these further and make a clear definition of system;
-          We have replaced ‘joint action’ with either ‘interaction’ or ‘service activity’ where appropriate;
-          Further modelling needs to be done on several diagrams, while other diagrams are being proposed for deletion, either because the terms are now no longer used or defined, or because the diagrams offer no visual benefit.
 
I have already spotted some other minor issues myself, going through the draft again, and will obviously collect feedback and comments again for another round and editors’ draft.
 
I will also send shortly a table that compares the terms that are defined (along with their respective definitions) in the 28 July draft compared with this 17 Jan 2011 draft.
 
What I would like to propose is:
-          Discussion tomorrow on a possible timetable to adoption by the SC and the full TC, and in this direction, identify what remains to be done; milestones and timing;
-          Indication as to whether we are moving in the right direction and particularly major concerns that members feel have not yet been addressed;
-          Time permitting, have a brief discussion on the definitions comparisons, to see if anything jumps out as requiring immediate attention;
-          If we can finalise the remaining work within a couple more weeks of SC meetings, that we hold an “out-of-cycle” full TC meeting within the next few weeks in order to adopt the SC draft as a full new TC draft for public review – tactically, I don’t think we should wait until the next regular three-monthly meeting in April…
 
All the best,
Peter
 
Peter F Brown
Independent Consultant
Transforming our Relationships with Information Technologies
Web         www.peterfbrown.com
Blog          pensivepeter.wordpress.com
Twitter     @pensivepeter
P.O. Box 49719, Los Angeles, CA 90049, USA
Tel: +1.310.694.2278
Tel: +1.310.694.2278
 


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