"And finally – conversations where always considered a special case of the service invocation", and this is correct. The most concrete engineering approach is mathematics and it states that converstion has 1 or more interactions; the conversation of 1 interaction is the simplest, primitive case bacause it nulls several aspects that have to have values for the cases of more than one interactions in the conversation (at the end, we are dealing with computer science, I guess).
I do not think that my statement is vague, it is rather service-oriented because it includes scalability as needed. Particularly, if you implement SW for one and only one interaction (traditionally) you will need re-design and rebuild your systen for multiple interactions (conversation), while SO approach does not have such problem.
The much bigger and important question is what the 'authority' of SOA ecosystem and what does mean private vs. public in it. We have had a long discusstion about this and I have not chanmged my opinion because of it: SOA ecosystem is the world, there are no private things unknown to the ecosystem while for the participants some things may be available to only a limited numbers of them. For example: a return from the service is supposed to be visible to the requister only unless otherwise is not explicitly set but this return is totally visible to the ecosystem. THis means thar ANYTHING happening with the services, consumers, providers, and so on are the part of the SOA ecosystem.
If you limit JA to the exchange actions only, JA looses its sense. Here is why: any exchange assumes two actions at least but a responder (service) has only a contractual obligation to respond to the invocation and, as the co-owner of this contract is free to break it in any moment. This means that an invocation is not always must be responeded, i.e. invocation does not trigger JA in all cases. However, if you consider that each invocation includes, at least three actions - the consumer's decision action to invoke the service, the invocation action itself and the service's decision action about what to do with the invocation/request, then we naturally have a JA from the very beginning. I think my understanding of the JA is in line with the definition of JA we are using now.
A few minutes ago, Adobe made a presentation to us about their new offerings and they said (with regard to the CRM and related document management in the Call Centre) that the use of stateful services allowed them to decrease efforts and improve end-user sutisfaction several times because instead of a week of back and force activities without the state (on the end-user side) they were able to manage it in 1 day.
'When in SOA, do as functions do', OO experience is not right in many cases here because the goals and objectives are different now (they are function-oriented). I do agree with you that stateful design looses in performance and scalability to the stateless one but in SOA you have different types of consumers than before.
I have not understood "Implementation of a services as a business process is a design approach allowing to support invocation state in a separate service (business process) to make the majority of services “invocation stateless”." What "the majority of services “invocation stateless" you are talking about? Business process (as a service) keeps its state between invocations of its actions. This service' specific is in that its consumer ( the entity that requests the service in the first place and receives the returns) may simultaneouisly become a service worker, i.e be an action provider for some of the process actions. In this case , the service keeps the state across these working actions. I am not sure we may call the providers of the process actions a process consumer; this is why I call it 'worker'. If several roles of the worker are provided by the same entity, the interinvocation state is indeed offloaded to the process (the client of the action).
It is an open question of what is the proper design. If the criteria of properness is the sutisfaction of business needs today and for some overseen future changes, that the service state (implementation) may be as needed.
- Michael
-----Original Message-----
From: Lublinsky, Boris <boris.lublinsky@navteq.com>
To: mpoulin@usa.com <mpoulin@usa.com>; boris.lublinsky@navteq.com <boris.lublinsky@navteq.com>; rex.brooks@ncoic.org <rex.brooks@ncoic.org>; jeffrey.a.estefan@jpl.nasa.gov <jeffrey.a.estefan@jpl.nasa.gov>
Cc: soa-rm-ra@lists.oasis-open.org <soa-rm-ra@lists.oasis-open.org>
Sent: Tue, Mar 15, 2011 1:06 pm
Subject: RE: [soa-rm-ra] RE: One-pager
Lets clarify a couple of things.
I am distinguishing service state from the invocation state. The former always exists and is a representation of the real world conditions. The second, on another hand is the ability of service to keep state of interactions with a particular consumer – a BAD design practice. It was proved bad many times, see for example stateful session beans, which were once considered a state of the art. When will we finally learn our lesson and stop reinventing a square wheel in hope that this time it will actually roll better than a round one.
Implementation of a services as a business process is a design approach allowing to support invocation state in a separate service (business process) to make the majority of services “invocation stateless”. It is the same principle of offloading state management to a client – in this case business process.
Services are intersection of business and IT and both concerns have to be accommodated in a proper design.
Now the phrase “JA is always more than conversation because it includes all internal actions and activities on both sides…” is way too vague. We are engineers – not writers, so we need to be very specific. Can you give very specific examples what exactly this means? More specifically, I consider all internal actions (for both consumer and provider) to be internal and thus irrelevant to the ecosystem. So I do not see how they can be part of externally visible JA.
And finally – conversations where always considered a special case of the service invocation, not vice versa as you are trying to explain.
I have two answers, Boris:
1) I distiguish between JA and conversation: JA is always more than conversation becasye it includes all intornal actions and activities on both sides in addition to the exchnage scenario.
2) the simplest case of conversation is 1 request - 1 response. In this sense, conversation always present in the JA. According to the SO Principle that I call (http://www.ebizq.net/blogs/service_oriented/2009/02/principles_of_service_orientation_reviewed.php) Service State Management principle (initially known as Service Statelessness) - any service has to minimize resource consumption by deferring the management of state information when necessary . This clearly states that the service has to maintain it state and be stateless or stateful when necessary for the business task while the "scalability and often performance" are the IT problems (if you have them, compensate ithem by other means). Example: all business services that are implemented as business processes or orchestrations are stateful; theis type of services dominates the field of services in the business area of SOA ecosystem.
P.S. If you say that stateful services are not welcome in IT because of the complexity of the task, I would say that this is the reality, this is the new requirements to the automation and, thus, new solutions might needed for scalability and performances. Technology may replace business and run its own rules; if the business is not replaced, technology must provide for the business 'operational pattern', IMO.
In your definition you effectively equate JA with conversations.
· Joint action is really a conversation?
· All service invocations are conversational?
If this is the position I have a big problem with this. Conversational means state management which pushes complexity through the roof and typically kills scalability and often performance.
Not sure I agree with Rex (if I've understood correctly).
Joint Action is about actions, not about spiritual preparation to act. That is, any JA has its life-time and, correspondingly, the epoch. An ensemble of actions, which we also call session, completes, the JA completes. Since neither consumer-requester nor the service can define when RWE of the JA will be consumed (if at all) but unknown consumers (the shareable part of the RWE), we cannot tie the JA to any demobilization moment; the service may be retired already and destroyed while the RWE it produces before may be still in the public access area.
So, I agree with Chris - every JA has its epoch. We should not mix it with multiple service requests that result in the JA that can exist simultaneously. Any new request results in its own JA as well as in the new instance of the service responding to it (again, the epoch of JA may be called a session, a business transaction, or somehow else. This 'thing' defines which actions are the part of particular JA and which ones belong to about JA for the same service)
I think that attempting to restrict or constrain the epoch of Joint Action to any arbitrary time-period, especially post invocation, is a problem. in my view, Joint Action is required any time more than one party is required to move a service toward invocation or toward completion once invoked. It stretches from design time to demobilization. Therefore, it does not fit into any specific epoch.
Cheers,
Rex
On 3/11/11 4:05 PM, Estefan, Jeff A (3100) wrote:
First, this RAF definition of RWE is quite a bit different from what it was defined in the RM, which really seemed focused on what happens upon service invocation.
Second, execution context is not mentioned at all in Sect 3 of the RAF or at least not in earlier drafts. How is that going to play out in the new updates?
Still having a hard time with Joint Action, in particular, determining its epoch.
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.
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]