[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm-ra] responses to Michael suggestions [was: [soa-rm-ra] revised section 4.3]
----- Original Message -----
From: Lublinsky, Boris
Sent: 01/23/12 02:06 PM
To: Ken Laskey, 'Mike Poulin', soa-rm-ra@lists.oasis-open.org
Subject: RE: [soa-rm-ra] responses to Michael suggestions [was: [soa-rm-ra] revised section 4.3]
See inline to inline
From: soa-rm-ra@lists.oasis-open.org [mailto:soa-rm-ra@lists.oasis-open.org] On Behalf Of Ken Laskey
Sent: Sunday, January 22, 2012 12:20 PM
To: 'Mike Poulin'; soa-rm-ra@lists.oasis-open.org
Cc: jeffrey.a.estefan@jpl.nasa.gov; 'Thornton, Danny R (IS)'; ellis@deccs.com
Subject: [soa-rm-ra] responses to Michael suggestions [was: [soa-rm-ra] revised section 4.3]
see inline [KJL]
Michael was the only one who specifically responded to the edits to section 4.3. If there are no further specific suggestions, I will ask for final acceptance during the call on Wednesday.
Ken
From: Mike Poulin [mailto:mpoulin@usa.com]
Sent: Wednesday, January 18, 2012 8:34 AM
To: Ken Laskey; soa-rm-ra@lists.oasis-open.org
Cc: jeffrey.a.estefan@jpl.nasa.gov; Thornton, Danny R (IS); ellis@deccs.com
Subject: Re: [soa-rm-ra] revised section 4.3
1.
I beg you pardon for missing an issue with the diagram "Figure 27- Interaction dependencies" in 4.3.1. This diagram has the same problem with Service INterface and Behavior/Information Models as the diagram in "Figure 14- Service Description": Behavior/Information Models drive and contribute into the definition of the Service Interface, not another way around.
I propose (to Peter? :-) ) to correct both diagrams in sync (or I can send corrected picture w/o the source).
[KJL] Peter has action for consistent suggestions to be clear when talking about thing vs. description of thing. I think it was mentioned by Michael in another email that our experience is people interpret these models as intended, i.e. description, rather than a pure reading out of context.
[MP] I would rather wait for Peter (a small symbol in the diagram can lead to huge mistakes - I dislike it).
2.
Propose a change for:
Services can be composed in a variety of ways, including direct consumer-to-service interaction, by using programming techniques or using an intermediary, such as an orchestration engine leveraging higher level orchestration languages. Such approaches are further elaborated in the following sub-sections.
as
Services can be composed in a variety of ways, including direct consumer-to-service interaction or using an intermediary Actor. In technology, interactions may be realised , by using programming techniques or using an intermediary, such as an orchestration engine leveraging higher level orchestration languages. Such approaches are further elaborated in the following sub-sections.
[KJL] I’m not sure rewording is improvement. I’m open to the opinion of others.
[BL] I am sure it will make things worse. Orchestration engine is an implementation approach, not a new actor.
[MP] The only point I'm trying to make is to say that the conductor may ne a human, not a system/impleentation only. Every UI=business process=user journey works with a human conductor. Actor is the conductor. Orchestation engine/SW is, indeed, implementation detail. This is why I said "In technology"...
3.
Propose a change for
Business Collaboration
Business collaboration is a set of interactions among business participants where each participant agrees to perform activities that in aggregate will produce a required business outcome.
as
Business collaboration is a set of interactions among form of joint work of business participants where each participant agrees to perform interactions and activities that in aggregate will produce a required business outcome.
Reasons: business collaboration is not about interactions but about individual work in encemble with others, which may include interactions.
[KJL] This is where our old friend “joint action” may be useful. Let’s try
Business collaboration is a set of interactions form of joint action among business participants where each participant agrees to perform activities that in aggregate will produce a required business outcome.
I left out “interactions and” from Michael’s suggestion because I don’t know what it mean to “perform interactions”. We could say “agrees to perform activities and engage in interactions” but I’m not sure that is necessary.
[BL] So is orchestration. We are back to the legs vs hands
[MP} to Boris, "Business collaboration is a set of interactions form of joint action" has nothing to do with orchestration IMO.
4.
Propose a change for
Whereas orchestration requires a central controller to execute a predefined business process, service composition can also be accomplished as a simultaneous cooperation between actors without the presence of a central control.
as
Whereas orchestration requires a central controller to execute a predefined business process, service composition can also be accomplished as a simultaneous cooperation between joint work of actors without the presence of a central control.
Reason: cooperation != collaboration; cooperation preserves the rule that participants work "as is" only and coopration task is an additional task to them; collaboration assumes dedication and potential chnages inside the participants. Thus, business_collaboration_ may include service _cooperation_ but not service collaboration (which defeats the purpose of services).
Also, a low popularity of Choreography in services (not in business) is attributed to "business services into collaborative efforts in order to achieve a common business outcome based on collective agreements between participants and with no one in charge over the entire collaboration", i.e. it assumes possible change thap participants try to avoid.
[KJL] Following from above, I would replace “joint work of” in Michael’s suggestion by “set of joint actions among”.
[MP] I used "joint work of" to avoid any of cooperation/collaboration terms
Further, I take not of Michael’s concern that past experience with choreography may have been negative because folks did what sounds a lot more like custom hacking than what we try to describe in the RAF. To address this, consider adding the last sentence to the paragraph that follows the definition:
For choreography, multiple parties collaborate in a peer-style communication as part of some larger business transaction by exchanging messages with trading partners and external organizations (e.g., suppliers). [NEWCOMER/LOMOW] It differs from orchestration primarily in that each party in a business collaboration describes its part in the service interaction. Service-oriented business collaborations do not necessarily imply exposing the entire peer-style business collaboration as a service itself but rather the collaboration uses service-based interchanges. In addition, in the context of the SOA ecosystem, the choreography is ideally a collaborative use of existing services rather than custom changes to services or processes that would create connections that are brittle to future change.
[BL] Oh brother. Now there is a new controversial term here – business transaction, which btw applies to both hands and legs and is another stumble block in the SOA community. There are several competing definitions here as well.
5.
Suggestion:
now it is written: "These ports do not explicitly show service interfaces in order to emphasize that in the example these are not intended to be generally available to any actor in the SOA ecosystem;however, the interfaces should adhere to the principles involved in the composition of services. " (2307-2308)
I understand that this example demonstrate internal dedication o participants to collaborate via syncronising (changing) internal processes. I am OK with this as well with the explanation about "ports". However, the statement "interfaces should adhere to the principles involved in the composition of services" needs a bit more or different wording. We can say that to be used in the SOA Ecosystem, the interactions between commpanies must use services and service interfaces rahter than ports in accordance with the principles involved in the composition of services
[KJL] As I understand Jeff’s intent in this model, he adhered to our guiding principle of parsimony, i.e. don’t always get into all the detail. I prefer we leave the ports somewhat ambiguous and not get into explanations that the original editor did not intend. That said, I’m still open to suggestions for specific tinkering that we can accept, reject, or modify.
[MP] When the text talkes about service interfaces and ports - this is a lot of details altready - I did nopt open this "box". My point is that the interactions between companies must use services instead of _interfaces_ and these services "should adhere to the principles involved in the composition of services". Nobody (it is my experience dictated by convenience of existing consumers) would modify interface for the sake of just anothercomposition of services. This was and is my position about collaboration vs. cooperation: business collaborate by cooperating services
Thanks,
- Michael
P.S. I will not be bale to partiicpate in today meeting, sorry.
----- Original Message -----
From: Ken Laskey
Sent: 01/17/12 12:18 AM
To: soa-rm-ra@lists.oasis-open.org
Subject: [soa-rm-ra] revised section 4.3
I’ve incorporated all adjudicated changes to section 4.3 and attempted to capture consensus in some original material appearing in section 4.3.4 to the end. I am hoping for a continuation of the agreeability over the past few days and everyone will be happy with the changes; at the least, I am hoping for an acceptable balance among everyone’s remaining unhappiness.
Take a look and start the discussion. I’d like nothing better than to have this resolved before Wednesday’s call.
Ken
---------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]