Hi Steve > 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.
My example is about the semantics of synchronous versus asynchronous communication as (for instance) in the difference between synchronous and asynchronous CCS (Robin Milner's process algebra). If you use locks, you can simulate (or implement) synchronous semantics using an underlying asynchronous mechanism. If you use the right access disciplines, you can implement a stack using an array. But you wouldn't use this to claim that stacks and arrays have the same semantics. Rgds Ashley Steve Jones wrote: > > > > > > On 28 January 2010 10:02, Ashley at Metamaxim > <[email protected] <mailto:[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]> > > <mailto:[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:[email protected]> <mailto:harm.smit%40neuf.fr > <mailto:harm.smit%2540neuf.fr>>> > > > > > >> > > >> > > >> De : > > >> [email protected] > <mailto:[email protected]> > > <mailto:service-orientated-architecture%40yahoogroups.com > > <mailto:service-orientated-architecture%2540yahoogroups.com>><service-orientated-architecture%40yahoogroups.com > <http://40yahoogroups.com> > > <http://40yahoogroups.com <http://40yahoogroups.com>>> > > >> [mailto:[email protected] > <mailto:[email protected]> > > <mailto:service-orientated-architecture%40yahoogroups.com > > <mailto:service-orientated-architecture%2540yahoogroups.com>><service-orientated-architecture%40yahoogroups.com > <http://40yahoogroups.com> > > <http://40yahoogroups.com <http://40yahoogroups.com>>>] > > > > >> De la part de Gregg > > >> Wonderly > > >> Envoyé : dimanche 24 janvier 2010 04:41 > > >> > > >> À : > > >> [email protected] > <mailto:[email protected]> > > <mailto:service-orientated-architecture%40yahoogroups.com > > <mailto:service-orientated-architecture%2540yahoogroups.com>><service-orientated-architecture%40yahoogroups.com > <http://40yahoogroups.com> > > <http://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 > > > <http://groups.yahoo.com/group/service-orientated-architecture/join> > (Yahoo! ID required) > > [email protected] > <mailto:[email protected]> > > > > > ------------------------------------ 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/
