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.
Because Microsoft is trying to drop Java, and Sun isn't driving it as hard as it used to, I personally don't view Java as a viable solution for web development anymore. 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, and certainly easier to intereface with XML from what I've seen. In fact, with HTML servers these days there's already native XML/XSLT support, making server side scripting/applications not even needed in some cases.
There's about 64 million people fluent in XML and Java, and approximately 4 jobs available (3 of which are already going to relatives). Good luck getting one--try the lottery, the odds are better.
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.
The reviewer seems to be worried about the information density in this book. I would say it is a good thing that this book doesn't bother explaining how to compile hello world. If you don't understand the Java syntax, you're reading the wrong book.
Another good thing is that it doesn't include API documentation. API documentation seems to be a popular way of wasting dead trees but IMHO it is much easier to browse/search in HTML form. That leaves more room to content you'll actually need. There's so many Java books out there that use more than half of the pages for introductory stuff and API documentation and then try to squeeze the stuff you really need in ten pages or so.
Jilles
JAXP and Xerces do different things. JAXP is essentially a standard interface that can be used to decouple your parsing code from a particular parser implementation. Xerces is one such implementation (for DOM, SAX, etc.) which can be used underneath JAXP and therefore unseen by a developer. As such it can be used by JAXP but is never in competition with JAXP.
As far as I can remember, JAXP has little or no implementation code.
From the article: 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.
So in other words, the CD has a bunch of (almost certainly) out of date versions of Open Source software in order to drive the price up. Vote with you dollars -- don't buy books with CDs!
Content about things like WSDL is also likely out of date by the time it is published.
I'd say there are probably a lot of good online tutorials on these topics that are probably more up to date.
I am not a number! I am a man! And don't you
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.
I agree. Java and Linux have not always gotten along, but that's changing now. It's even more important that this happens in order to provide an alternative to .NET. Now if only we could get a good open source/free software JVM . . . (anyone know of one other than Kaffe?)
Who said Freedom was Fair?
For good reason. There is zero demand for XML web services on the right now, no real support for security, and still-evolving standards.
Download the full Manning book J2EE and XML Development (pdf) here
You can also get a full copy of Bitter Java there.
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.
(Above is an affilate link)
It was nice of you to say so, at least, but for myself I don't really like it when people post affiliate links like this. This is too much like a barely-on-topic advertisement for my taste.
In case readers don't know, Amazon's affiliate program is basically a system of kickbacks. Person X signs up with the affiliate program and starts handing out special links to the Amazon site. If person Y clicks person X's special link and then buys something, person X gets a small amount of money from Amazon. They say up to 15% of what person Y spent, but I'm sure it's a lot less that than most of the time.
Long story short, people who post affiliate links to Amazon's site are really trying to maximize their gains from the affiliate program. I can't put my finger on it, but that just gives me a funny feeling for some reason.
I'm not flaming you or anything, so don't get mad. I'm just voicing my opinion. Slashdot soapbox and all that.
--Socrates
But there is still plenty of work to do getting it into the system. I've got this pagination engine, see. It doesn't have an integrated lisp machine. In its absence I'll have to stumble along with pointy brackets.
The AC is thick, the comment tendentious. XML consciously borrowed the concept. Have a look at XSLT; remind you of anything?
illegitimii non ingravare
I wathch these GUI based apps and god are they slow to work with. They take less time to learn but god forbid if you have a lot of transactions to enter.
So I will agree with you except for the TAB issue.
DRM? No thanks, I'll just get it somewhere else...
Python isn't hyped as much as Java. This has had a positive effect on the quality of books written about the language. You don't have to plow through hundreds of bad books when looking for a good book on the language. The referenced Python book had the following description on Amazon.
I never understood TAB to advance a field.
It makes sense to me, of course, because I'm used to it. But thinking about it in more depth, I guess it makes sense for a couple of reasons. First, ``tab'' on a typewriter sends the carriage to a different point in the line, where you can start typing something new. So using it to advance to the next field is a reasonable extension.
Also, it makes sense if you consider that ``enter'' is specifically for sending the entire screen to the system for processing. So ``enter'' to advance to the next field wouldn't work.
If you're enough of an old-timer, you'll know that the .NET hackers will be face down in the dirt with large-caliber bullet holes in their backs soon enough - just as soon as Microsoft comes up with the next strategy du jour, just like all the poor VB programmers who were put out to pasture with VB.NET.
Markup is inherently platform-independent for the same reason that scripting languages are: requires an interpreter on your platform.
Pop quiz: Where does the term markup originate?
illegitimii non ingravare
Data Entry Errors- large. The more freedom the user has- the more ways they will mess it up.
I suppose that's a valid point, but it falls to the application designers to put in all reasonable checks on input. You can't verify that a last name was spelled correctly, of course, but there's no way to guarantee that in the UI either. But for things like entering codes for medical billing (a huge, vast data processing job that most people aren't even aware of) you can put a good deal of sanity checking in the back-end system to minimize errors. You can't eliminate them, but you can cut 'em down quite a bit if your application is clever enough. For example, the system will initally reject a billing record that includes no surgical procedures, two nights in a room, and only five meals. The system knows that most non-surgical patients get fed three times a day, every day. If the patient had a surgical procedure, the system will accept the record, because it knows that surgical patients are always NPO for part of their stay. (Oh, NPO = ``nil per os,'' or ``nothing by mouth,'' meaning no food or drink.)
But like all things, it's a trade off. The hospital would have had a much bigger problem if every record were perfect, but it took an hour to enter each one. You'd have patients dropping dead of a burst appendix sitting at the admissions desk. You face the same basic problem with things like airline ticket counter systems. Nobody would die, of course, but customers would find another airline if it took six hours to make their way through the ticket queue.
but I was alone.
illegitimii non ingravare
If you ever had to use an older app where the Enter key was advance to the next feild you would understand what i mean. I've used both. I have seen no benefit except confussion to the TAB. In accounting the TAB key just slows you down. You have to use both hands for key entry. Since most of your time is spent in key entry and account equiry. If you look at any major company with more than 1000 clients you will notice the account numbers are numeric. Faster entry, faster search (Human) lower cost of labor.
I have also used Enter in other database apps. I never felt it slowed me down. I just wish that all software had an option to treat Enter as Tab.
DRM? No thanks, I'll just get it somewhere else...
All the languages referenced in your links were not statically typed (Python, Perl, Lisp).
The dynamically-typed languages are very useful and powerful for individual programmers, smart programmers, and small, tightly-knit teams. But static typing is an important feature in the commercial world, where software has to be worked on by ever-changing teams of often mediocre people. Static typing provides an enormous safety net in these environments, and supports capabilities - such as automated refactoring and IDE hinting - which are nowhere near as powerful in dynamically typed languages.
The best way to understand the benefits of static typing is to ask the question "would it help if the computer had more information about the program it was running?" The answer, by many criteria - performance, safety, reliability, maintainability - is yes.
As for p-code, the last widely-used p-code based system that had static typing was probably USCD Pascal, which dates back to at least 1980 or so. Java is certainly an improvement over that. Java did in fact advance the state of the art, quite significantly. Considering that Guy Steele, coinventor of the awesome language Scheme, was on the original Java team, perhaps they got some things right which you haven't understood yet.
Finally, the "XML as flawed S-expressions" meme may have some truth to it, but it's also so misleading that it's valid to characterize it as simply wrong. The real benefit of S-expressions arises in "code is data" languages like Lisp. No-one has yet come up with a statically typed language that supports this model, so it's not valid to claim that Java+XML is a reinvention of Lisp+S-expressions; it's an evolution in a direction in which Lisp has typically been very weak.
You see before we had GUIs, and windows, next feild was always Enter. While tab seems to work in text/word processing, keypunch entry is another matter.
Ah, but I'm talking about a system even older than that. I'm talking about an IBM mainframe system with dumb terminals attached over serial lines. The mainframe sends you a screen, and you use the terminal to navigate through the fields and input data. Then you send the entire screen of data back to the mainframe for processing. It's not an interactive system. It's almost a batch processing system, except that you process each screen as you're done with it.
That's why the ``enter'' key couldn't be used for advance-to-next-field, because ``enter'' had to be used for process-this-screen-now.
That said, I'm sure you're right that ``tab'' is a bad thing if you spend all your time on the numeric keypad. But the kind of applications I'm thinking of were text-based, not number-based, so to those operators ``tab'' made more sense anyway.
I think you're kind of overstating your point to say, ``I have seen no benefit except confusion to the tab.'' It's more a case of one being better than the other in each situation.
So I just lean that way since it works so well for us so often. It is very easy to get into habits. It is good to hear other ways of doing something so that one does not get too entrenched in a single approach.
;-)
Now that's refreshing. All too often, GUI programmers were raised on the Mac Way, or (worse) the Windows Way, or (even worse) the Java Way, and they spend all of their time trying to shave the corners off of square pegs. What's worst of all, of course, is when your customer is entrenched in the Windows Way, and mandates the use of tabbed dialog boxes for data entry interfaces, then complains when the app is slow and hard to use.
Heh. You want a job?
There's one more thing you need: JDOM. It's basically a wrapper for XML parsers that make manipulating XML in Java much less painful. It's good enough, in fact, that Sun has adopted it as a JSR (JSR 102, I think). I bumped into it a few months ago, and it's already made a huge difference in terms of productivity. With JDOM you spend less time worrying about all the oddities of the DOM or the limits of SAX - instead you mess with good ol' Java objects and JDOM does the rest.
Exactly, and that would be Perl on Unix. That got it right before Microsoft knew there was such a thing as HTTP.
I bet you haven't tried this. It performs fine, we use a Java XML-bound combo box in in-house web apps which replaced traditional two-tier GUI apps. Used by professional data entry operators who love it. It's not slow to load or use.
I cut my teeth on the old style orange data terminal with fixed width fonts and no pictures. When designed well, the end user's learning curve was extremely low. New people, with no computer experience, were up and working within an hour of their new job. After moving to GUI (Windows) and OO formats, the learning curve increased, and quality of data and data entry speed decreased. For pure number crunching, data entry and access, these old systems were lean and mean, and accurate, and have not been improved upon by the GUI world. Of course, pure number crunching or efficiency is not end of existence or only consideration in designing a system...however I don't buy into the argument that the Java/XML/OO world is better in every way to ideas from the past. Different approaches have different strengthes.
An advanced accounting system today no longer requires that you enter the "." It is assumed. This reduces the time in keypuch entry.
My only point is that I wish that todays programs would allow us to configure the keyentry response so we can optimize for our own use.
In spreadsheets it makes sense that the Tab will advance to the next column and that enter will advance to the next line. But I would like to configure my browser to use the Enter key to advance to the next feild so that web based accounting apps would not slow down the entry of numerical data.
DRM? No thanks, I'll just get it somewhere else...
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.]
There still is no good Web Services implementation in Java other than costly commercial implementations from BEA and IBM. In short: Java + XML is a joke.
what about: www.soap4j.org?
Free open source soap for java. You need no commercial products to do SOAP etc. in Java.
Theonly FUD I see in this thread is yours
BTW: please provide a link for downloading
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
--daz--,
.Not and complain about IBM and BEA having "costly commercial implementations" in the same breathe. MS will charge $$$$ for .Not servers and .Not Studio is $1000 USD for a single licence. Meanwhile,many Java-XML solutions are:
You ever heard of Apache? Jakarta? IBM Alphaworks? While only recent additions to the JDK core, all kinds of opensource, free and technically superior XML parsers and tools have been available for Javafor quite a long time now. Xerces, Crimson, Axis (Wow, Webservices!!!!), Cocoon...the list goes on.
And please don't towt the virtues of
1. Free
2. More mature
3. Based on W3C specs
4. Free.
BTW IBM and Sun were also "major contributors" to the XML-Schema standard...your point?
Get over the MS marketing tripe..
Never by hatred has hatred been appeased, only by kindness - the Buddha
heh - another astroturfer with .NET FUD:
MSXML 2 and 3 were not complete XML validation parsers, while IBM's XML4J was fully implementing the XML specification. XML4J later became the Xerces parser from the Apache project.
MS invented the broken XDR schema, and only after they saw that they won't get to do their "embrace and extend" routine with the W3C XML Schema working group they hired one of the editors of the working group. Their newest BizTalk server still does not suport XML schema, only the broken XDR schema. Only MSXML 4 has any support for XML schema.
I think the fact that there are many tools from different vendors and groups (IBM, Oracle, Apache) which provide XML functionality in Java is a much better foundation for Web services than a MS SDK...
I like the Java language ... but this Java Virtual Machine is a hindrance. For things like downloaded applets that need to run in anyone's browser on any machine, a portable run-time is essential. But for building server-side applications, the JVM is the problem. So I'm looking for a compiler system with libraries that compiles Java to native machine code (with many platforms supported), and still does everything any Java program would expect ... except for things like being able to share the runtime code, both the executeable and the libraries, across thousands of process instances, and the raw speed native code gets. Oh, and GPL, LGPL, or BSD style licensing would be nice.
now we need to go OSS in diesel cars
What's the big deal? You can do this with a browser based interface by going to the server to do the query and then displaying the result (I built several things like that with Java/JSP stuff).
Of course, you'll argue that the extra server interaction is slower, which is true. But in the real world many such application run on corporate Intranets (100mb Ethernet) or over T1 lines, so the speed is sufficient for the practical purposes.
There are other gains to be had by deploying web based apps.
...richie - It is a good day to code.
VB in the back and Java in the Front? WTF are you smoking?
.Net. That's right it is superior....uh huh...you just go on now....;)
That's like having PERL in a web page and posting to HTML on the server...that just doesn't happen.
And if by some bizzare twist you really did do that, well, yeah go ahead, use
Never by hatred has hatred been appeased, only by kindness - the Buddha
Aren't those all just reinventions of the Turing machine? What exactly is your point? People abstract things (reinvent) to make them easier and more powerful to get things done. My handgun is just a reinvention of a thrown rock, but it's a hell of a lot more accurate, reliable, and deadly. The car is just a reinvention of the horse and buggy. The telephone is just a reinvention of tin-cans with string. Just because it's a reinvention doesn't mean it's useless.
Any application can use the SOAP protocol to communicate with their server instead of proprietary binary, text, or XML formats; multi-tier architectures will increasingly use SOAP to communicate; etc.
What proprietary formats are you thinking of? CORBA is the opposite of proprietary, and it works very well. If you apply web services technologies to problems that are currently being solved with CORBA applications, you may find that the web services version is, at best, no better than the CORBA version.
I suppose one might argue that web services technologies are better suited to the high-latency environment of the internet, but I don't necessarily buy that. I run CORBA applications across the internet from home to office and vice-versa all the time, with no complaints.
Just like text, TCP/IP, HTTP, and XML, SOAP standardizes how computers talk to each other.
So does CORBA. So we have two competing implementations of the same basic idea. Question is, is SOAP better in any significant way? I haven't yet seen anything that says it is. In fact, the amount of effort required to marshall and de-marshall objects into XML seems prohibitive in a lot of situations. CORBA obviates that need through the standardized mappings of IDL constructs to native language types.
Ever considered combining PHP with C-based CGI?[...] Is that sort of solution unrealistic in the enterprise environment?
In my opinion, it is. For starters, writing CGI applications in C is painful and error-prone. Java servlets are faster and much easier to write cleanly. So there's no real reason to use C or C++-language CGI for anything, unless you're doing something tricky on the back end that just can't be done with Java.
On the other side of the coin, we've got PHP. PHP is easier to write and faster to develop than JSP, in my opinion, but harder to write in any sort of scalable way. For instance, JSP gives you tag libraries which can be used to abstract out some Java code without having to delve all the way into servlets. Very handy for presentation-layer automation. PHP doesn't give you that.
There are lots of little things, too. You can package up an entire web app into a couple of files, for instance, while deploying a PHP/CGI application requires the installation of a whole tree full of scripts and programs. A small thing, but it makes a difference in the long haul.
So I think the combination of PHP and CGI is better than PHP alone, but still losing in comparison to J2EE technolgies.
CSV can have a header row which assigns names to the columns. This is equivalent to element names in XML. It is not correct that XML assigns meaning to data and CSV doesn't. The real benefit of XML, as I see it, is that while delimited files represent two-dimensional information (entity/attribute) XML can represent multi-dimensional info - an entity can contain child entities.
I can only think of two answers:
- The specific elements the Lispers are so proud of (s-expressions, etc.)
- The Lisp community had little interest in real-world needs, and did not evolve or promote Lisp as a solution to those needs. Those who evolved and promoted such solutions deservedly got the fame and market share.
The way I see it, the only way we are having this discussion at all is thanks to C, Perl, Linux, and possibly Microsoft (not on my end).are not the whole story. They are relatively minor constituents of these modern and popular technologies.
(* Maybe not in the Internet world, but for internal sytems within companys with heterogeneous applications, there is a great demand for it. We have a whole host of different applications written in a multitude of languages and running on a whole host of operating systems that need to communicate. Web Services offer a great way of doing this. *)
Why not either communicate via the database systems or regular HTTP Post and Get? Send some parameters, and get back the result in whatever format you like: comma-delimited, XML, HTML, BrainF*ck, etc.
Databases already offer queuing, contention management (multi-user), transactions, etc. Why find other ways to reinvent a wheel that you are already paying for in the DB?
Or even FTP for a third option. Between these 3, you have plenty of choice and approaches.
Web services has the same marketing foot that "push services" did. Fortunately, it was pushed into the dump. Somebody just wants to move boxes off the store shelves to keep their pockets fat.
Table-ized A.I.
Oh great! MS not only cloned Java, but also cloned the pattern of stupid, bloated, beurocratic Java error messages.
When MS wants to kill a company or technology, they get so hell-bent that they copy the stupid parts also.
I suppose they will now copy case-sensative file-names now that they also want to kill Linux?
Table-ized A.I.
Actually from my experience I would agree with the parent post. Perl is faster than blazes for string manipulations and file I/O functions which usually forms a significant part of most server side web applications.
I recently benchmarked an application that parsed large binary files, swapped bytes from big endian to little and sent the data out a socket to a remote application. I wrote the application in C and in Perl. Perl came within 5% of the performance of C, but the C program took me 3 times longer to write and debug.
For web applications check out the
Popular Perl Complaints and Myths Page
A quote from this reference:
Q: Perl had its place in the past, but now there's Java and Java will kill Perl.
R: Java and Perl are actually more complimentary languages then competitive. Its widely accepted that server side Java solutions such as JServ, JSP and JRUN, are far slower then mod_perl solutions (see next myth). Even so, Java is often used as the front end for server side Perl applications. Unlike Perl, with Java you can create advanced client side applications. Combined with the strength of server side Perl these client side Java applications can be made very powerful.
In reference to GUI's I just started playing with Perl/TK and was able to put together a short operator interface to view and filter a log file output. The application runs equally well in Linux, Windows and Solaris. I have not played with it enough to determine the weakness of the combination but first appearances are impressive.
Thanx for the link, but why I'm a fool?
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
(* 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. *)
That is not Java the technology, but:
1. The 'network effect' where the more people that use it, the more info there is on it. Sun is playing Microsoft's game.
2. Standard API's.
Why should standard API's be tied to any one language? What is needed is standard GUI interfaces, standard network interfaces, standard file system interfaces, etc. Then the language nor platform would matter. Python, C++, or FORTRAN could all talk to the same API's.
I know, other languages can still talk to Java API's through some fiddling, but the Java API's are optimized for Java syntax and design.
And, the run-time-engine thing does not mean much for server software.
We have plenty of languages already (viva choice). We just need standard protocols so that the OS does not matter for GUI's, etc.
Table-ized A.I.
(* I'm astounded by people who think XML is an acceptable language for writing code....*)
LISP fans have found out that simply by replacing the parenthesis with angle brackets in the interpreter parse rules, they can convince their PHB that they are "programming in XML", but really doing LISP.
They can then be "with it", AND use their favorite language (invented in the late 50's). Retro and cool.
Personally, I like the verbs to the left of the parenthesis....I mean brackets, but to each their own.
Try ColdFusion if you want one flavor of XML/HTML-like programming constructs. I cannot say I recommend it.
Table-ized A.I.
(* You just seem to be bitter because, apparently, you don't grasp the elegance of object oriented programming *)
There aint nothing to "grasp". There is no fricken good objective peice of evidence that OOP is better. Ed Yourdon's studies found it made no measurable difference. The only comparisons available are with rigged lame procedural/relational code.
oop.ismad.com
(* Let me see you design one good GUI based application with Perl, and see how well it runs on Windows/Linux/Solaris. *)
This has to do with API's, and not app OOP. There is the TK windowing kits. They are a bit kludgey at times, but so is Java's GUI under Windows.
BTW, I am not a perl fan.
Table-ized A.I.
(* It depends on what sort of data entry you're doing. In the example you cite, it seems that the user was well-versed in the system, and through using it frequently had become very efficient....For the casual user of such a system, things might be different. *)
I agree. An interface optimized for a skilled/experienced user may not be optimized for a newbie.
It is really hard to make an interface that is optimized for *both*. You usually have to pick a target audience, generally middle-of-the-road.
But, it is a problem that too many companies are trying to make web forms do complex stuff that is stretching the HTML/DOM/JavaScript standards way beyond their intention or naturalness.
I think there needs to be a new GUI standard or GUI Browser standard, something like XWT. (XWT promotes too much of a flat-client model IMO, but it at least allows having the server control most if wanted.)
Table-ized A.I.
(* using it as they realize exactly how powerful J2EE is for large distributed web applications. *)
Why do they need to be distributed if they are web-based?
I thot the idea of web standards is that it does not matter where the servers are. Thus, you might as well put them all in the same room to reduce/consolidate management costs of them.
Or, are you talking about B-to-B stuff? (In that case, use HTTP Get and Post. You don't need complicated Java crap for that.)
Table-ized A.I.
(* I often must rely on search, which can be very frustrating, where in Java I can use the type hierarchy *)
Sun's hierarchies often seem *arbitrary* to me. They stuck things places simply because they didn't know where else to stick them. I would rather search on keywords than traverse funky hierarchies and following dead-ends. Demeter lives!
(* Another thing is seen in much of the Java API: The API usually reflects the normal usage pattern. Creating either a server or client socket application is very intuitive in Java, but less so in C. *)
I find very little "intuitive" about the Java API's. I kept thinking of ways to rewrite them to make them "sane" the last time I tried to use them. Lets just agree to disagree and move on. Perhaps you just think like the Sun designers.
(* If you have a universal API, it often is slanted toward one language. *)
I don't know if this has to be the case. Unix-influenced protocols often use text as their transport mechanism so as to not tie things to particular binary representations. This is one of the reasons that HTTP and CGI can run on just about anything.
(* The Java API assumes object-orientation (of course) and is constructed accordingly. *)
What if OOP and/or Java fall out of style? You are dooming something to legacy-land faster if you tie it too closely to a given paradigm or language.
You don't think OO and Java are the pinnicle of programming, I hope.
Table-ized A.I.
Get your facts straight. One of the first high quality xml parsers was xml4j from IBM. I used it nearly four years ago. At the time there were very few xml parsers and Java was about your only option if you wanted to do XML.
.Net you only have one realistic option: visual studio.
A quote from the Xerces pages:
The Xerces Java Parser 1.4.4 supports the XML 1.0 recommendation and contains advanced parser functionality, such as support for the W3C's XML Schema recommendation version 1.0, DOM Level 2 version 1.0, and SAX Version 2, in addition to supporting the industry-standard DOM Level 1 and SAX version 1 APIs.
Note that because some of the standards are still not complete, the stable API will definitely be different from its current form in Xerces-J 1.4.4. This is your chance to give us feedback on the features that are important to you, and let us know whether the APIs that we are providing are the right ones. Please direct your feedback to the Xerces-J mailing list.
As you can see Xerces supports all the latest standards and even appologizes that some of the API calls will change because the standards are not stable yet. The moment these standards stabilize the 'mature' options you mention will of course suffer from the same problem. However, it wouldn't surprise me if xerces was updated first.
Regarding soap, there are many java implementations from, among others, apache and IBM.
So in reply to your comments, Java XML:
- Java usually is among the first languages to support XML related w3c standards. Third parties like apache and IBM play an important role here.
- Java is actually pretty damn fast (hence the popularity of server side Java).
- Very mature (see first two points)
- Standards compliant.
I fully agree with your comments regarding the necessity of IDEs. Though, given your comments about visual cafe it is very clear that you haven't tried any of the fancy Java IDEs released in the new milennium since VC is long gone (hint, try Idea or Eclipse for a change). Of course with
Jilles
Yes, I sense your fear, your fear of the bungus.
As to me, I don't believe anything. I *think* its okay to use superior tools, but I find it much more effective to simply describe their superiority, particularly when I raise my voice.
illegitimii non ingravare
If you want to use XML in PHP, then you may want to look here.
Phillip.
Property for sale in Nice, France