Hi 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]> > >> >> >> De : >> [email protected]<service-orientated-architecture%40yahoogroups.com> >> [mailto:[email protected]<service-orientated-architecture%40yahoogroups.com>] >> De la part de Gregg >> Wonderly >> Envoyé : dimanche 24 janvier 2010 04:41 >> >> À : >> [email protected]<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 >> >> >> >
