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]> > > > 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] <harm.smit%40neuf.fr>> > > > >> > >> > >> De : > >> [email protected]<service-orientated-architecture%40yahoogroups.com> > <service-orientated-architecture%40yahoogroups.com> > >> [mailto:[email protected]<service-orientated-architecture%40yahoogroups.com> > <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> > <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 > >> > >> > >> > > > > >
