[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; some suggestions and recommentations for action
Michael: Some quick responses inline below Best regards, Peter From: mpoulin@usa.com [mailto:mpoulin@usa.com] 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 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 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 (―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 1116 traditional software development, the prescribed interfaces alone do 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 i 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: · 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----- 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 Blog pensivepeter.wordpress.com LinkedIn www.linkedin.com/in/pensivepeter 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]