Slashdot Mirror
XML and Java, Developing Web Applications
Unfortunately, they might have put a little more thought into the bigger picture with this approach, because what they have ended up with is a book that reads like a play with two completely different acts: the second showing a wide variety of applications of XML for the Java platform, which works well enough, and the first, which attempts to teach the basics of working with XML and Java, which isn't quite so strong.
The GoodOne look at the table of contents should convince you that the book rates pretty highly on buzzword compliance (XML, DOM, SAX, SOAP, XLST, WSDL, UDDI, JSP, EJB, etc.). When it comes to content that should impress your manager, you could do worse. The accompanying CD-ROM also comes with some neat stuff, like Tomcat, Jakarta and Xerces, and trial versions of WebSphere and DB2. As an added bonus, the code within has been tested on both Windows and Linux.
For the most part, the progression through the topics is well-directed, with in-depth discussion about the different means of XML parsing and generation using both DOM and SAX early on, and after going through the early chapters the reader should already have a decent idea about what techniques might fit their own personal projects. Tamura's chapters on DOM and SAX in particular stand out, not just for the coverage he gives the two, but also for his comparisons of one versus the other. They serve as a decent enough primer to prepare for the latter chapters, although the reader might be better equipped if they gained some extra foundation from other sources (more on this in a bit).
Despite the breadth of topics, they don't throw in the kitchen sink. Readers are expected to get their introductions to XML and Java elsewhere, and while one can probably get away with a surface understanding of XML and still get what they need out of the book, the same cannot be said for the needed Java knowledge. However, for someone who has a good understanding of Java and the various surrounding technologies (JavaBeans, Java Server Pages, and so on), there's some pretty good coverage of the different ways that XML can be incorporated. They've even taken care to provide appropriate supporting material, talking about where the various standards may be headed, some coverage on the theory behind Schema design, and there's even an appendix that explains JDBC, to serve as a counterpart to the chapter on XML and databases.
This book is in many ways an example of the way second editions should be. This book has double the chapters of the original, and efforts have been made to cover as much additional (but still relevant) material as possible, including XML Schemas, namespaces, messaging, web services with SOAP, and security. Some of these topics were in the first edition, but bunched together into a single chapter. In this book, they get individualized treatment.
The Not-So-GoodIt's a hopeful endeavor to bring together nine authors and expect that there can still be stylistic continuity, and this book is a good example of what happens when the editor doesn't lay a heavy enough hand. There are inconsistencies from one chapter to the next in the way code snippets, method lists and diagrams are incorporated (in particular, the use of line numbering by Uramoto and others is unintelligible to the point of inspiring wrath). Furthermore, because each author handles their subject matter just a little bit differently, it's hard to get into any sort of a learning rhythm. In this case, the whole is probably weaker than the sum of its parts. A good section, like the one contributed by Tamura for instance, loses some of its luster if the chapters preceding it or following it aren't up to snuff, as is sometimes the case throughout the book.
To be fair, things do improve in the latter chapters when the authors are focusing on more specialized cases, and such expectations of continuity become somewhat moot. However, even then, the authors obviously have different opinions on how steep the learning curve needs to be. The chapter on JSP, for instance, eases you in and begins with simple examples, despite the fact that embedding programming code within HTML is pretty intuitive, comparatively speaking. The chapter on WSDL, on the other hand, makes no such assumptions of a beginner's audience, and it's trial by fire, with long stretches of code and in some cases nary a comment in sight. It's understandable that talking about distributed programming necessitates long code listings, but a newbie is going to experience some serious hymen-breaking here.
If there is any consistency, it's a pretty clear editorial bias towards Xerces over JAXP early in the book, including a special chapter on parser tricks specifically for Xerces. No real surprise there, as several of the others have been key contributors to IBM's open source project. Still, it's poor form to be using the pages of a learning guide to talk smack about one over the other, if for no other reason than the fact that it becomes a distraction to somebody who's trying to learn with an open mind towards all the possibilities. If a comparison is absolutely necessary, it deserves its own chapter away from the rest of the learning material. This brings up another problem, in that by mixing JAXP and Xerces techniques together early on, you run the risk of overwhelming a neophite who'd be glad to figure out just one way of doing things. There's already a marked difference between DOM and SAX parsing, and doubling this with the duality of JAXP vs. Xerces makes for an introduction that's a little too busy.
Also, what was mentioned in the previous section as one of this book's strengths is also a bit of an audience-limiter. If you try coming to this book without a solid founding in Java, there's a decent chance you'll find it difficult to get into this book. People who are already soured on Java will likely find their distaste further entrenched, and it's doubtful that anything beyond the most conceptual of the subject matter will be portable.
ConclusionThere's something to be said for bringing in the biggest authorities in the field to present a subject -- however, it's one thing to know a subject and another thing completely to know how to teach that subject well. John Madden once said that the best teachers are the ones who got C in school because they're the ones who best understand the intellectual bumps and bruises that can come from learning a new subject, and can help prepare and guide a student through them. There are no C students in this bunch -- readers are left to their own devices to keep up with the authors and fight through the numerous obstacles to get at the core knowledge within, which is admittedly impressive enough. Far be it for a lowly Slashdot contributor to tell the folks at Addison Wesley how to do their job, but on a third edition they might want to put the material through a stronger editorial filter to make things a little easier on the reader. This is definitely a book to preview in the bookstore very carefully before considering a purchase.
Table of Contents Preface.1. Web Application, XML, and Java.
2. Parsing XML Documents.
3. Generating XML Documents.
4. Working with DOM.
5. Working with SAX.
6. Parser Tricks.
7. XPath and XSLT.
8. Bridging Application Data Structure and XML.
9. Working with Schemas: Datatypes and Namespaces.
10. XML Application Server.
11. XML and Database.
12. XML Messaging.
13. Web Services.
14. Security.
15. Data Binding.
16. Principles of Schema Languages.
Appendix A. About the CD-ROM.
Appendix B. Useful Links and Books.
Appendix C. XML-Related Standardized Activities.
Appendix D. JDBC Primer. Related Links Addison-Welsey website
W3C's XML page
Sun's Java page
You can purchase XML and Java, Developing Web Applications from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then visit the submission page.
Sun isn't driving it as hard as it used to
Where did you get that impression? I don't mean that rhetorically; I'm relatively new to Java development, having just started working with it about a year ago. What makes you say that Sun isn't driving Java? Just this winter they pushed out J2SE 1.4, and a beta of 1.4.1 is available now. Seems to me as though Sun is doing as much Java work now as ever, at least in my limited experience.
Kids:"Grandad, what was .NET like?" .MSX and there has never been anything but .MSX. That's the Word of the Gates"
Gran:".NET? Never heard of it. It never existed."
Kids:"But Grandad, we found a book in the attic and...."
Gran:"You NEVER found that book. DO YOU UNDERSTAND? It never existed. We have always loved
Kids:(disappointed)"Thanks be to Gates".
If you aren't part of the solution, there is good money to be made prolonging the problem
Apache XML projects
Apache Java projects
Explore the projects at the above two links. All the most exciting and usable Java/XML technologies are in there, ranging from SAX/DOM Schema aware parsers to transformers, databases and query languages for XML.
XML is not a Java only technology, far from it. I fail to understand why so many books appear to try and make it look so.
Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
Geocrawler error message.
Sun isn't driving it as hard? What planet are you on? Sun just finished a complete rehaul of the java.sun.com site. Java is still very alive, though it may not be getting the press it once did.
.NET technology.
PHP is very nice, and very easy to use (especially compared to J2EE), but if you're doing some serious heavy enterprise/distributed application work, then it just doesn't cut it. I've been working in enterprise java applications for about a year and a half now and I've found that most developers who aren't very familiar with java have no idea how powerful it is, how much it is used, and how much support there still is for it. Of course Microsoft is trying to drop java, it's been one of their key targets for years. Now that they're trying to drop it on the desktop, people start to think that java is dead. Well, server side it sure isn't and it has quite a bit of headway on the newer
That's not to say java is perfect and will never be replaced, but it's still a player now and to just dismiss it is to make a gross mistake.
Who said Freedom was Fair?
For example, take an HTML form. Let's say you had a few hundred choices for one of the textboxes on that form. It would be incredibly useful to be able to type in the few first letters of the text and press a button to search for all matches and display them in a selection box next to it.
But that's hard in any language on any platform, unless your platform happens to provide you with a widget that does that for you. (ViewKit does on SGI. Don't know about any of the others, 'cause I don't do GUI programming very often.)
I think you've got a valid point, but it doesn't justify your conclusion. In your example, you just need to redesign your UI slightly. A few hundred choices for a text box? Maybe there's a better way to present that to the user.
Sure, the HTML interface platform has severe limitations. But it's going too far to say that web applications will fail because of them. It's just that web applications are good for only a subset of what native desktop clients are good for. But within that subset, web apps are very useful.
My personal opinion on data entry, though, differs from the conventional wisdom. My girlfriend is a doctor so I've spent a little bit of time in hospitals. One time I watched a woman admit a patient. It took about five minutes, I guess. She was using an old-style forms-based data entry program on a text terminal, the kind where you fill out a whole screen of information and then send that screen to the computer downstairs for processing. She was incredibly fast, keying in a huge amount of data in just a few minutes. No messing around with clicky-clicky, no pulling down menus. Just type, tab, type, spacebar, type, tab, enter. Man, that was efficient.
Instead of trying to force a web app to behave like a Windows desktop app, maybe you should look at some older programs that use the same sort of screen-based paradigm that web pages use, and design your interface according to those well established conventions.
This comment doesn't make any sense. Compare PHP to JSP if you must, as both are front end languages that can do everything, but you'd be foolish to use them to do so.
Writing a larger scale web application in PHP would be a very bad idea, and until you've done one I doubt you'd see why.
For good reason. There is zero demand for XML web services on the right now, no real support for security, and still-evolving standards.
PHP is very nice, and very easy to use (especially compared to J2EE), but if you're doing some serious heavy enterprise/distributed application work, then it just doesn't cut it.
Agreed, 100%. We showed a web application demo at a recent trade show. The demo was written (by me) in about two weeks, using PHP and a custom-written interface to our proprietary database back-end. It worked fine... for the demo.
But we're implementing the real, non-demo application using J2EE technologies. There are a lot of things that you can do better-- more securely and more stably (is ``stably'' a word?)-- with Java and J2EE than you can with PHP, and there are a few things that you can't do with PHP at all. For example, one of the features of our web app would be that it opens a socket listener, then passes the IP and port of the listener (via a separate control socket) to the back-end. The back-end connects to the web app's listener socket and initiates a bulk data transfer. It works pretty much the same way FTP does, if you're familiar with the guts of that protocol.
As of last March, that simply was possible with PHP, as near as I could tell. You could open sockets to other computers, but you couldn't open a socket listener inside a PHP script instance. That's not cool, because using the web app to facilitate bulk data transfers between the back-end and the desktop is a major design feature for us.
And, of course, when you're working on a complex, distributed app with lots of components, the ``bondage-and-discipline'' features of Java come in handy. It's nice that non-exception-safe code won't even compile. Saves you time in test and debugging.
I never really spend too much time advocating Java, even though I develop in it just about every day. There will always be people who play the other side, the devil's advocate, who regurgitates all the possible negative things that can be said about it...slow, not open, run once and debug everywhere, etc.
.NET thing has given me great pause. When it first came out, so many of my friends, mostly developers, started gleaming with energy about .NET. It was the greatest thing since sliced bread, and it was going to revolutionize computing as we know it. It was so tight, elegant, powerful, with great performance, and a much better GUI library.
So now, I want to say just how much I really enjoy and appreciate it as a technology. It's a complete dream to work with, with an absolutely huge library, extremely well done documentation and support, instant answers to just about ANY question at Google Groups, and a huge community around it. I think Sun has found a great balance between being open and providing leadership and definition.
As a professional, the whole
Instead of the hype settling down into seeing it just as a good tool, almost all of them have switched away from it. It was cool at first, they explain, but now they realize that it's still run by Microsoft, it still needs Windows, and almost everyone except Microsoft still has no idea what's going on under the hood.
So it seems like it's simply a pre-requisite to the Internet Age that the source code must be available. The rules have changed, and the game people now are most excited about playing requires that the source code is available. It's now just a part of the ground rules. You can still play the old game, but the best and brightest are now playing a new game, and to prove yourself and be a part of the new game, you have to play by the rules. There are still people pretending (especially to themselves) that this old game is really exciting, but those playing the new one see how much better it is.
So, I definitely expect that Java will continue, and that the ringing endorsement of Java by Microsoft will lead to a huge renaissance. It may be that it will have to become GPL'd to have a chance, but that's not clear at the moment. I think it's just a matter of time before it starts to take over on the client, and the eventual GUI for Linux will be written in Java. In the same way that you don't notice the BIOS when you run the OS, you won't even notice the OS when you run whatever becomes the NET GUI.
I think PHP or another webside language/scripting language would be more beneficial at this point than using Java...
sure, if most web "sites" needed only to use server side scripting, that would work great. infact, serverside javascript works great, and maybe asp does as well. the fact is though, many companies are building web applications, not web sites. these web applications need to communicate with other web and legacy applications (that's where the ejb app server and xml bring it all together). jsp, with all it's ease of use is just icing on the cake. also, these applications need to be scalable, redundant and failover safe. is the architecture bloated? possibly. is it a LOT to learn? seems that way. right tool for the job? most often, yes.
not that i'm a big fan of web applications in and of themselves, but lots of companies are moving in that direction. the user interface is extremely limited, the protocol is stagnant, and forced upgrades (re-trainning staff to use the new applicatoin) are aren't an issue, they are mandatory.
Java had it's place, but I think it's no longer fast enough for current practices. I think PHP or another webside language/scripting language would be more beneficial at this point than using Java, [...]
You could not be more wrong.
The only thing wich is faster than Java as a web application is a monolithic C++ application with an build in web server.
Or -- of course -- the same in C.
Precompiled and cashed perl scripts may come close to it, depending on the purpose of the web app. But perl scripts have no way to pass objects of internal data from one script to the other. However a big perl application in OO style might/should be able to do that.
Look here for easy scripts and a speed comparision of e.g. PHP versus Java (note: that is not Java 1.4): http://www.bagley.org/~doug/shootout/
This side benchmarks explicitly web sites: http://www.cs.rice.edu/CS/Systems/DynaServer/inde
regards,
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
There's hardly an MS shop out there that hasn't felt some misgivings about Microsoft and specifically .NET over the past couple of years - whether because of Microsoft tightening the licensing screws, dumping support for Java, radically changing VB for .NET, or pushing a brand new language (C#) for Microsoft's own benefit, or simply all the information that's come out in court which makes it clear that Microsoft has always been more than willing to screw their customers to make a buck.
IOW, Microsoft has provided us with an enormous amount of FUD ammunition, all we have to do is load up and start firing. Don't be too in-your-face about it, though. Instead, start by asking questions:
Don't get overly emphatic about any of this, you're just asking questions. Once the target has had a chance to think about this - maybe over a period of days, weeks, or even months, depending on the degree to which their brains are set in Microsoft concrete - you can slowly start pointing out the benefits of open platforms.
For example, running Java means using any hardware and OS as your server, today. The WORA creed actually does apply to Java on the server side - we regularly run our server apps on Windows, Linux and Solaris, without changing a line of code. Linux server farms are a heck of a lot cheaper than Windows farms, because of licensing. And if you need a single box that's bigger than any PC-class server, you can't beat the Unix-based hardware that's out there.
Running Java means wide support from multiple vendors, some of them very large and reliable, like IBM and Sun. There's competition amongst vendors in the form of multiple implementations of application servers, JVMs, and Java compilers - you can pick what you need, from open source to expensive enterprise-oriented products. The equivalents on .NET are all single-sourced - no competition, no openness.
The lack of competition within .NET has important implications: Microsoft can't fill all niches, and it doesn't even try. Its offerings are usually skewed towards the most lucrative markets, the biggest enterprises, and as a result smaller businesses that don't need all the features have unnecessary stuff pushed on them. In the Java world, if you want something small and light, you can just download an application server like Jetty, a lightweight but powerful persistence solution like Hibernate, and you've got a kick-ass application development and deployment solution. Powerful open and extensible IDEs abound, with Eclipse being a top contender.
What it comes down to is that companies have to be on some weird kind of crack to think that it makes sense to commit their development to .NET. Microsoft has upped the stakes in platform commitment required from their customers, but it's not offering anything in return. Meanwhile, there's a widely used, widely supported, competitive, successful, open, multi-platform alternative that's available today. The choice here is a no-brainer, folks.
[P.S. for those who object to the Java-centricness of all this, I'm talking about commercial scenarios where Perl, Python etc. are just not considered options. But once companies begin using open solutions, they tend to become more open to other such solutions - I had one IT manager who switched from IIS/ASP to Java/JSP recently ask me where he could download Perl for Windows.]
1000 processes doing just-in-time compiling? Now tell me how that resultant machine code is shared securely between processes. If compilation to native machine code can be done, why not do so before run time, and then the stored machine code image can have its one copy in RAM shared by the many processes running. This wouldn't have been an issue with applets in a browser, but it certainly is in a server.
now we need to go OSS in diesel cars