> > Allowing for distributed processing means that you can > do > > it later. In a Java RMI remoting application, this > means > > that up front, your interfaces include support for > > RemoteException and extend Remote. > > "Allowing for distributed processing" involves much more > than declaring RemoteException on interfaces. It is an > architectural decision, influencing the whole system > design.
This is the fundamental issue that most people gripe about when suddenly remote access is needed. They hate the fact that suddenly they've got to handle RemoteException in places that they did not use to. When you put RemoteException on your business interface methods, it allows you to see places where things get more detailed and need more attention. There are, of course, other things that you need to do for "distributed programming". But, if you really understand how RuntimeException can impact your application unexpectedly, you will have already designed the architecture of your application so that it handles business affecting exceptions correctly.
> > Now, all the software > > that uses those interfaces has to handle them and be > > designed to deal with remoting. > > Handling remote processing adds much complexity to > clients.
Humm, clients are remote aren't they?
> Of course, if you ignore them, or just popup an > alert saying "Remote Exception ocurred, try again later!", > it's pretty simple (and limited, and stupid). Dealing with > remoting includes assuming that calls are not > instantaneous, maybe asynchronous. You may have to show a > progress bar to the client, and let them cancel the > request in the middle of processing (if they get bored). > Also, you have to know when an error is about business or > network. If it is only on a layer boudary, OK, it may be > well encapsulated, but if it is spread through the system, > it is quite troublesome.
There are plenty of ways to badly design an application. If you don't know how to deal with remote access, then, yes, you will have problems. It is something to learn, and something that will, perhaps try your patience. I got a lot of my education in the world of telephone switching systems. But, I also had to learn to use SwingWorker threads in Java based clients that do remote access to a server via RMI.
> > Later, if you need to > > remote, you don't have to rearchitect or redesign the > > system for this. The interface signatures don't > change! > > Er... do you really mean you believe that redesigning is > just changing interfaces?
Hopefully, you've designed your architecture so that the business logic is encapsulted in interfaces that are effective for your application. Then you can in fact use interfaces as your primary documentation. The smart proxy concept will allow you to rearchitect your remoting to various systems so that you can cache, use transactions, etc. All without the application having to deal with those exact details.
This, is not an attempt to hide remote access. It is a way to change how your remoting acts within the system so that the applications using remote access don't have to be changed except for the most drastic circumstances of change in your architecture.
> Excerpt from: Jini Network Technology Fulfilling its > Promise: A Conversation with Jim Waldo
Jim's comments are great! I try and stress the importance of what he says to everyone I talk to about Distributed systems.
Jim doesn't say anywhere that you should build complex distributed systems. He says
The end result is that we make the same mistakes over and over, trying to do what can't be done. But progress happens when practitioners understand the intrinsic difference in programming that the network introduces. We have a long way to go before all of us understand this.
So, if you don't understand what you are doing, you will fail, and if you don't learn, you will fail repeatedly.
Often people that argue about Jini and complexity of distributed systems, don't use phrases or words that tell me they have the experience. Instead, I hear a lot of theory being recited, and links being pointed to.
It's great to have all the theory and concepts under your belt. But, you need to build these systems, and try out the theory to understand the situations that are important. Different domains experience different circumstances more readily than others.
Distributed system designs don't have to be complex. You do have to account for the complexities of distributed system design in distributed systems though.
"This is the fundamental issue that most people gripe about when suddenly remote access is needed. They hate the fact that suddenly they've got to handle RemoteException in places that they did not use to."
Well, that just points out the idiocy of checked exceptions doesn't it? Suppose I've built an application with a solid exception handling scheme with appropriate finally blocks and such in various places. Introducing Runtime exception is quite likely to require a lot of busy work quieting down the compiler or wrapping the exception for zero gain. Nifty.
I think "idiocy" may be a tad too harsh. When Java came out, exception handling was essentially unheard of, especially in the C/C++ world. I think it might be that we've grown past what the original ideas in exception handling are capable of and that what Java enabled earlier now actually stands in the way. Personally, I don't mind. I'm betting that AOP can be used to create exception handling frameworks that process exceptions in conceptual layers rather than the physical layer (the object methods). I'm not sure what the current status is, but I know that Ron Bodkin and Ramnivas Laddad are doing work in this area for the A-Track project on sourceforge.
> Well, that just points out the idiocy of checked > exceptions doesn't it? Suppose I've built an application > with a solid exception handling scheme with appropriate > finally blocks and such in various places.
Well, there is actually a great pattern that JDK 1.4 enabled via Throwable.initCause(). If you've truely dealt with exceptions in your software so that RemoteException handling can be handled by another exceptions processing, then all you need to do is create that delegate exception, and use Throwable.initCause() to tuck the RemoteException into that exception. This will still make exception traces show the RemoteExceptions trace so that you can see (when you need to), what the base cause was.
You have to have some Exception handler though that will do the right thing. If you've missed this, then there will still be extra work to do.
But, if you do enough design of distributed applications, then you will likely learn to deal with this issue from the beginning.
> "State is the second worst thing in distributed > computing. > No state is the worst." --John Ousterhout
From http://www.javaworld.com/javatips/jw-javatip41_p.html This back-and-forth process is definitely more complicated than the other solutions, but it works today across a wide combination of clients and servers. The drawbacks to this process stem from needing to perform multiple HTTP requests to fulfill a single, complete transaction. We must retain "state" information across the multiple requests to be able to keep track of what's going on (recall that HTTP is a stateless request/response protocol). Robustly managing the requisite state information can be quite challenging. As John Ousterhout, the father of the Tcl scripting language and the Sprite distributed operating system, has said: "State is the second worst thing in distributed computing. No, state is the worst."
John, HTTP based web services operations are not the type of distributed computing that this thread is about. Web services do try to provide a way to distribute processing, but in general, web services are used to interface systems that are already distributed because they are different OSes, different processors, different companies, etc. While there is distributed processing going on, the point of the distributed processing is to connect the disjoint systems.
In this thread, we are talking about building systems were distibuting the processing of certain tasks is done, up front, on purpose as part of the design for scaling the system to handle a particular type of load/task. A side effect of distributed systems is that often you can change the cohesive forces of the system more readily because you've already thought about what happens when a resource or operation is not available or fails.
The fact that HTTP doesn't allow the client and the server to have state is an interesting problem. In distributed systems that we are talking about in this thread, the interactions are more rich because Jini uses the RMI programming model. We can send objects and/or remote references to objects back and forth and have the other end manipulate state in a central location with transactional semantics either implicitly or explicitly specified.
This is one of the places where HTTP just doesn't solve the problems that need to be solved for real distributed processing. You can tunnel with HTTP, and heck, you could even right a JERI endpoint implementation that ran over http that provided RMI semantics. But, if both ends do not understand the richer language of the communication, then you are not adding any value.
For distributed applications, it is important to understand what state has to be where. Sometimes, you need to have every thread of execution pass state around, because the calling thread has control of the life-cycle of that state. In other cases, the life-cycle is part of the transaction implied by the calling threads call into a remote object. In that case, state might be created and returned, or state might be created and held for a particular leased interval (including forever).
This is what distributed processing architectures need to take into account. Web services let certain things be passed around by hiding them in URLs or in content of a 'POST' request. The problem is that there are not transactional semantics explicitly specified by the presence of the content. It's always a 'hack' that the implementor decides the semantics and implementation of, and everyone using it has to figure out what's going on by reading through a text specification of the servers URL language etc.
Jini unifies these behaviours and semantics with a more formal specification that is the Java API associated with the distributed objects. This means that the semantics of the operations and explicitly definable. The interfaces used for distributed objects allows the operations to be specified in a way that lets multiple providers coexist. Anytime the definition changes, everyone sees the changes in the interface, and can upgrade/fix/extend as needed.
This makes it possible to make quick changes to APIs with a lot more safety to knowing that all users will be able to use the API correctly.
Subclassing the interface and extending the API allows versioning to occur with new semantics that don't have to do magical things to understand whether they are the old version with a bad parameter or the new version.
There are alot of other issues that define the differentiating factors between web services like APIs over HTTP transport, and Jini/Java, RMI based distributed systems. Maybe others will comment more on this issue.
Thanks for doing some homework. However, please be clear that I used Ousterhout's quote in this thread for a specific purpose that had nothing to do with that Tips & Tricks article and that I certainly didn't reference that article.
> John, HTTP based web services operations are not the type > of distributed computing that this thread is about. Web > services do try to provide a way to distribute processing, > but in general, web services are used to interface systems > that are already distributed because they are different > OSes, different processors, different companies, etc. > While there is distributed processing going on, the point > t of the distributed processing is to connect the disjoint > systems.
The facade put in front of a distributed or decentralized system has nothinga priori to do with the facts of life summarized in Ousterhout's quote.
It is, however, a simple fact that the capabilities of the facade do have a practical effect on how easy it is to manage interaction across the system. In terms of HTTP, as I hope is clear from reading Dr. O's quote, the statelessness is both a good thing and a bad thing and that means that we have to step up and take responsibility for dealing with the myriad tradeoffs.
> This is one of the places where HTTP just doesn't solve > the problems that need to be solved for real distributed > processing. You can tunnel with HTTP, and heck, you could > even right a JERI endpoint implementation that ran over > http that provided RMI semantics. But, if both ends do > not understand the richer language of the communication, > then you are not adding any value.
Indeed, a key issue is the real language of the system rather than just details like the underlying communication substrate. Alas, it's all too clear that many practitioners conflate those two entirely too often.
As for the rest, let me make a couple of comments:
First off, I find it fascinating how much you read into my posting of a very simple quote.
Second, in terms of using HTTP and friends as a substrate for building distributed and decentralized systems, I'll just humbly suggest that you study REST. [And please be clear that I'm not a Restafarian. :-)]
> > From > > http://www.javaworld.com/javatips/jw-javatip41_p.html > > Thanks for doing some homework. However, please be clear > that I used Ousterhout's quote in this thread for a > specific purpose that had nothing to do with that Tips & > Tricks article and that I certainly didn't reference that > article.
There was no other context that I could associate your comment with, as it stood alone. So, I went out on the web to see where the context may have come from. I saw your recent article mentioning the same quote, and chose to draw the conclusion that they were related. Perhaps you can provide the right context so that I and others can understand what your point is with this statement?
> The facade put in front of a distributed or decentralized > system has nothinga priori to do with the > facts of life summarized in Ousterhout's quote.
I guess that I'd have to be in John's head to know that.
> Second, in terms of using HTTP and friends as a substrate > for building distributed and decentralized systems, I'll > just humbly suggest that you study REST. [And please be > clear that I'm not a Restafarian. :-)]
REST first benefits security in a sort of sociological manner. Where RPC protocols try as hard as possible to make the network look as if it is not there, REST requires you to design a network interface in terms of URIs and resources (increasingly XML resources). REST says: "network programming is different than desktop programming -- deal with it!"
Jini clearly specifies the realities of this exact same difference through its use of the RMI programming model. Check the RMI spec. It is RPC with the requirement that you pay attention to failures to make the remote call. The interesting thing about RMI is that it is almost like making RuntimeException a checked exception. In any system using RMI, there is typically some important thread making the call, and you must protect that thread from exceptions that would stop it and dehabilitate the system. RuntimeException is no different for these important threads. You have to catch them too. If you understand this important fact, then the presence of RemoteException will be no additional complication to your application.
If you can't change the API to include a throws clause to declare the presense of the RemoteException explicitly, you will be able to wrap it as the cause of another, applicable exception, until such time that the API can be properly changed to declare the thrown exceptions.
The point of the quote is simple (though certainly not simplistic)... Distributed systems are all about the tradeoffs in dealing with the issues of (distributed) state. Any attempt or belief that there's a canonical, a priori "right" distributed state solution is, by definition, fundamentally and catastrophically flawed.
In extension, any discussion about distributed systems that doesn't recognize the above is, at best, horribly misleading.
> The point of the quote is simple (though certainly not > simplistic)... Distributed systems are all about > the tradeoffs in dealing with the issues of (distributed) > state. Any attempt or belief that there's a canonical, > a priori "right" distributed state solution is, by > definition, fundamentally and catastrophically flawed. > > In extension, any discussion about distributed systems > that doesn't recognize the above is, at best, horribly > misleading.
Great, I am glad to see this additional angle on that text. I agree with your statement here. I was just a little bit lost without more context.
Flat View: This topic has 27 replies
on 2 pages
[
«
|
12
]
Previous Topic
