Everything is a distributed object
Locked
12
12
Everything is a distributed object
 
|
Hello all,
I've seen various attempts to add distributed computing capabilities on top of an existing language. For a true distributed system I would expect it to be possible to instantiate objects of a remote class or to subclass a remote class and other stuff like this. My impression is that those things are difficult when built on top of an existing language. Since the paradigm "everything is an object" pays so well, I thought it might be less painful to implement a distributed system from ground up, starting with the paradigm: "everything is a distributed object". Maybe languages like Erlang and E get close to this paradigm. Other than those I am not aware of any attempts to implement distributed computhing in this way (from ground up). Are you aware of any ? As a sidenote: I have difficulties to understand how Smalltalk works, especially the way method calls eventually resolve to primitive calls. I'd be most grateful for an explanation the other way round, i.e. starting with the primitives and the way the entire system builds up from them. |
Re: Everything is a distributed object
|
|
Spring was one, from a different era... http://research.sun.com/features/tenyears/volcd/papers/mitchell.htm > Hello all, > > I've seen various attempts to add distributed computing > capabilities on top of > an existing language. For a true distributed system I would expect > it to be > possible to instantiate objects of a remote class or to subclass a > remote > class and other stuff like this. My impression is that those things > are > difficult when built on top of an existing language. > > Since the paradigm "everything is an object" pays so well, I > thought it might > be less painful to implement a distributed system from ground up, > starting > with the paradigm: "everything is a distributed object". Maybe > languages like > Erlang and E get close to this paradigm. Other than those I am not > aware of > any attempts to implement distributed computhing in this way (from > ground > up). > > Are you aware of any ? > > As a sidenote: I have difficulties to understand how Smalltalk works, > especially the way method calls eventually resolve to primitive > calls. I'd be > most grateful for an explanation the other way round, i.e. starting > with the > primitives and the way the entire system builds up from them. > > > |
RE: Everything is a distributed object
|
|
In reply to this post by Martin Drautzburg
You need to be very careful with this kind of thinking. A remote object is
VERY different from a local object. You can make very different guarantees about a local object. When communicating with a remote object you need to deal with communications delays, failures and so on. What happens when your method send works but the result message does not make it back? What happens when the delay to the remote object is 1/10th of a second? Or 1 second? The idea that remote communications can be transparent is what has killed almost every distributed computing effort to date. The one thing that the web services people got right is that you need to know when you are talking to a remote object and handle that differently than those in memory. Any other approach produces toys or failures. That said, a dynamic language like Smalltalk or Ruby makes this much easier to do well. You can have a proxy for a remote object that also has added behavior that allows you to deal with the communications issues, or add transactionality to the interaction, etc. I think there is an opportunity to define a new languge that has transactional semantics in memory as a way to deal with both remote communications and concurrency. But, transparency is not useful. As in your example you would not want to have a superclass on another machine and have that result in communications to the other machine every time you check for implementors of a method for a method send. Being able to reference a class from another addres space and have it migrate or clone into your address space might be useful and having language support for manipulating and accessing objects/classes in multiple address spaces might be interesting as well. Michael > -----Original Message----- > From: [hidden email] [mailto:squeak-dev- > [hidden email]] On Behalf Of Martin Drautzburg > Sent: Saturday, October 07, 2006 12:41 PM > To: The general-purpose Squeak developers list > Subject: Everything is a distributed object > > Hello all, > > I've seen various attempts to add distributed computing capabilities on > top of > an existing language. For a true distributed system I would expect it to > be > possible to instantiate objects of a remote class or to subclass a remote > class and other stuff like this. My impression is that those things are > difficult when built on top of an existing language. > > Since the paradigm "everything is an object" pays so well, I thought it > might > be less painful to implement a distributed system from ground up, starting > with the paradigm: "everything is a distributed object". Maybe languages > like > Erlang and E get close to this paradigm. Other than those I am not aware > of > any attempts to implement distributed computhing in this way (from ground > up). > > Are you aware of any ? > > As a sidenote: I have difficulties to understand how Smalltalk works, > especially the way method calls eventually resolve to primitive calls. I'd > be > most grateful for an explanation the other way round, i.e. starting with > the > primitives and the way the entire system builds up from them. > > |
Re: Everything is a distributed object
|
|
Isn't Croquet such an animal?
|
Re: Everything is a distributed object
|
|
In reply to this post by Martin Drautzburg
At 9:41 PM +0200 10/7/06, Martin Drautzburg wrote:
>Hello all, > >I've seen various attempts to add distributed computing capabilities on top of >an existing language. For a true distributed system I would expect it to be >possible to instantiate objects of a remote class or to subclass a remote >class and other stuff like this. My impression is that those things are >difficult when built on top of an existing language. > >Since the paradigm "everything is an object" pays so well, I thought it might >be less painful to implement a distributed system from ground up, starting >with the paradigm: "everything is a distributed object". Maybe languages like >Erlang and E get close to this paradigm. Other than those I am not aware of >any attempts to implement distributed computhing in this way (from ground >up). > >Are you aware of any ? Jini...no, it's not about networked toasters (that's a misconception due to lame marketing by Sun). Jini <http://java.sun.com/developer/technicalArticles/Interviews/waldo_qa.html> <http://java.sun.com/developer/products/jini/index.jsp> Javaspaces (a Jini service) <http://java.sun.com/developer/technicalArticles/tools/JavaSpaces/index.html> I would love to have a Smalltalk analog for Jini. For me that would be a "killer tool" for distributed systems solutions. -- ---------------------------------------------------------------------- Anthony Anton 3800 243rd Place SE Phone: 425-313-1024 Issaquah, WA 98029 Cell: 425-444-3084 Concept Systems [hidden email] FAX: 425-313-1024 |
re: Everything is a distributed object
|
|
In reply to this post by Martin Drautzburg
> For a true distributed system I would expect it to be possible to > instantiate objects of a remote class or to subclass a remote class > and other stuff like this. Spoon[1] can do that. The situation where I've found behavior like that most useful is when debugging a process that has some contexts on the local machine, and some on remote machines. -C [1] http://netjam.org/spoon -- Craig Latta http://netjam.org/resume |
re: Everything is a distributed object
|
|
In reply to this post by Martin Drautzburg
Martin,
Re tranparency of remote objects: it is a great idea if not taken too far. Remote objects are different from local ones. In particular, they are slower and vastly less reliable than their local counterparts. With that said, there is nothing wrong with an ORB that tries to make them as transparent as possible, as long as you realize that you will have to work to avoid punishing your user over timeouts and lost connections. ========================== As a sidenote: I have difficulties to understand how Smalltalk works, especially the way method calls eventually resolve to primitive calls. I'd be most grateful for an explanation the other way round, i.e. starting with the primitives and the way the entire system builds up from them. ========================== IMHO, (if you have not already done so) you should learn how to use Smalltalk before you try to engineer complicated proxies or turn yourself into a VM hacker, etc. In short though, look at Object>>at:. Note the call to primitive 60, and the code below it. If the primitive succeeds, that's it; the Smalltalk code below it is used only if the primitive fails. The idea is that primitives handle the simple and frequent, and the more flexible Smalltalk code can be used for the rare and the complicated. For a better explanation, see the end of the chapter on the graphics kernel in Goldberg and Robson (aka "the purple book" or, if you are lucky, "the blue book"[*]). With that said, I strongly believe that you should be comfortable solving problems and/or developing software in Smalltalk before you read the blue/purple book. You will get more out of it, and be in a better position to realize just how far PARC was ahead of the pack. Bill [*] the blue book simply has some VM specific chapters that were omitted on subsequent printings. The latter/purple form was easy to get when I was so motivated several years ago. Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [hidden email] Tel: (352) 846-1285 FAX: (352) 392-7029 |
Re: Everything is a distributed object
|
|
In reply to this post by Michael Latta
On Saturday, 7. October 2006 21:34, Michael Latta wrote:
> The one thing > that the web services people got right is that you need to know when you > are talking to a remote object and handle that differently than those in > memory. Any other approach produces toys or failures. Thats bad news. maybe I shoud explain why I want to know this. This issue is not strictly sqeuak related, it is just that a lot of smart people are on this list. We are currently in the situation where we need to support a larger user base of apx. 500 users. Our current application includes a fat client, a J2EE business logic layer and a databse backend. There are two main problems: (1) The client is too slow over a slow network (this is mostly our fault) (2) We need 500+ client installations and we need to repeat those 500+ installations with every upgrade of the client. Of course (2) can be attacked with clever remote installation mechanisms like java web start, and this is certainly an option, but I thought there might be a more elegant solution. This idea is to install a "browser" on the users machine just once, a browser that can display about every possible application. With this approach I can see two obvious solutions: (2a) Use a web browser and develop a web app. This has the drawback, that the possibilities you have to design your GUI are very limited and that you have to program things in strange ways. (2b) Use an X11 server on the user's machine. This eliminates the drawbacks of (2a), but is expensive memory-wise. With every session the application has to be started anew on the central machine. An experiment with a wxPython app showed that this can easily be 30MB of (non-shared) memory which adds up to 15GB for 500 users. Another problem with this approach is that window repaints are sometimes visible, which looks irritating to most users, even if the overall time it takes is quite small. The good thing here is (contrary to what you said): you do not have to know when you are talking to a remote object. Then I was looking at "pyrc" a remote python thingy, that promises transparent access to remote objects. So I thought: cool, I let the server (the user's machine) import the wxwidgets toolkit and I remote-control it from the client. So the client will not even have to import the wx toolkit (reducing memory footprint) and the client programmer can write the client code as usual. But alas, an ubiquitous pattern in GUI development is subclassing widget classes from the toolkit. This does NOT work with pyrc. Generally speaking I would need a protocol (other than http) that intercepts - somewhere below the X11 level and communicates higher level objects (not just rectangles and events-in-a-rectangle), to eliminat the drawbacks of (2b) - and above the database protocol (SQLNET) because that will result in a fat client again. |
Re: Everything is a distributed object
|
|
In reply to this post by Martin Drautzburg
Am Samstag, 7. Oktober 2006 21:41 schrieb Martin Drautzburg:
> As a sidenote: I have difficulties to understand how Smalltalk works, > especially the way method calls eventually resolve to primitive calls. Take this method in Object for example: Object>>basicAt: index put: value "Primitive. Assumes receiver is indexable. Store the second argument value in the indexable element of the receiver indicated by index. Fail if the index is not an Integer or is out of bounds. Or fail if the value is not of the right type for this kind of collection. Answer the value that was stored. Essential. Do not override in a subclass. See Object documentation whatIsAPrimitive." <primitive: 61> index isInteger ifTrue: [(index >= 1 and: [index <= self size]) ifTrue: [self errorImproperStore] ifFalse: [self errorSubscriptBounds: index]]. index isNumber ifTrue: [^self basicAt: index asInteger put: value] ifFalse: [self errorNonIntegerIndex] The thing in the brackets <primitive: 61> is a primitive call. The number 61 tells the VM which primitive to execute. (There are also named primitives which were added later on.) If the primitive succeeds then the method returns. If the primitive fails then the rest of the method is executed, in this case an attempt to recover or give a meaningful failure message. > I'd > be most grateful for an explanation the other way round, i.e. starting with > the primitives and the way the entire system builds up from them. Read http://users.ipa.net/~dwighth/smalltalk/bluebook/bluebook_imp_toc.html for a description of the ST80 virtual machine (the ancestor of the Squeak VM). Regards, Lothar |
|
|
In reply to this post by Martin Drautzburg
>From: Martin Drautzburg <[hidden email]>
>Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: [hidden email] >Subject: Re: Everything is a distributed object >Date: Sun, 8 Oct 2006 11:28:55 +0200 > >(2a) Use a web browser and develop a web app. This has the drawback, that >the >possibilities you have to design your GUI are very limited and that you >have >to program things in strange ways. > I was in the anti "web as a platform" camp for a long time, but today it just makes sense. I have to ask: have you looked deeply into seaside? Using seaside you will be subjected to the visial limitations of HTML, but you won't have to program "in strange ways". The seaside frame work hides the state problems with HTTP. Seaside also will do javascript if asked, so those GUI limitations wont be as bad as you would expect. |
|
|
In reply to this post by Lothar Schenk
Hello all,
I don't know if the maintainers of squeaksource are on this list or not, but I think the site may have been hacked. I tried to click on Marshal's name in the ical project so I could mail him a question and it pops up a javascript box that says "I'm here" over and over as a modal. I had to "end task" my browser to get rid of it. |
Re: problem with squeaksource
|
|
J J schrieb:
> Hello all, > > I don't know if the maintainers of squeaksource are on this list or > not, but I think the site may have been hacked. I tried to click on > Marshal's name in the ical project so I could mail him a question and > it pops up a javascript box that says "I'm here" over and over as a > modal. I had to "end task" my browser to get rid of it. > Verified here, probably the site was not hacked, but Philippe plays a practical joke on the visitors of his SqueakSource page by embedding <script>while(true){alert('it\'s me');}</script> into his description. Visit SqueakSource with javascript disabled, and the problem goes away. And while you're at it, you might ask Philippe whether it was him or somebody else, and politely request that he removes that nonsense. And maybe SqueakSource should filter out <script> tags while we're at it... Cheers, Hans-Martin |
Re: Everything is a distributed object
|
|
In reply to this post by J J-6
On Sunday, 8. October 2006 14:12, J J wrote:
> I was in the anti "web as a platform" camp for a long time, but today it > just makes sense. I have to ask: have you looked deeply into seaside? > Using seaside you will be subjected to the visial limitations of HTML, but > you won't have to program "in strange ways". The seaside frame work hides > the state problems with HTTP. Seaside also will do javascript if asked, so > those GUI limitations wont be as bad as you would expect. Yes, from what I've read Seaside is the most promising solution I have seen. At least they have some advanced concepts which go way beyond string manipulation in order to produce html. The drawback is that Squeak does not support Oracle except through ODBC (and I haven't gotten that to work yet). The more I think of it, the more I think Michael Latta is right: "you need to know when you are talking to a remote object and handle that differently than those in memory". Even if we could implement a shared object memory, that would still not solve all problems. Opening a file that contains a list of filenames already becomes difficult, even though we are only dealing with strings here. This is because for the operating system, a filename is something like an OID, but a remote file reader cannot know this. It will simply return a collection of strings and it takes an extra effort to distinguish between local and remote files. This makes me believe that there is a whole set of problems which are not related to technical issues like network latency, marshalling and the like but are rooted in semantics. Many objects seem to have an inherent "meaning" and it can become very difficult to transport meaning over the network even if we could send bits or even objects without any problems. This is because we have to eventually leave the world where "everything is a distributed object". At this boundary we have an impedance mismatch which will cause problems. This said, I believe this kind of stuff would be much easier if I stop accessing objects outside the "everything is a distributed object" world. This means I should not talk about files and other location-bound resources. From what I know both X11 and SQLNET act in this resticted way. |
RE: Everything is a distributed object
|
|
In reply to this post by Martin Drautzburg
You can certainly design a protocol between your server and client that is
better than raw X11 or raw SQLNet. As you point out that will require you deploy an application to each client. Something like web start is a good way to manage that deployment. As you pointed out the use of X11 to a remote machine is not satisfactory, while locally it is fine. This is one quality of service difference between local and remote access you can not ignore. At a fine-grained programming level things get far worse then flicker very quickly. X11 is relatively efficient and was originally designed to function in that situation. This is not to say remote objects do not work, just that you need to design your application so you know when you are incurring the delays and potential failures of a remote connection. Michael > -----Original Message----- > From: [hidden email] [mailto:squeak-dev- > [hidden email]] On Behalf Of Martin Drautzburg > Sent: Sunday, October 08, 2006 2:29 AM > To: [hidden email] > Subject: Re: Everything is a distributed object > > On Saturday, 7. October 2006 21:34, Michael Latta wrote: > > The one thing > > that the web services people got right is that you need to know when you > > are talking to a remote object and handle that differently than those in > > memory. Any other approach produces toys or failures. > > Thats bad news. maybe I shoud explain why I want to know this. This issue > is > not strictly sqeuak related, it is just that a lot of smart people are on > this list. > > We are currently in the situation where we need to support a larger user > base > of apx. 500 users. Our current application includes a fat client, a J2EE > business logic layer and a databse backend. There are two main problems: > > (1) The client is too slow over a slow network (this is mostly our fault) > (2) We need 500+ client installations and we need to repeat those 500+ > installations with every upgrade of the client. > > Of course (2) can be attacked with clever remote installation mechanisms > like > java web start, and this is certainly an option, but I thought there might > be > a more elegant solution. > > This idea is to install a "browser" on the users machine just once, a > browser > that can display about every possible application. With this approach I > can > see two obvious solutions: > > (2a) Use a web browser and develop a web app. This has the drawback, that > the > possibilities you have to design your GUI are very limited and that you > have > to program things in strange ways. > > (2b) Use an X11 server on the user's machine. This eliminates the > drawbacks of > (2a), but is expensive memory-wise. With every session the application has > to > be started anew on the central machine. An experiment with a wxPython app > showed that this can easily be 30MB of (non-shared) memory which adds up > to > 15GB for 500 users. Another problem with this approach is that window > repaints are sometimes visible, which looks irritating to most users, even > if > the overall time it takes is quite small. The good thing here is (contrary > to > what you said): you do not have to know when you are talking to a remote > object. > > Then I was looking at "pyrc" a remote python thingy, that promises > transparent > access to remote objects. So I thought: cool, I let the server (the user's > machine) import the wxwidgets toolkit and I remote-control it from the > client. So the client will not even have to import the wx toolkit > (reducing > memory footprint) and the client programmer can write the client code as > usual. > > But alas, an ubiquitous pattern in GUI development is subclassing widget > classes from the toolkit. This does NOT work with pyrc. > > Generally speaking I would need a protocol (other than http) that > intercepts > > - somewhere below the X11 level and communicates higher level objects (not > just rectangles and events-in-a-rectangle), to eliminat the drawbacks of > (2b) > > - and above the database protocol (SQLNET) because that will result in a > fat > client again. > > > > > > > > |
Re: Everything is a distributed object
|
|
In reply to this post by Martin Drautzburg
Hi!
Martin Drautzburg <[hidden email]> wrote: > The more I think of it, the more I think Michael Latta is right: "you need to > know when you are talking to a remote object and handle that differently than > those in memory". Even if we could implement a shared object memory, that > would still not solve all problems. The "truth" about transparent networking is a rather "old" one by now. BUT... the shared object memory has already been implemented and used successfully since 1985 in the Smalltalk community IMHO. It is called GemStone. So sure, distributing objects is hard and if you rely on "simplistic" methods like using fine grained RPC (or whatever we can call all these variations on the theme: CORBA, RMI, SOAP, yaddayadda) - then it can get quite nasty. GemStone uses a highly advanced "paged" object memory (about 8k per page IIRC) with typically a page cache process running on each participating node. And then a transactional model on top, similar to how most OODBs work I suppose - like Magma for instance. Distributed over the Internet? No, typically not. But it is still highly distributed and proven successful in quite large systems. And no - it doesn't solve "all problems". :) regards, Göran |
Re: Everything is a distributed object
|
|
In reply to this post by Martin Drautzburg
There may be more to the problem, but what is described by Martin
does not really require a general distributed object solution -- which is fortunate. The situation described is the usual domain of "rich client" architectures (pun often intended). http://www.laszlosystems.com/ http://www.curl.com/ http://en.wikipedia.org/wiki/AJAX [Disclosure: I was Technology Strategist at Curl and have many friends there and at Laszlo. There are other players in this field, too.] On Oct 8, 2006, at 4:28 AM, Martin Drautzburg wrote: > On Saturday, 7. October 2006 21:34, Michael Latta wrote: >> The one thing >> that the web services people got right is that you need to know >> when you >> are talking to a remote object and handle that differently than >> those in >> memory. Any other approach produces toys or failures. > > Thats bad news. maybe I shoud explain why I want to know this. This > issue is > not strictly sqeuak related, it is just that a lot of smart people > are on > this list. > > We are currently in the situation where we need to support a larger > user base > of apx. 500 users. Our current application includes a fat client, a > J2EE > business logic layer and a databse backend. There are two main > problems: > > (1) The client is too slow over a slow network (this is mostly our > fault) > (2) We need 500+ client installations and we need to repeat those 500+ > installations with every upgrade of the client. > > Of course (2) can be attacked with clever remote installation > mechanisms like > java web start, and this is certainly an option, but I thought > there might be > a more elegant solution. > > This idea is to install a "browser" on the users machine just once, > a browser > that can display about every possible application. With this > approach I can > see two obvious solutions: > > (2a) Use a web browser and develop a web app. This has the > drawback, that the > possibilities you have to design your GUI are very limited and that > you have > to program things in strange ways. > > (2b) Use an X11 server on the user's machine. This eliminates the > drawbacks of > (2a), but is expensive memory-wise. With every session the > application has to > be started anew on the central machine. An experiment with a > wxPython app > showed that this can easily be 30MB of (non-shared) memory which > adds up to > 15GB for 500 users. Another problem with this approach is that window > repaints are sometimes visible, which looks irritating to most > users, even if > the overall time it takes is quite small. The good thing here is > (contrary to > what you said): you do not have to know when you are talking to a > remote > object. > > Then I was looking at "pyrc" a remote python thingy, that promises > transparent > access to remote objects. So I thought: cool, I let the server (the > user's > machine) import the wxwidgets toolkit and I remote-control it from the > client. So the client will not even have to import the wx toolkit > (reducing > memory footprint) and the client programmer can write the client > code as > usual. > > But alas, an ubiquitous pattern in GUI development is subclassing > widget > classes from the toolkit. This does NOT work with pyrc. > > Generally speaking I would need a protocol (other than http) that > intercepts > > - somewhere below the X11 level and communicates higher level > objects (not > just rectangles and events-in-a-rectangle), to eliminat the > drawbacks of (2b) > > - and above the database protocol (SQLNET) because that will result > in a fat > client again. > > > > > > > > > > |
RE: Everything is a distributed object
|
|
In reply to this post by Göran Krampe
I would never suggest that distributed computing does not work. In
particular it works much better in a closely located cluster type configuration as GemStone is typically set up. I would not want to use GemStone or any other transparent distribution system over the public internet or other WAN system. Also, if the network starts to have reliability issues GemStone or other transparent systems recover far less successfully than do explicitly distributed systems. A system built of communicating systems can deal with outages and gracefully degrade functions until the connection is again available. Transparent systems generally fail to do this acceptably. Michael > -----Original Message----- > From: [hidden email] [mailto:squeak-dev- > [hidden email]] On Behalf Of [hidden email] > Sent: Sunday, October 08, 2006 11:11 AM > To: The general-purpose Squeak developers list > Subject: Re: Everything is a distributed object > > Hi! > > Martin Drautzburg <[hidden email]> wrote: > > The more I think of it, the more I think Michael Latta is right: "you > need to > > know when you are talking to a remote object and handle that differently > than > > those in memory". Even if we could implement a shared object memory, > that > > would still not solve all problems. > > The "truth" about transparent networking is a rather "old" one by now. > BUT... the shared object memory has already been implemented and used > successfully since 1985 in the Smalltalk community IMHO. It is called > GemStone. > > So sure, distributing objects is hard and if you rely on "simplistic" > methods like using fine grained RPC (or whatever we can call all these > variations on the theme: CORBA, RMI, SOAP, yaddayadda) - then it can get > quite nasty. > > GemStone uses a highly advanced "paged" object memory (about 8k per page > IIRC) with typically a page cache process running on each participating > node. And then a transactional model on top, similar to how most OODBs > work I suppose - like Magma for instance. > > Distributed over the Internet? No, typically not. But it is still highly > distributed and proven successful in quite large systems. > > And no - it doesn't solve "all problems". :) > > regards, Göran |
Re: Everything is a distributed object
|
|
In reply to this post by Martin Drautzburg
Hi.
You could have a look at Oz, which supports distributed computing: http://www.mozart-oz.org Best regards, Micke On 10/7/06, Martin Drautzburg <[hidden email]> wrote: > Hello all, > > I've seen various attempts to add distributed computing capabilities on top of > an existing language. For a true distributed system I would expect it to be > possible to instantiate objects of a remote class or to subclass a remote > class and other stuff like this. My impression is that those things are > difficult when built on top of an existing language. > > Since the paradigm "everything is an object" pays so well, I thought it might > be less painful to implement a distributed system from ground up, starting > with the paradigm: "everything is a distributed object". Maybe languages like > Erlang and E get close to this paradigm. Other than those I am not aware of > any attempts to implement distributed computhing in this way (from ground > up). > > Are you aware of any ? > > As a sidenote: I have difficulties to understand how Smalltalk works, > especially the way method calls eventually resolve to primitive calls. I'd be > most grateful for an explanation the other way round, i.e. starting with the > primitives and the way the entire system builds up from them. > > > > |
Re: Everything is a distributed object
|
|
In reply to this post by Martin Drautzburg
On 10/8/06, Martin Drautzburg <[hidden email]> wrote:
> We are currently in the situation where we need to support a larger user base > of apx. 500 users. Our current application includes a fat client, a J2EE > business logic layer and a databse backend. There are two main problems: Ouch! Using J2EE! It's like a punishment ;) (I've been working with j2ee for more than two years... so know how horrible is to maintain and develop) Some alternatives that comes to my mind: 1. Use Smalltalk ;) St is more comfortable for "rpc", because you can do things like dynamic proxies or "become" that are very difficult or impossible in Java. For commercial projects, GemStone it's a very powerful solution (but a little expensive). With GS you get a distributed object oriented database that solves: remote object execution and persistence at the same time. There are other solutions in Squeak, VW, Dolphin and VAST... but I only have experience in VAST and GemStone... For example at Mercap we are developing an application with VAST and GS that runs unchanged in a local image or using remote objects (we only have to "hide" the small dialect differences between VAST and GS and the transaction handling). The good: A really cool language ;), a 95% transparent "rpc", the other 5% is because you have to take care of the performance and transactions. The bad: May be your development team doesn't know anything about smalltalk and your current application is developed in Java :( I think that a transparent "rpc" framework it's not suitable for a non-reliable, slow network like a WAN 2. Use a web client instead of a fat client You can use web pages with a lot of JavaScript to make a more dynamic client. If the software is going to be used in a intranet you can use Mozilla's XUL to make a more "rich" user interface. The good: Zero installation on the client. Works good on a WAN. The bad: JavaScript is difficult to maintain, and HTTP is stateless, so is more difficult to program the application logic (unless you use Smalltalk and Seaside ;) ) 3. Use ULC (http://www.revasoft.com/) I don't know if it's a good option (I've tried only the ULC goodie in VAST that it's not supported and contains some bugs), but I think that maybe the Java version is more polished. Good and Bad... I can't tell you anything about the Java version of ULC. The VAST version (a Smalltalk server with a Java UI), it is not appropriate for a slow network. I didn't mention WebServices because I think that they aren't a good alternative for this kind of client (fat clients that made a lot of remote calls to the server). In my experience WebServices are slow, and suffers of the same problem as CORBA: it's a "generic" specification (multi-language, multi-platform) hence it's really complex (it's good for interop, but working with them it's a pain in the ass). I hope it helps. Regards, Diego.- |
Re: Everything is a distributed object
|
|
The ULC link that I wrote in the previous mail is outdated... a Google
search gave me this one: http://www.canoo.com/ulc/index.html (I don't know if it's exactly the same framework, but the name and the intention it's the same and the homepage it's up-to-date) On 10/9/06, Diego Fernandez <[hidden email]> wrote: > On 10/8/06, Martin Drautzburg <[hidden email]> wrote: > > We are currently in the situation where we need to support a larger user base > > of apx. 500 users. Our current application includes a fat client, a J2EE > > business logic layer and a databse backend. There are two main problems: > > Ouch! Using J2EE! It's like a punishment ;) (I've been working with > j2ee for more than two years... so know how horrible is to maintain > and develop) > > Some alternatives that comes to my mind: > 1. Use Smalltalk ;) > St is more comfortable for "rpc", because you can do things like > dynamic proxies or "become" that are very difficult or impossible in > Java. > For commercial projects, GemStone it's a very powerful solution (but a > little expensive). With GS you get a distributed object oriented > database that solves: remote object execution and persistence at the > same time. > There are other solutions in Squeak, VW, Dolphin and VAST... but I > only have experience in VAST and GemStone... > For example at Mercap we are developing an application with VAST and > GS that runs unchanged in a local image or using remote objects (we > only have to "hide" the small dialect differences between VAST and GS > and the transaction handling). > > The good: A really cool language ;), a 95% transparent "rpc", the > other 5% is because you have to take care of the performance and > transactions. > > The bad: May be your development team doesn't know anything about > smalltalk and your current application is developed in Java :( > I think that a transparent "rpc" framework it's not suitable for a > non-reliable, slow network like a WAN > > 2. Use a web client instead of a fat client > You can use web pages with a lot of JavaScript to make a more dynamic client. > If the software is going to be used in a intranet you can use > Mozilla's XUL to make a more "rich" user interface. > > The good: Zero installation on the client. Works good on a WAN. > The bad: JavaScript is difficult to maintain, and HTTP is stateless, > so is more difficult to program the application logic (unless you use > Smalltalk and Seaside ;) ) > > 3. Use ULC (http://www.revasoft.com/) > I don't know if it's a good option (I've tried only the ULC goodie in > VAST that it's not supported and contains some bugs), but I think that > maybe the Java version is more polished. > > Good and Bad... I can't tell you anything about the Java version of > ULC. The VAST version (a Smalltalk server with a Java UI), it is not > appropriate for a slow network. > > I didn't mention WebServices because I think that they aren't a good > alternative for this kind of client (fat clients that made a lot of > remote calls to the server). > In my experience WebServices are slow, and suffers of the same > problem as CORBA: it's a "generic" specification (multi-language, > multi-platform) hence it's really complex (it's good for interop, but > working with them it's a pain in the ass). > > I hope it helps. Regards, > Diego.- > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |