Re: [MLUG - DISCUSSION] Re: [MLUG] guess what

[Michael <EMAIL:PROTECTED>]

> A lot of it is the language features and how the server systems 
> implement them.  Ever seen the API's for Java?  They're some of the 
> best documented and easy to work with set of API's I've seen.  I'm a 
> HUGE fan of the javadocs system.
> As for the specific API's that make Java nice, a lot of it has to do 
> with object indirection, the naming interfaces and libraries available 
> for it.  I'd imagine any language given time and effort could compare, 
> but Java has that stuff now, and has had it.  It's also hard to 
> describe all of this as it gets kinda difficult for even me to 
> explain.  But, here's a simple case:

Documentation is always a good thing. I believe that Python's pydoc 
system was modeled after Javadocs. It's still not everything Javadocs is 
but it's still impressive. I love being able to make a program access 
it's own documentation. I use that feature to have self-documenting 
code. You can open a connection to the program via a browser and see a 
documentation of it's XML-RPC interface.

Prehaps it's me but I've always found Java has to many libraries you're 
required to learn to really write anything useful. It seems to have a 
high learning curve. What do you think?

> Tomcat server, which runs Servlet objects.  You can run this on one 
> server, which ONLY stores objects which handle output processing.  
> Another server, an application server, runs business logic components 
> and does caching.  The Display objects talk to the other server, the 
> application server, VERY easily in java using RMI, JNDI, or any other 
> set of look ups.  XML communications makes transferring data VERY 
> easy.  Further, the application server and the web server don't even 
> have to be the same OS, and you don't have to mess with CORBA to get 
> objects to transfer over or do anything funky.  Or at least, not too 
> terribly funky.  You can get VERY complex with certain scenarios.  
> Anyways, the business object layer then would talk to the database, 
> handle object loading and passing, adding indirection, caching, and 
> optimization.  This lets developers work on the display end without 
> having to see how say a business policy was processed, or what the 
> database format is.  Now, of course, this is quite a bit trickier to 
> code, even this one simple example, but on the other hand, you get a 
> lot of advantages, in that you can add MULTIPLE servers in each layer, 
> and not have to replicate your code, worry about different 
> configurations, etc.  the display servers, assuming they were 
> multiple, don't have to understand or know where the application 
> servers are, or that there are multiples of them - it just uses the 
> API's for JNDI to do object lookups and to obtain the information.  
> And then, to scale the system, you can just add in more servers.

I do something like this anyway using XML-RPC. I've done it in PHP and 
more recently Python. Yes, that does require some effort on the part of 
the programmer but that effort is very small. Essentially all I need to 
do is register the methods with the XML-RPC service and call the 
functions using the XML-RPC lib of the client programs. Maybe five lines 
of code extra on the server side per program and three on the client 
side. How does that compare to Java? Given that it's HTTP you can use 
normal proxy and load balancing software to implement caching and load 
balance.

Python's XML-RPC lib does need rewritten so that it supports SSL wrapped 
connections.. for cases where you may need sepperate servers over 
unsecure networks.

Something like CORBA I feel is to top heavy for most needs.

> Of course, this is a fairly simple example, doesn't explain that some 
> of this can be a BEAST to setup and get running properly, that the 
> initial configuration is often a royal pain, that some of those 
> application servers to get support can be expensive, and numerous 
> other things.  But, when you consider the size of an enterprise, i.e. 
> 10,000+ users with a MASSIVE amount of data, all of a sudden costs 
> aren't quite so important, or at least, the cost of delays, 
> inefficiencies, or other issues is MUCH more expensive then getting 
> that all setup and working right.

The advantage of my method is that it's 100% free I guess. I don't think 
it's that hard to setup but I can't compare it to Java since I've not 
tried setting that up. I can't say that I've compared how well it's 
performed in comparison either. It'd be interesting to write the same 
app in both languages and run some tests to compare them.

> I'm hoping this sorta explains it.  And it's not that other languages 
> couldn't do so, but it's more other languages AREN'T doing so, other 
> than .Net.  Java already has the tools, the API framework, the 
> libraries, etc. which allows all of this to be implemented.  The only 
> thing Java really needs to do is simplify some of the stuff so newer 
> programmers can hop in without having to read a library, or figure out 
> what some of the stupid Sun documentation really is saying.  Sun's 
> documentation generally is lousy, but the Java API's as a general rule 
> are great, and there are some REALLY good Java books out there.  Sun 
> just seems to like to make things difficult for most people so they 
> can get support contract money out of them.  Doesn't mean the product 
> isn't good, just wish it were easier to get into.

Maybe. I think you can do it in other languages but it isn't a common 
practice and Java might have an easier more intergrated solution. I'd 
agree that Sun is the main problem Java has. If they'd opensource Java 
and give control of it to a community that could iron out some of these 
kinks it could be a very nice tool. I still think that if they don't 
that Microsoft with their C# and .NET is still going to murder Java.
_______________________________________________
discussion mailing list
EMAIL:PROTECTED
http://mlug.missouri.edu/mailman/listinfo/discussion