Re: [service-orientated-architecture] Steve on RPC
- The simple issue is that the use of the term RPC (perhaps RPC-like would make it
less implementation like) is still being taken as an "implementation" rather
than an "architectural" mechanism. The introduction of asynchronous behaviors
doesn't change the fact that at some point, that asynchronous action would be
requested by an entity executing some set of ordered steps. It's that
underlying order that this is all about. You need to confine your thought
processes, during architectural design, to order sets of operations so that you
are burdened by that process, to think about what it will take to make these
types of synchronizations happen in a distributed system.
Some other thoughts...
The issue of separating the "sending the message" vs "consumption and action" is
the "architectural" consideration. There are lots of ways to do this, but the
exclusive nature of the two messages implies that a synchronization point
exists, not necessarily that a synchronous messaging mechanism is necessary.
A 2PC based transactional control might be appropriate, but the send and receive
of the message could very much be asynchronous with other operations in the
system. You might then just code the synchronization step into the send section
of the system on both ends to check to see if the other message has been
received before sending.
You'd then also need to use a second synchronization point at the point of
"acting" on the received message to not process the message if you've sent your
message. Because those two checks happen in the same "process", it would be
very easy to make the synchronization work exactly as needed. If both messages
are in flight at the same time, then both sides would choose to not act on what
they have received, because they've sent a message. This is where transactional
mechanisms work out as a better solution than lots of logical checks.
If time considerations are important, you could do that check as well to decide
who actually sent a message first, perhaps. But, time based synchronization is
hardly ever a good thing in a distributed system, because of clock granularity.
You can still write RPC-like interface details, and put the appropriate
description of the constraints. Adding transactions into the mix doesn't
present a change in what needs to be done. It's just one way that you can
manage some types of interactions that have distributed sychronization needs.
> I haven't followed this thread particularly closely, so this remark may
> not be pertinent. But here goes anyway.
> There is a formal difference between synchronous (RPC type) and
> asynchronous communication that can be illustrated as follows:
> Suppose that you have two entities A and B, and suppose you require that:
> Either A sends message x to B or B sends message y to A, but not both.
> Then you *must* use synchronous communication between A and B. The
> requirement cannot be realized if the communication is asynchronous.
> This makes the two forms of communication logically different,
> independently of how they are implemented.
> > 2010/1/26 Harm Smit <harm.smit@... <mailto:harm.smit%40neuf.fr>>
> >> De :
> >> firstname.lastname@example.org
> >> [mailto:email@example.com
> >> De la part de Gregg
> >> Wonderly
> >> Envoyé : dimanche 24 janvier 2010 04:41
> >> À :
> >> firstname.lastname@example.org
> >> Objet : Re: [service-orientated-architecture] Steve on RPC
> >> Harm Smit wrote:
> >> >
> >> > Steve,
> >> >
> >> > It seems to me that what this discussion boils down to is that
> >> >
> >> > - Your reasoning is exclusively aimed at a top-level
> >> > “conceptual” description of a given problem
> >> >
> >> > - This description is essentially verbal, it cannot be modelled
> >> > rigorously
> >> >
> >> > - You term “implementation” everything beyond this conceptual
> >> > level, including what is usually called “design”
> >> >
> >> > - At this conceptual level, you express every form of
> >> > interaction as an RPC
> >> >
> >> > This terminology is pretty personal (hence some mutual
> >> > misunderstandings), and your use of the term RPC is misleading (not
> >> only
> >> > to me) and IMO inappropriate, given the general acceptation of this
> >> > concept at the “implementation” level.
> >> The term RPC, hopefully means "I pass something to this other, remote
> >> entity",
> >> and "I get back a result of 'passing the something'". If you think
> >> anything
> >> else about what "RPC" means, than you are putting some kind of
> >> implementation
> >> detail into the process and that's breaking out of the abstraction.
> >> [HS] Hopefully? As illustrated by other messages on this list, I'm
> >> clearly
> >> not alone in thinking that this is *not* the usual acceptation of the
> >> term
> >> RPC. Unless I missed something prior to that, the Remote Procedure Call
> >> paradigm was introduced in the early 1980s by Apollo Computer, the first
> >> workstation vendor, later acquired by HP. It allowed calling a procedure
> >> without having to be aware of whether that procedure was executed on the
> >> same or on another networked machine.
> > I call a method... I pass in parameters, if the return isn't void I get
> > something back.
> >> No more, no less! RPC was carried over
> >> into OSF's DCE, OMG's CORBA and Microsoft's COM/DCOM. Being
> >> indistinguishible from an ordinary procedure call, an RPC is by
> >> definition
> >> synchronous, whether or not the result is void. Thus, RPC is obviously
> >> an
> >> implementation-level concept and generations of people have grown up
> >> with
> >> this understanding. So if you now take it to just mean "passing
> >> something
> >> to
> >> a remote entity", you are creating undue confusion. Again, I would
> >> designate
> >> that 'something' as a message, IMO a much more neutral term.
> > If we want to get picky an RPC call does exactly what you are saying, it
> > fires messages across sockets and gets responses it only HIDES the async
> > from the end user. If there is a void return then (depending on the
> > implementation) it may actually not wait for a response to return. If its
> > a
> > local call then the assembler code does something similar.
> > So the _abstraction_ of RPC is even in the old Apollo's with their quirky
> > "pads" (IIRC from when I used them) rather than windows actually just
> > an abstraction over the underlying implementation.
> >> > Apart from that, your conceptual level is **way** apart from what
> >> Gregg
> >> > was initially referring to and where this whole thread started from:
> >> he
> >> > said that **developers** should be **designing** services as RPC
> >> > interfaces, etc.; obviously, his approach (with which I clearly
> >> > disagree) is not at the conceptual level.
> > What other type of interfaces would you design? Note here that Gregg said
> > INTERFACE not IMPLEMENTATION, if you DESIGN the interface as RPC then you
> > can still choose to implement it anyway you want. As an example you could
> > design an RPC style interface and then choose to use SOAP over JMS for
> > your
> > implementation.
> >> The developers of a service are THE architects of the inner-workings of
> >> the
> >> software. It is exactly these people that make or break portability,
> >> adaptability and usability of the systems.
> >> [HS] Agreed, but your architects are not the same as Steve's, as the
> >> latter
> >> are in no way concerned with inner workings. Here you're talking about
> >> the
> >> HOW, Steve said he's only talking about the WHAT.
> >> If you don't see this as a "fact", then I'm not sure how else to stress
> >> how
> >> I feel with regard to my assertion of
> >> the importance of "abstacting interactions to RPC."
> >> Steve, I believe is just moving up the stack to the system architecture
> >> level,
> >> which I had already thought was usually modeled with the thought of "do
> >> this
> >> next" as a basic principle of modeling. "Do this next" is very much an
> >> "RPC"
> >> mechanism. If you are modeling an SOA, then you are dealing with
> >> services
> >> and
> >> users, and each has a role at some point that is trivially (at least for
> >> me)
> >> modeled as one of those entities handing something to another entity and
> >> finding
> >> out "how that went" or "what the result was".
> >> [HS] All this is fine to me, except that the term RPC is a red herring
> >> in
> >> this conceptual context, as explained above. That's about all there is
> >> to
> >> this discussion: confusion due to inappropriate terminology!
> > But the confusion is because you are jumping from the INTERFACE into the
> > IMPLEMENTATION of a service. In the same way as a .h file says nothing
> > about how the code works so an INTERFACE design doesn't have to force
> > implementation to work in a specific way but acts as a consistent
> > reference
> > against which the interface is measured.
> > Steve
> >> Harm.
> >> I'm trying really hard to understand how abstracting away details using
> >> a
> >> simple
> >> concept is so hard.
> >> Gregg Wonderly
> >> ------------------------------------
> >> Yahoo! Groups Links
- Yes, carefully crafted transaction mgmt protocols may simply processing, especially in a inter-organisational setting, with a single point of control.However in a multi party situation with some level of distrust, the game still change. The common sense idea of "reach the desk" still applies, even in a situation where one party has a poorly executing system. The key is the balance of risk, who is responsible of case of failure? In most B2B scenarios parties does not like to assume the risk of others.Its also discouraging that most (business) SOA design disciplines don't incorporate the balance (and cost) of risk./anders w. tellOn Apr 6, 2010, at 11:57 PM, Gregg Wonderly wrote:
Anders Tell wrote:
> In a legally relevant transaction- protocol there are more end states to
> consider such as dispute. So technically protocols and solution can be
> improved to be more business like an handle more scenarios.
One the things that can happen, is that transaction participants can be added
that can check the things that are unimportant to the IT infrastructure, but
necessary for the business case. By using transaction participants, you avoid
layering logic in various places, and instead, you can provide a pluggable API
in a software system which can allow additional logic to be implemented by
simply adding more participants that can "vote" on the validity of what is
The use of transactional agreement is often viewed as a problematic step to take
but, in the end, you'll end up writing transaction structured code for these
kinds of things anyway. Jini provides a simple to use transactional model and
because it standardized and setting at your finger tips, it's easy to just do it
and thus guarantee the sanity of the operation.
Yes, software can have bugs, and a transaction participant may not be
implemented correctly. But this is no different than any other bit of software.
One must test and demonstrate fitness of the system at the appropriate level.