The Artima Developer Community
Sponsored Link

Weblogs Forum
Re: Opinion: Martin Fowler's First Law of Distribution

27 replies on 2 pages. Most recent reply: May 13, 2004 6:13 PM by Gregg Wonderly

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 27 replies on 2 pages [ 1 2 | » ]
Dale Asberry

Posts: 161
Nickname: bozomind
Registered: Mar, 2004

Re: Opinion: Martin Fowler's First Law of Distribution (View in Weblogs)
Posted: Apr 20, 2004 11:54 AM
Reply to this message Reply
Summary
Dan: Great blog entry - well said and supported. I think the discussion is pointing out some very big reasons why Jini isn't taking off: people don't get distributed computing. They just don't get it.
Advertisement

Here's one comment:

About Dan, he misses the point when he says "This difference in granularity is introduced because of a need to avoid network round trips". That is not the only reason, and (I think) not even the most important for avoiding distribution of objects. Designing distributed systems involves DISTRIBUTED STATE, that can cause a hell of problems and an explosion of complexity. It's not about "saving some bytes" of bandwidth, it is about consistency, simplicity (simplicity as 'avoiding unnecessary complexity'), and productivity.

I've seen this problem before. It's usually the result of writing a lot of code around managing the interactions for remote participants. It results in twisted, incomplete, custom transaction management for each and every type of interaction.

Frankly, one service should not have state dependencies on another service... if there are, why are they different services? Carlos Perez' Loose Coupling Leads to Robustness quotes an interesting paper Crash-Only Software. The interesting point 1 is

  1. Requests are entirely self-describing.

The authors George Candea and Armando Fox explain it to mean:

Requests are entirely self-describing, by making the state and context needed for their processing explicit.

This means to me that any state needed by a service 2 will be included in the request either directly by including it as a request parameter, indirectly through a parameter containing a global reference, or implicitly 3 through some asynchronous mechanism 4.

My practical solution to this is to perform remote method calls, or groups of calls, within a Jini transaction that also contains any and all JavaSpace entries representing service state 5. This buys me consistency in state for all distributed participants AND fault-tolerant fail-over for when a service becomes unavailable.

So, where is the explosion in complexity? I can probably do this with less code than programmers only capable of implementing it in a "local" manner.

[1]the other three points sure do sound like Jini!
[2]external to the service firing off the request.
[3]the processing and context is still explicit, but achieved implicitly through conventions. See [4].
[4]like an entry in a JavaSpace.
[5]for those services that have a long-lived state.


Ronald Tetsuo Miura

Posts: 22
Nickname: ronaldtm
Registered: Jan, 2004

Re: Opinion: Martin Fowler's First Law of Distribution Posted: Apr 20, 2004 12:37 PM
Reply to this message Reply
<i>
Frankly, one service should not have state dependencies on another service... if there are, why are they different services?
</i>

Quoting myself: "Most developers don't know how to write distributed code".

Developers who take Fowler's words as God's, and never make anything distributed are the same who would do everything as remote EJBs otherwise. If all developers could reason about when it is appropriate to make objects distributed, his statement would be just nonsense, but, for most systems, there's no reason to distribute objects, and people keep doing it. KISS!

And quoting myself again:
"I understand that this refers to distributed objects (RPC, CORBA, RMI, EJB), not distributed services or layers (TCP/IP, Databases, browsers)." (please include webservices and JINI to the latter)

As I understand, distributed objects are something like keeping a reference to an object running at a remote location, communicating through the network. Keeping this reference means that you depend on the object's state, that you trust that the same, or an equivalent, object will respond to any call you make. Sometimes, it's just natural to design an object as stateful, and trying to make it stateless may result in even more complexity and delay (you must pass all the information it needs to perform its work).

I do think one should try to keep most services stateless, but when state is needed, distribution should be considered only if there will be some real gain (or, "if in doubt, don't").

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

And of course state copying is free, right? Posted: Apr 20, 2004 2:50 PM
Reply to this message Reply
I don't think so. The fact is, I've seen precious few applications that could be cleanly implemented as "services". The vast majority of them are simply CRUD applications with the db as the sole transactionally aware component. Thus, they used exactly one, rather stateful, service.

