Gosh, Steve. It's impossible to tell from your reply whether you agree with me or not! I hope you don't talk to your clients like this :-)
> Its physics. In my view, it's mathematics. Rgds Ashley Steve Jones wrote: > > > > > Actually that is an NP complete problem unless you introduce another > set of elements (namely locks) as if at point T1 both A and B look to > send messages then its impossible to prevent them without A or B first > requesting a lock (which gets you into the possibility of a livelock > as you'd have to add compensations for the scenario where both A and B > request locks at the same time). > > > ALL computing exchanges are fundamentally at the lowest level async, > its just that some approaches BLOCK until they get a response which > turns their behaviour into APPEARING as sync. > > > Its physics. > > Steve > > > > 2010/1/27 <[email protected] > <mailto:[email protected]>> > > > > 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] <mailto:harm.smit%40neuf.fr>> > > > >> > >> > >> De : > >> [email protected] > > <mailto:service-orientated-architecture%40yahoogroups.com><service-orientated-architecture%40yahoogroups.com > <http://40yahoogroups.com>> > >> [mailto:[email protected] > > <mailto:service-orientated-architecture%40yahoogroups.com><service-orientated-architecture%40yahoogroups.com > <http://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 > <http://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 <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: [email protected] [email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
