On 28 January 2010 10:02, Ashley at Metamaxim <[email protected]>wrote:
> 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 :-) > What I'm saying is that your example which tries to put a block on a 2-way distributed communication is not a sync/async issue its a different problem set entirely. You have a locking requirement rather than a blocking requirement. > > > Its physics. > > In my view, it's mathematics. > Well arguably everything is but in this case I was refering to the point that the exchange of information between two non-tied particles cannot be instantaneous. Bit poncy I'll give you ;) Steve > > 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<harm.smit%2540neuf.fr> > >> > > > > > >> > > >> > > >> De : > > >> [email protected] > > > > <mailto:service-orientated-architecture%40yahoogroups.com<service-orientated-architecture%2540yahoogroups.com> > ><service-orientated-architecture%40yahoogroups.com > > <http://40yahoogroups.com>> > > >> [mailto:[email protected] > > > > <mailto:service-orientated-architecture%40yahoogroups.com<service-orientated-architecture%2540yahoogroups.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%2540yahoogroups.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 > > > >
