I have a few words to say about the last Gregg's comment. 1) "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." I think that one task is substituted by another one here: it does not matter that the "entity executing some set of ordered steps" in RPC manner because at this point you are talking about the receiving entity and its steps that unrelated to the sending entity. The sending entity does not know and cares about the receiving enity, which can come up or not; this is certainly a non-RPC 'interaction' style (because the entities do not interact with each other).
2) where "two messages" came from in between "sending the message" vs "consumption and action"? Two messages may be considered if we preliminary agreed that the consuming side always responds which is not true, i.e. there may be only one message in the "sending the message" vs "consumption and action" 3) "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. " What justifies the statement: "Because those two checks happen in the same "process""? As we know, MOM is not transaction transparent. This is why EJB MDB has only sub-set of transaction states availble to its prototype - Session Bean. Again, sender and receiver in asynchronous model do not need to know about each other and not obliged to exchange (send-AND-receive) the message; this is why IBM has changed its MQ description from guaranteed to assured delivery. My conclusion: if we talk about architectural RPC style, it requires both sides of the interaction to be present and willing-and-capable to interact, i.e. exchange a message. Otherwise, this is not a RPC style. - Michael ________________________________ From: Gregg Wonderly <[email protected]> To: [email protected] Sent: Mon, February 1, 2010 3:32:46 PM Subject: 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. Gregg Wonderly [email protected] wrote: > 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. > > Rgds > Ashley > > > 2010/1/26 Harm Smit <[email protected] <mailto:harm.smit%40neuf.fr>> > > > >> > >> > >> De : > >> [email protected] > <mailto:service-orientated-architecture%40yahoogroups.com><service-orientated-architecture%40yahoogroups.com> > >> [mailto:[email protected] > <mailto:service-orientated-architecture%40yahoogroups.com><service-orientated-architecture%40yahoogroups.com>] > >> De la part de Gregg > >> Wonderly > >> Envoyé : dimanche 24 janvier 2010 04:41 > >> > >> À : > >> [email protected] > <mailto:service-orientated-architecture%40yahoogroups.com><service-orientated-architecture%40yahoogroups.com> > >> 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 > that > > 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 > your > > 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 > >> > >> > >> > > > > ------------------------------------ Yahoo! Groups Links
