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 > > >
