On 2 February 2010 09:33, Michael Poulin <[email protected]> wrote: > > > 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. >
As per the OASIS SOA RM, if the two parties can't agree a contract for the interaction then it doesn't exist. So in otherwords you can't have an SOA architecture in which both sides don't want to co-operate. Steve > > - 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<harm.smit%2540neuf.fr> > >> > > > > > >> > > >> > > >> De : > > >> [email protected] > > <mailto:service-orientated-architecture%40yahoogroups.com<service-orientated-architecture%2540yahoogroups.com> > ><service-orientated-architecture%40yahoogroups.com> > > >> [mailto:[email protected] > > <mailto:service-orientated-architecture%40yahoogroups.com<service-orientated-architecture%2540yahoogroups.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%2540yahoogroups.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 > > > > > >
