[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, From your comments, it appears you are completely missing the forest due to focusing on the trees. The whole point of section 3 of the RAF is that it ties the IT stuff to the business stuff. The problem we are trying to solve is IT taking on a life of its own and ignoring the larger world of the business that it has to fit in and support. The ecosystem viewpoint is where we focus specifically on aligning the IT with the business. Note that the RAF is not giving guidance into how to realize an ecosystem, or own an ecosystem, but rather how to realize (and own) a SOA-based system within the realities of the larger ecosystem that was identified in the ecosystem viewpoint. So … sections 4 and 5 are appropriately scoped. One other thing that seems to be a continuing problem - I think your fundamental understanding of the term “service” is different than the OASIS SOA RM understanding. The RAF needs to be true to the RM, and uses the definition in the RM. The RM specifically and explicitly limits itself to the domain of software architecture: While service-orientation may be a popular concept found in a broad variety of applications, this reference model focuses on the field of software architecture. The concepts and relationships described may apply to other "service" environments; however, this specification makes no attempt to completely account for use outside of the software domain. And, consistent with this limitation defines the service as: A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. A service is provided by an entity – the service provider – for use by others, but the eventual consumers of the service may not be known to the service provider and may demonstrate uses of the service beyond the scope originally conceived by the provider. A service is accessed by means of a service interface (see Section 3.3.1.4), where the interface comprises the specifics of how to access the underlying capabilities. There are no constraints on what constitutes the underlying capability or how access is implemented by the service provider. Thus, the service could carry out its described functionality through one or more automated and/or manual processes that themselves could invoke other available services. A service is opaque in that its implementation is typically hidden from the service consumer except for (1) the information and behavior models exposed through the service interface and (2) the information required by service consumers to determine whether a given service is appropriate for their needs. The consequence of invoking a service is a realization of one or more real world effects (see Section 3.2.3). These effects may include: 1. information returned in response to a request for that information, 2. a change to the shared state of defined entities, or 3. some combination of (1) and (2). Note, the service consumer in (1) does not typically know how the information is generated, e.g. whether it is extracted from a database or generated dynamically; in (2), it does not typically know how the state change is effected. The service concept above emphasizes a distinction between a capability that represents some functionality created to address a need and the point of access where that capability is brought to bear in the context of SOA. It is assumed that capabilities exist outside of SOA. In actual use, maintaining this distinction may not be critical (i.e. the service may be talked about in terms of being the capability) but the separation is pertinent in terms of a clear expression of the nature of SOA and the value it provides. This is the definition, and we don’t need to re-define it in the RAF. Again, the ecosystem viewpoint is intended to help align this more directly with the business. My impression is that you are coming into this with a different understanding/definition of “service” than what is in the RM. Your definition/understanding may be ok …. For you, but the RAF needs to be consistent with the RM. Note that trying to get to a “GOD” definition of “service” is a losing battle. It’s not that one definition is the “right” one and all others are wrong. Instead, we need to accept that there are different uses and definitions of the term (along with associated differences in semantics), and both communicate to others as well as understand amongst ourselves that the RAF is using the definition and limitations spelled out in the RM. From those definitions and limitations, the RAF makes sense, and is getting at the stuff you are trying to point out. 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? >>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: 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” Also, further definition of Actor: >> 723 Actor 724 An actor is a person participant or automated agentdelegate capable of action 725 within a SOA-based system. << allows only technical Actors if SOA-based system is IT thing only. I strongly disagree with this approach: Actor may be not necessary a technical agent. 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, a Participant cannot be a natural/human person “in the SOA-based system” 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. What has happened with the definition of the service constructed by Ken, Boris and me?! 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. << 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 Again, singular interface for SOA service is unacceptable wording: 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. 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 Web www.peterfbrown.com 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]