Which is fine. The other point being skipped is that it takes work to make an object distributable - it is not free. Not just more coding work (of which there is) but also more rigorous design work to minimize state copying and make interactions more coarse. The fact is, a lot of useful patterns simply don't work efficiently when distributed because their interaction patterns are fairly rich.

Of course, you're talking about services rather than objects (even though you don't come out and say it). Fowler, I think was talking about objects. I think he's right.

Probably the root cause of the unfortunate disconnect you bemoan is the modeling of services as objects. Objects have state (ivars). Services, ideally, don't. Objects without state are just bundles of functions - which is a much better model for a service than a class. I rather suspect that this is the source of much bad design - services are NOT best modeled as objects.

It seems to be Jini week at Artima and there's a "wait - distribution is really good - honest - you just have to use Jini" vibe for some reason. I find this trend to be dangerous - many people will consider you are talking about objects and begin trying to distribute objects willy nilly around the network. I predict a large number of project failures in the wake of this little love-in.

I've been doing distributed apps starting with rpc, home grown orbs, corba, rmi, PDO, DST, OODBMS's and a lot of even more esoteric technologies over the last 12 years. The tradeoffs are invariably the same. Jini isn't fundamentally new or different and doesn't offer any magic solutions to the same old problems. It will require the same level of rigorous design to account for network traffic minimization and network reliability problems.

This additional work is exacerbated in Java because the paradigm is fundamentally function calling oriented rather than message passing. Yet another impedance mismatch.

Anyhow, I'm not buying this week. Application design is work. Distributed application design is more work. There is no magic bullet.

Dan Creswell

Posts: 49
Nickname: dancres
Registered: Apr, 2003

Re: And of course state copying is free, right? Posted: Apr 20, 2004 5:11 PM
Reply to this message Reply
>
> Of course, you're talking about services rather than
> objects (even though you don't come out and say it).
> Fowler, I think was talking about objects. I think he's
> s right.
>
> Probably the root cause of the unfortunate disconnect you
> bemoan is the modeling of services as objects. Objects
> have state (ivars). Services, ideally, don't. Objects
> without state are just bundles of functions - which is a
> much better model for a service than a class. I rather
> suspect that this is the source of much bad design -
> services are NOT best modeled as objects.
>
> It seems to be Jini week at Artima and there's a "wait -
> distribution is really good - honest - you just have to
> use Jini" vibe for some reason. I find this trend to be

I don't see anyone saying distribution is good or that you must use JINI.

People are saying when would you use distribution and how would you use it?

People are saying here's how I might use JINI for whatever and highlighting what they feel to be benefits?

> dangerous - many people will consider you are talking
> about objects and begin trying to distribute objects willy
> nilly around the network. I predict a large number of
> project failures in the wake of this little love-in.
>

And that would be in spite of your earlier statement that this discussion is about services, objects are bad, Fowler is right and the recommendations in the article? Forgive me but I think that's just plain flamebait.

> I've been doing distributed apps starting with rpc, home
> grown orbs, corba, rmi, PDO, DST, OODBMS's and a lot of
> even more esoteric technologies over the last 12 years.
> The tradeoffs are invariably the same. Jini isn't
> t fundamentally new or different and doesn't offer any
> magic solutions to the same old problems. It will require
> the same level of rigorous design to account for network
> traffic minimization and network reliability problems.
>

Not new or different? So leases, join and discovery, lookup by type etc. are all common-place and found everywhere? Perhaps you'd argue that Web Services provides all these things, that's okay but I'd note that JINI was available some time before Web Services.

> This additional work is exacerbated in Java because the
> paradigm is fundamentally function calling oriented rather
> than message passing. Yet another impedance mismatch.
>

Could you clarify: Are you referring to asynchronous processing or something else here? Are you talking about Java the language or Java the platform or something else? How 'bout a counterexample?

> Anyhow, I'm not buying this week. Application design is
> work. Distributed application design is more work. There
> is no magic bullet.

No and nor is there a one size fits all approach and, given changes in environment over time, the approaches you favour today need revising or replacing. This requires that people ask the question "why?" and challenge old knowledge and try thinking in different ways about problems.

Dan Creswell

Posts: 49
Nickname: dancres
Registered: Apr, 2003

Re: And of course state copying is free, right? Posted: Apr 20, 2004 5:28 PM
Reply to this message Reply
>
> Probably the root cause of the unfortunate disconnect you
> bemoan is the modeling of services as objects. Objects
> have state (ivars). Services, ideally, don't. Objects
> without state are just bundles of functions - which is a
> much better model for a service than a class. I rather
> suspect that this is the source of much bad design -
> services are NOT best modeled as objects.
>

Interestingly CORBA and RMI at least, focus on the exporting of interfaces not the exporting of classes and you could use that construct to build either an object or a service kind of thing. The key issue for me here is to provide appropriate advice on the best way to use these things to avoid the kind of pitfalls we've all been discussing and, whilst round-trips and latency are a factor there are lots of other things which might be more important in other situations.

i.e. it's not as simple as objects vs services and roundtrips.

On a somewhat different topic, what would you say about the current interest in Service Oriented Architecture vs the more traditional CRUD apps you've mentioned. Do you, for example, think they'll end up being the same thing?

Dale Asberry

Posts: 161
Nickname: bozomind
Registered: Mar, 2004

Re: And of course state copying is free, right? Posted: Apr 20, 2004 6:12 PM
Reply to this message Reply
Who said that state copying is free? How about some intellectual honesty rather than sarcasm?

>>The fact is, I've seen precious few applications that could be cleanly implemented as "services". The vast majority of them are simply CRUD applications with the db as the sole transactionally aware component. Thus, they used exactly one, rather stateful, service.<<

You live in a very nice world. Most of the applications I've worked on are more than CRUD. They require interaction with disparate servers (multiple databases and types of database, special applications, etc), need to be able to scale to thousands of users affordably, and have to be readily available (95% or more). I have yet to find ANY non-distributed approach that can resolve even only one of those issues.

>>Of course, you're talking about services rather than objects (even though you don't come out and say it). Fowler, I think was talking about objects. I think he's right.<<

