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.
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.
I am sorry, but this poster has aboslutely no idea what he/she is talking about. Java will continue to be not only a heavy hitter, but the heavy hitter in the years to come for the following reasons:
1. Momentum. I don't know if this poster has noticed, but most large organizations build big things have seen J2EE as the only to go for sometime. Therefore, Java already has a very large chunk of the market today. Those applications will continue to be developed and expanded in the years to come.
2. Cost. The cost of developing and deploying a Java solution can be done with siginificantly less dollars that those based on proprietary technologies. I develop applications daily that could not be done in PHP, it's just that simple. It doesn't scale or provide the advanced facilities (i.e. JTA, JMS, advanced resource pooling, clustering) that our applications require. When you compare cost apples to apples, Java wins hands down. I can deploy a completely clustered app and pay NOTHING for licensing fees (Apache, Tomcat/Jetty, Java, JBoss) other than for the database.
3. Platform elegance. Like it or leave it, the J2EE is a very nice development platform. Could it be better? Heck yeah! Is it very nice as is? Heck yeah!
There are a whole range of other reasons, but I need to get back to real work. This poster has obviously never used Java, and, probably, never developed much more than his/her personal web site the pictures they snapped of their buddies last weekend.
Download the full Manning book J2EE and XML Development (pdf) here
You can also get a full copy of Bitter Java there.
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.
IBM understand this very well and is pushing for WSFL (Web Services Flow Langauge), which uses concepts from pi calculus async communication model. MS on the otherhand is pushing XLang, which is really for simple two way communications. SOAP in it's current form in my opinion is really push messaging. Since SOAP doesn't address state, it's not well suited for transactional processing. Atleast from the actual code examples I've seen and the documentation on devnet.
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.]