[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. From: mpoulin@usa.com
[mailto:mpoulin@usa.com] 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. - Michael 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. -----Original Message----- In your definition you effectively equate JA with conversations. Does it mean that: · 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. From: mpoulin@usa.com [mailto:mpoulin@usa.com] 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) - Michael -----Original Message----- 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. Chris, Couple of comments: 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. Cheers… - Jeff 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]