I do mean passing objects in a distributed fashion. Fowler, in this case (the three issues I mention above), is wrong.

>>Probably the root cause of the unfortunate disconnect you bemoan is the modeling of services as objects. Objects have state (ivars). Services, ideally, don't. Objects without state are just bundles of functions - which is a much better model for a service than a class. I rather suspect that this is the source of much bad design - services are NOT best modeled as objects.<<

The disconnect that I am "bemoaning" is that distributed state will not necessarily cause "an explosion of complexity". What I stated as the cause is that programmers will write highly dependent, brittle code to manage the interactions between services - in essence writing incomplete transaction managers that are highly specific to each interaction. Hey, I see this kind of baloney even more so in non-distributed code.

>>It seems to be Jini week at Artima<<

If you hadn't noticed, Artima is run by a dedicated member of the Jini community!

>>I predict a large number of project failures in the wake of this little love-in.<<

Again, save me the sarcasm and get back to intellectual honesty. I doubt that anything I say has much impact at all :-)

>>I've been doing distributed apps starting with rpc, home grown orbs, corba, rmi, PDO, DST, OODBMS's and a lot of even more esoteric technologies over the last 12 years<<

That only makes you experienced, not an expert.

>>Jini isn't fundamentally new or different and doesn't offer any magic solutions to the same old problems.<<

