De : [email protected] [mailto:[email protected]] De la part de Gregg Wonderly Envoyé : dimanche 24 janvier 2010 04:41 À : [email protected] 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. 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. > 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. 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! Harm. I'm trying really hard to understand how abstracting away details using a simple concept is so hard. Gregg Wonderly ------------------------------------ Yahoo! Groups Links
