From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,1eef1e815cf70416 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.234.38 with SMTP id ub6mr7984995pbc.2.1339190815488; Fri, 08 Jun 2012 14:26:55 -0700 (PDT) Path: l9ni29895pbj.0!nntp.google.com!news2.google.com!postnews.google.com!6g2000vbv.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Distributed Systems Annex, data sharing between programs Date: Fri, 8 Jun 2012 14:26:55 -0700 (PDT) Organization: http://groups.google.com Message-ID: <0d661453-423c-484b-90cd-4e80ffe1db5b@6g2000vbv.googlegroups.com> References: <8055acf5-188f-4b34-b4f0-83d70fee54f8@googlegroups.com> <96feb838-e0d3-4d06-abf0-79a8e74b5746@e20g2000vbm.googlegroups.com> <54af7ad7-7268-4d84-bafa-542e380a58f6@n16g2000vbn.googlegroups.com> NNTP-Posting-Host: 83.3.40.82 Mime-Version: 1.0 X-Trace: posting.google.com 1339190815 25347 127.0.0.1 (8 Jun 2012 21:26:55 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 8 Jun 2012 21:26:55 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: 6g2000vbv.googlegroups.com; posting-host=83.3.40.82; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20100101 Firefox/12.0,gzip(gfe) Content-Type: text/plain; charset=ISO-8859-1 Date: 2012-06-08T14:26:55-07:00 List-Id: On 8 Cze, 04:11, Shark8 wrote: > Could you give examples of what sorts of tasks are better-suited/easier in DSA and YAMI4? Pascal already provided example where DSA is attractive due to its integration with the language. Note the pattern: Ada is a synchronous sequential[*] language, so if your distributed problem is of the same nature, then the DSA solution will look natural. [*] this means that your problem can be described as a sequence of steps where each step has to finish before the next step begins. Now, the contrary example. You have a system with several thousand machines and you want to send them new configuration or something. You know the locations of those systems, but the little problem is that with this scale some of them are not working at all, some are hanging and some are overloaded and therefore process everything very slowly. And you cannot do much about it. And you have to send them the new data within very short time frame. How short? Let's say several seconds. The synchronous-sequental solution has a loop over the targets and a remote call of the kind that Pascal has shown. This does not work. It would not work even if all the targets were in a perfect shape. A naive extension of this solution involves creating some tasks to make things go in parallel. This is bad design, as the parallelism already exists in huge amounts - remember, there are thousands of machines over there, right? So why do we have to create tasks locally, if the parallel resources are elsewhere? OK, let's shove this conceptual issue under the carpet, but then - how many tasks should we create? This is where DSA (or CORBA or ICE or similar solutions from the same paradigm) proves to be actually very low-level instead of high-level and forces us to think in terms that are very distant from the actual problem at hand. The solution is to stop thinking in terms of RPC (remote procesure calls), and start thinking in terms of messages. If you lift the concept of the message to the level of a design entity (yes, distribution is *not* transparent and it *cannot* be an afterthought), then some cool things are possible - just create thousands of messages and let them go. No need to create additional tasks and no need to wait for consecutive steps, as everything can happen in parallel naturally. The original problem becomes feasible even in the presence of partial failures, because separate message do not have to see their delays and their individual communication problems. Another example of this paradigm shift is a trading system, where you want to inform all interested participants about a price change. Say, there is a new price of the IBM share and you want to send it to everybody. The difference from the above example is that this time you don't really care (and therefore don't need to know) who is interested. But you still have to publish this data somehow. The DSA (CORBA/ICE/etc.) solution is lots of coding. Lots of low-level code that has very little connection to the original, high-level problem ("publish new price"). The messaging system allows to solve it differently, exactly thanks to the fact that a message becomes a design-level entity. Create a new message and give it to the broker - he will take care of it. Hey, if the message is a first-class entity, then you might try to do even more funny things with it - why not store it? Why not "record" the stream of messages and "replay" them later? Why not attach some security-related stuff to it, like digital signatures or access control lists? Or maybe route tracing? This is just the tip of the iceberg. YAMI4 is a messaging system, where the programmer deals with messages. This is the fundamental difference from DSA, where the programmer deals with calls. Ironically, the lack of language integration is both a disadvantage and a big advantage of messaging systems - the advantage being that if there is no integration, then the language rules do not limit what you can do. More here: http://www.inspirel.com/articles/RPC_vs_Messaging.html Also, in the last section titled "Message-oriented middleware": http://www.inspirel.com/articles/Types_Of_Middleware.html -- Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com