Actually, two people that were fundamentally involved with CORBA would disagree with you: Jim Waldo and Ken Arnold. My previous employer and friend, Bob Schlicher, wrote Applying CORBA in the Enterprise (http://developer.netscape.com/viewsource/schlicher_corba.html) for Netscape would also disagree. The reasons "why" Jini is different are not simple and part of the reason why you've been seeing so many Jini related articles.

>>This additional work is exacerbated in Java because the paradigm is fundamentally function calling oriented rather than message passing. Yet another impedance mismatch.<<

I'm not quite sure what this means.

>>Anyhow, I'm not buying this week. Application design is work. Distributed application design is more work. There is no magic bullet.<<

Never claimed that there were any magic bullets. Only that distributed application design isn't really as hard as most people think, and that they need to change their thinking if they are going to be able to move past some of the more pressing complexity problems quickly approaching the horizon.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

OK, Pile on the new guy Posted: Apr 21, 2004 5:11 PM
Reply to this message Reply
You know, the one without a blog doing Jini evangelism. Guess I'm a little far outside your paradigm.

>I don't see anyone saying distribution is good

Three recent blog entries "How to think like a Jinition", "RE: Opinion: Martin Fowler's First Law of Distribution", and "Is Distribution really that bad?" I guess we don't read the same web site.

>People are saying here's how I might use JINI

Which is fine. And that's my cue to say here's why I wouldn't do it that way. Or is the comments part of the site only meant for people who agree with the author?

Oh, and Dale, Experience implies Expertise - there's that common root word. That's the last I'm going to respond to you with that kind of cheap shot taking.

OK, enough sarcasm.

>Not new or different? So leases, join and discovery, lookup by type etc.

Like Java itself, Jini bundles up a bunch of older ideas from other technologies. There have been many lookup/lease/discovery/binding mechansims for all sorts of network resources long before Java, much less Jini.

Incidentally, I'm not a web services fan either. WS standardization effort looks quite a lot like the OMG efforts on CORBA - same learning curve. Soon they'll be adding transactions...

>> function calling oriented rather than message passing.

> Are you referring to asynchronous processing or something else here? Are
> you talking about Java the language or Java the platform or something else?
> How 'bout a counterexample?

Sure. Smalltalk, Ruby, and Objective C are message passing languages. I can send any message to any object at any time. In this way you can think of each object as a tiny server. Its quite possible that the message you send may not be understood by the server - at which point it will perform some default action. That's considered to be inherently OK at all times. In fact, you can do some astonishingly clever things by writing smart default message handlers - like have them wrap up all messages and forward them to another object, or over a network connection. These little servers are truly loosely coupled. The loose coupling makes distributing an object trivial - any object can be distributed simply by publishing it and there's only on proxy class in the system which can proxy any interface.

http://cocoadevcentral.com/articles/000062.php

Above is a link to a basic tutorial. DST (Distributed Smalltalk) worked essentially the same way using the IIOP wire protocol. Compare this with the amount of code to do roughly the same thing in:

http://www.oreilly.com/catalog/jininut/chapter/ch04.html

Man, what a lot of plumbing I have to master just to move a chunk of processing. Why is there so much more code?

Because Java, like C++, is a function calling language - its inconceivable that an object might not implement a function. It enforces this view of the world by requiring you to write interfaces, then using code generation for stubs, which spits out proxy and implementation classes that implement the interface. You end up with one proxy class for every class of distributed object.

This also adds distribution issues WRT to version interfacing BTW. Your client MUST have the appropriate interface (and correct version) at compile time - or you can jump through hoops and use the very un-natural and labor intensive reflection api - but at that point its just way too much work for too little payoff.

Which brings me back to my earlier assertion - distribution is clearly more work for the programmer (in the case of Java - MUCH more), more work for the computer, and may or may not provide you with a great payoff. So do developers not "get it"? Or do they just have more pressing business logic to write and not enough time/motivation to do boiler plate plumbing? I know where I stand on this. Remote interfaces cost more money than local ones and I can usually do without them.

The arguments about half baked exception handling to deal with network reliability is well taken - but I'd argue that the more natrual solution is to have your services participate in transactions and make use of JTA.

Now here's a chance for you to educate me - If I am to use a distributed SOA then I am going to likely require distributed transaction management. Looking at the Jini docs - it looks like Jini has its own transaction manager - does this manager interop with the JTS/DB Transactions I find in my local J2EE server?

Its not at all clear to me but looking at the package names my guess is NO. The are independent mechanisms. In which case they ought not to be mixed. I'd be pleased to hear I'm wrong about this though.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: OK, Pile on the new guy Posted: Apr 21, 2004 9:53 PM
Reply to this message Reply
I've tried to provide substantive information here regarding the questions in the Todd's post. We are trying to understand your position Todd, and your questions and comments do strike some nerves it appears, so the things you are asking and saying are important to clear up.

> Like Java itself, Jini bundles up a bunch of older ideas
> from other technologies. There have been many
> lookup/lease/discovery/binding mechansims for all sorts of
> network resources long before Java, much less Jini.

There are a fundamental set of things about distributed computing that everyone does. There is method/messaging, there is usually a proxy to manage the interface between the application and the network. There can be many levels/layers of API that allow lots of different things to be customized (as is the case with Jini 2.0). So, yes, you see lots of commonality and if you stop there, you won't see the other things that are Jini.

When you've decided to use another language or feature of a platform, have you always been forced to use it due to a business need, or have you been able to play and explore? I am curious where the barrier between you and Jini comes from and what issues are truely detracting.

> Incidentally, I'm not a web services fan either. WS
> standardization effort looks quite a lot like the OMG
> efforts on CORBA - same learning curve. Soon they'll be
> adding transactions...

Web Services will soon be a large, ugly hairball, as opposed to its current unattractiveness...

> Sure. Smalltalk, Ruby, and Objective C are message
> passing languages. I can send any message to any object
> at any time.


public interface MessageReceiver extends Remote {
public Object send( Object msg ) throws RemoteException;
}


> http://cocoadevcentral.com/articles/000062.php
>
> Above is a link to a basic tutorial. DST (Distributed
> Smalltalk) worked essentially the same way using the IIOP
> wire protocol. Compare this with the amount of code to do
> roughly the same thing in:
>
> http://www.oreilly.com/catalog/jininut/chapter/ch04.html
>
> Man, what a lot of plumbing I have to master just to move
> a chunk of processing. Why is there so much more code?

Because they are showing you all the details. The ServiceDiscoveryManager provides 2 statement service lookup.

public class MyMessageSender {
Configuration config;
MessageReceiver recv;
ServiceDiscoveryManager sdm;
public MyMessageSender( Configuration conf ) {
this.config = conf;
sdm = new ServiceDiscoveryManager(
null, null, conf );
}

public Object doWork( String dataMsg ) {
ServiceItem item = (MessageReceiver)sdm.lookup(
new ServiceTemplate( null, new Class[] {
MessageReceiver.class }, null ),
null // no filter needed
);
recv = (MessageReceiver)getProxyPreparar().
prepareProxy( item.service );
return recv.send( dataMsg );
}
}

Frameworks such as my startnow project on jini.org, amongst several other similar concepts make it possible to create service implementations with minimal lines of code, as in:

public class MyService extends PersistantJiniService
implements MessageReceiver {
public MyService( Configuration conf ) {
super(conf);
startService( conf, "My Service", "persist.ser" );
}

public MyService( String args[] ) {
super(args);
startService( "My Service", "persist.ser" );
}

public Object send( Object msg ) {
...
}
}

Doesn't seem like that much code to me.

> Because Java, like C++, is a function calling language -
> its inconceivable that an object might not implement a
> function. It enforces this view of the world by requiring
> you to write interfaces, then using code generation for
> stubs, which spits out proxy and implementation classes
> that implement the interface. You end up with one proxy
> class for every class of distributed object.

JDK1.5 no longer requires rmic. The JERI work in Jini 2.0 also uses dynamic Proxy implementations that remove all the hassles associated with rmic and simple downloaded proxies. And, JERI does this in JDK1.4.

> This also adds distribution issues WRT to version
> interfacing BTW. Your client MUST have the appropriate
> interface (and correct version) at compile time - or you
> can jump through hoops and use the very un-natural and
> labor intensive reflection api - but at that point its
> just way too much work for too little payoff.

The interface is a contract that makes it a lot easier for everyone to know what the system does. Developers will be able to replace piece-parts with all symantics of all operations very well documented. In a smalltalk or other dynamic language, you can end up with subtle side effects in places such as the default message handler and elsewhere that make it very difficult for people to just walk in and adjust the system for a slightly different task. There can be side effects that are not a visible part of the system.

> Which brings me back to my earlier assertion -
> distribution is clearly more work for the programmer (in
> the case of Java - MUCH more), more work for the computer,
> and may or may not provide you with a great payoff. So do
> developers not "get it"? Or do they just have more
> pressing business logic to write and not enough
> time/motivation to do boiler plate plumbing? I know where
> I stand on this. Remote interfaces cost more money than
> local ones and I can usually do without them.

What you are supposing is that somehow the only important consideration of distributing a system is that it might make the work between any two parts of the system slower. What you fail to take into account is that threading can reduce latency related to distributed systems. And, the idempotency of remote method calls helps make sure that you can multi-thread without state related issues where multiple threads comming from remote VMs might corrupt state.

When state is important each remote client can have a smart proxy or a remote reference to a unique object that holds some state if needed. You can then use the distibuted leasing model to make sure that any shared knowledge between the client and server is dropped when the client disappears in an abnormal situation.

> The arguments about half baked exception handling to deal
> with network reliability is well taken - but I'd argue
> that the more natrual solution is to have your services
> participate in transactions and make use of JTA.

Transactions are great for maintaining consistancy of global resources. But each VM still needs to manage socket connections, proxy instances etc., related to network failures. So, there is some work where you really need to use Exception handling to help you know when things need to be cleaned up.

> Now here's a chance for you to educate me - If I am to use
> a distributed SOA then I am going to likely require
> distributed transaction management. Looking at the Jini
> docs - it looks like Jini has its own transaction manager
> - does this manager interop with the JTS/DB Transactions I
> find in my local J2EE server?
>
> Its not at all clear to me but looking at the package
> names my guess is NO. The are independent mechanisms. In
> which case they ought not to be mixed. I'd be pleased to
> hear I'm wrong about this though.

A simple adapter service would allow Jini services to participate in JTA based transactions. However, the JTA model within your APP server may not allow you to 'export' a transaction for remote use. So, you would need to put a Jini service within your APP server that would provide the remote RMI semantics for a Jini service.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: OK, Pile on the new guy Posted: Apr 22, 2004 10:08 AM
Reply to this message Reply
> When you've decided to use another language or feature of
> a platform, have you always been forced to use it due to a
> business need, or have you been able to play and explore?

Oh, you haven't had to find a job lately have you?

Occasionally I get to call the shots. When I do, the solution is seldom Java.

But this is more and more rare. The typical job req involves a long vendor/version specific list of stuff management already bought because it was listed in some PHB magazine. Add to this work engagements that come in 3-6 month contracts and the frequent use of the word "overqualified" in response to my application (apparently 2-3 years of development is the sweet spot) and the utter lack of the appearance of Jini in the aforementioned reqs and you might begin to appreciate my skepticism.

Incidentally, I've got really broad experience and in the last year I still only manage to keep working about 50% of the time.

Given that the JCP and the apache group farts out a framework every other week, I've begun to take a trailing edge adoption approach to technologies. The Java "platform" is way too freakin big and loaded with redundant stuff. There is nothing in Jini that isn't also available via EJBs and EJBs are much more popular.

> I am curious where the barrier between you and Jini comes
> s from and what issues are truely detracting.

Amount of coding work vs payoff and complete lack of market adoption would be two. Overselling it for inappropriate uses would be one more (mentioned in my first post).

> > Sure. Smalltalk, Ruby, and Objective C are message
> > passing languages. I can send any message to any
> object
> > at any time.
>
>
> public interface MessageReceiver extends Remote {
> public Object send( Object msg ) throws
> rows RemoteException;
> }
>


OK, but this isn't the typical approach used in the Jini literature. The typical approach is to write a bunch of interfaces and then remote them. Frankly I think your approach is more practical - but I don't see it advocated anywhere.

> > http://cocoadevcentral.com/articles/000062.php
> >

> Because they are showing you all the details.

Are these details I have to write? It still seems like a lot of boilerplate. Its definitely larger than the PDO version of the same code.

> Doesn't seem like that much code to me.

For what it does, it looks plenty verbose to me.

> In a smalltalk or other
> dynamic language, you can end up with subtle side effects
> in places such as the default message handler and
> elsewhere that make it very difficult for people to just
> walk in and adjust the system for a slightly different
> task. There can be side effects that are not a visible
> part of the system.

This is true in any system. So?

> > Which brings me back to my earlier assertion -
> > distribution is clearly more work for the programmer
>> Remote interfaces cost more money than
> > local ones and I can usually do without them.
>
> What you are supposing is that somehow the only important
> consideration of distributing a system is that it might
> make the work between any two parts of the system slower.

No, reread what I said. Distributing the system makes the *development* of the system go slower. Distributed systems have more failure modes, and more infrastructure to support for the *developer*.

IOW, which is easier - to throw it all in one VM with local interfaces and no RemoteExceptions to catch - or to do the distributed system.

> What you fail to take into account is that threading can
> n reduce latency related to distributed systems.

I don't fail to take anything of the kind into account. I'm well aware of the benefits of parallelization - I'm also not often presented with a situation where I can take advantage of it and when I can, I am typically constrained by the need to assure ACID behavior.

> And, the
> idempotency of remote method calls helps make sure that
> you can multi-thread without state related issues where
> multiple threads comming from remote VMs might corrupt
> state.

If you move those method local, I'll wager they'll stay idempotent. Its not an inherent feature of remote invocation.

> When state is important each remote client can have a
> smart proxy or a remote reference to a unique object that
> holds some state if needed.

Yes, done that - its even more work though.

> You can then use the
> distibuted leasing model to make sure that any shared
> knowledge between the client and server is dropped when
> the client disappears in an abnormal situation.

Sure, in other systems this is known as distributed garbage collection. Old idea.

> A simple adapter service would allow Jini services to
> participate in JTA based transactions. However, the JTA
> model within your APP server may not allow you to 'export'
> a transaction for remote use. So, you would need to put a
> Jini service within your APP server that would provide the
> remote RMI semantics for a Jini service.

OK, more work for me again.

So I get it, If I want to use Jini as part of a J2EE solution, there's a lot of stitching to do. If I use Jini at all (or any distribution mechanism) its more work (*development* work) than doing a local model. So the question remains, is the extra coding work worth it?

More often than not, I find the answer to that question is "NO".

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

If you float between contracts do you have to worry about extensibility? Posted: Apr 22, 2004 8:34 PM
Reply to this message Reply
> Oh, you haven't had to find a job lately have you?

I have not, but I am not sure how that matters.

> Occasionally I get to call the shots. When I do, the
> solution is seldom Java.

That can provide you with a different view of the world. I am familiar with the influence that working in a particular environment can have.

> Incidentally, I've got really broad experience and in the
> last year I still only manage to keep working about 50% of
> the time.

I don't want to poke at your work situation in a harmful way. I would, blindly, observe that if you aren't having to stay at the same place to maintain the work that you've done, and to grow with it, then you may not know how your decisions have constrained what might be needed down the road.

Here's my position a little more bluntly. You can either design for the here and now, or you can look down the road and make plans for the turns that are on the horizon. If you design a system with a distributed systems architecture and methodologies in mind, you'll be able to take the turns you need to grow a software system more readily. If you are working on such constrained, specialized systems, day in and day out, that they never do more than one thing for more than a year, then yes, it would probably not be worth thinking about Jini for such systems.

But, I am not talking about, nor am I considering with much detail, these kinds of systems. Man such systems that I've seen, the "CRUD" systems, exist in the way that they do because the entire enterprise has no consistent architecture for how things interact, exchange data etc. So, everytime someone wants some data, there's not a centralized broker with authentication and subscription based services. Instead, there are 200 databases that things get written into with triggers strewn all over the place.

These systems won't benefit from Jini being grafted on. However, I do believe that the enterprise can benefit from having a new architecture based on Jini put in place so that anytime I need the data produced by the XYDataMapper, I just look it up in the lookup server and use it (providing I have access). I don't have to know the XML schema so that I can unwrap the data. Noone has to write any code to provide me a hook into that application or do anything else except account for access permissions and scalability.

If the system is already Jinified, then there are lots of solutions to access control and scalability inherent in the architecture, so its more of an administrative detail than a programming detail.

You keep comming back to the fact that you think all of this stuff is not new. I don't think that's a valid argument. The packaging of these technologies into a single package for the Java language is new. J2EE does not have an interface AND attribute based lookup. It has JNDI which might derive such things from the passed name, but I am not aware of any JNDI provider that does that yet. But, there has been talk in the Jini community about creating such a thing.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Hell yes Posted: Apr 22, 2004 9:39 PM
Reply to this message Reply
And I resent the implication.

I do every gig like I'm going to be there forever. But layoffs/business failures are very common. I live in Denver, BTW, with the second highest unemployment in the nation. I moved here from the bay area which isn't doing too well either.

So I do plan for longevity. I do a pretty good job of it too. I've been chief architect of half a dozen companies. I have products still on the market that are as much as 7 years old.

>J2EE does not have an interface AND attribute based lookup. It has JNDI
>which might derive such things from the passed name, but I am not aware
>of any JNDI provider that does that yet. But, there has been talk in the Jini
>community about creating such a thing.

OK fine. When you get the platform consolidated, let me know. There are too many competing mechanisms and redundancy in the Java "platform". Its a crap shoot to pick the technology that's going to last. For instance, where the hell is JXTA being positioned this week? Does anybody still care? I can't be bothered to keep up with every single api.

So I focus on the ones that appear in the job advertisements. I've never seen a job mentioning Jini. I see lots of jobs mentioning J2EE. Guess which technology I'm focusing on? (And FWIW, I think J2EE and struts are shit - WebObjects and Seaside are vastly better tools - again simply from the standpoint of developer productivity).

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

XP suggests you plan for the here and now BTW Posted: Apr 22, 2004 9:44 PM
Reply to this message Reply
>You can either design for the here and now, or you can look down the road and make plans for the turns that are on the horizon.

XP doctrine, BTW, would have you design for the here and now as its quicker and its quite likely that your system will not survive to see the horizon (project cancellation, business refocus, bankruptcy, funding shortfall).

If your system does not survive, then the extra work spent distributing it is wasted and in fact may be the cause of your system being killed (not enough visible progress in a short enough time period).

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: XP suggests you plan for the here and now BTW Posted: Apr 23, 2004 7:02 AM
Reply to this message Reply
> >You can either design for the here and now, or you can
> look down the road and make plans for the turns that are
> on the horizon.
>
> XP doctrine, BTW, would have you design for the here and
> now as its quicker and its quite likely that your system
> will not survive to see the horizon (project cancellation,
> business refocus, bankruptcy, funding shortfall).

XP says that you should not develop any more actions/capabilities in the system than you need. This is in stark contrast to many peoples notion that this also means that you should not plan for the future in your design and implementation.

> If your system does not survive, then the extra work spent
> distributing it is wasted and in fact may be the cause of
> your system being killed (not enough visible progress in a
> short enough time period).

Most cancelled projects that I've experience have been because of either money, or too short of a vision. At some point in the project it is realized that the project won't accomplish anything that actually makes any difference to the bottom line...

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. Now, all the software that uses those interfaces has to handle them and be designed to deal with remoting. Later, if you need to remote, you don't have to rearchitect or redesign the system for this. The interface signatures don't change!

Ronald Tetsuo Miura

Posts: 22
Nickname: ronaldtm
Registered: Jan, 2004

Re: XP suggests you plan for the here and now BTW Posted: Apr 23, 2004 7:45 AM
Reply to this message Reply
> 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.

> 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. 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.

> 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?

Ronald Tetsuo Miura

Posts: 22
Nickname: ronaldtm
Registered: Jan, 2004

Re: XP suggests you plan for the here and now BTW Posted: Apr 23, 2004 9:03 AM
Reply to this message Reply
Excerpt from: Jini Network Technology Fulfilling its Promise: A Conversation with Jim Waldo
http://java.sun.com/developer/technicalArticles/Interviews/waldo_qa.html

Unfortunately, not everyone is convinced. There are still those who try to produce middleware that masks the difference between local and remote calls. And then there are those who try to avoid the problem by claiming that they are not subject to the errors that we talked about. I'm constantly amazed by people who say that they don't have to worry about the difference between local and remote computing because they use "reliable message systems." I've been known to claim that there are two kinds of reliable message systems. The first kind are those that come with an asterisk; following the asterisk leads you to the small print, where you find out when the messaging system can fail and so it is not, therefore, reliable. The second kind are those systems that simply lie -- they are no more reliable, but they don't tell you that there are circumstances where they can fail.

A friend of mine once characterized the majority of computer scientists as people who would rather spend weeks of hard hacking than an afternoon in the library. I'm afraid that describes many in the distributed computing community today. 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.

Flat View: This topic has 27 replies on 2 pages [ 1  2 | » ]
Topic: Why Standards? Previous Topic   Next Topic Topic: Why is Distributed so Hard?

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use