XML and Java, Developing Web Applications 295
| XML and Java, Developing Web Applications (2nd Ed.) | |
| author | Hiroshi Maruyama, Kent Tamura, Naohiko Uramoto, Makoto Murata, Andy Clark, Yuichi Nakamura, Ryo Neyama, Kazuya Kosaka, Satoshi Hada |
| pages | 661 |
| publisher | Addison Wesley |
| rating | 6.5 |
| reviewer | WrinkledShirt |
| ISBN | 0-201-77004-0 |
| summary | An ambitious book, covers a fair amount of material, but lacks continuity. |
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 Good
One 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-Good
It'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.
Conclusion
There'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 websiteW3C'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.
XML And Java.. (Score:2, Interesting)
Re:XML And Java.. (Score:3, Informative)
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.
Re:XML And Java.. (Score:5, Insightful)
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.
Re:XML And Java.. (Score:3, Informative)
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.
Re:XML And Java.. (Score:2)
J
Re:offtopic discussion (Score:2)
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.
Re:XML And Java.. (Score:5, Insightful)
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.
Re:XML And Java.. (Score:2)
Re:XML And Java.. (Score:2)
Unless, if course, you want to be able to read your code.
I'm astounded by people who think XML is an acceptable language for writing code or documents. Just as writing in pure HTML is only for the gearest of the gearheads (myself included), writing pure XML, or XML with embedded logic like XSP, is painful in the extreme.
It's really getting to the point where XML and its derivatives are write-only formats, suitable for machine-to-machine communication only. Hell, even Ant pisses me off with its XML syntax for makefiles. I miss make.
Re:XML And Java and LISP (Score:2)
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.
Re:XML And Java.. (Score:2)
You don't need OO to scale nor to "separate presention logic blah blah".
Good procedural/relational programmers can do all this as well or better than OOP.
Show me a single example (in code) of OO doing these better than p/r, and I will show you bad p/r skills.
Just because nobody cares about p/r software engineering techniques because it is out of style right now, does *not* mean it is not possible.
There is no evidence to support most OO claims. It just has better cliches, that's all.
oop.ismad.com
Re:XML And Java.. (Score:2)
Go to JobServe [jobserve.com] and see how many jobs are requesting Java. Go to JobStats [jobstats.co.uk] and see how much demand there is for Java. Admittedly the demand is down from a year ago, but that's across the board. Note that these are UK sites, but I don't see a geographical dependency.
Pretty much every IT consultant I know is concentrating on Java, and most of all in the J2EE and XML sectors. That's where the development work is here.
Re:XML And Java.. (Score:2)
PHP is nothing but a server-side scripting language. Don't get me wrong, this can be all that's needed for many web projects, but for enterprise-level web applications, it's totally insufficient. Furthermore, it's a scripting language that needs to be in the same file as the HTML code. This means the web designer and web developer will constantly be stepping on each other's toes. AFAIK, there are no hard-core object-oriented features in PHP.
Java, on the other hand, allows you to compartmentalize your HTML code, servlets, and server-side processes. It's much cleaner. Java's object-oriented, so it's far more maintainable than procedural code. Furthermore, it allows further encapsulation of different components of your application, components and code that can be reused across different applications and projects. For example, if you want to perform complex mathematical calculations, you can simply put these into a class and place that class into your general libraries, to be reused in another project.
We currently use XMLC, a set of tools that allow HTML pages to be converted into Java classes. These classes can be manipulated by servlet code, and finally changed back into HTML output to the browser. This allows a great deal of flexibility, and absolutely NO worries about parsing HTML. It's all done automatically. PHP doesn't offer that kind of functionality.
Servlets can be subclassed from the most general dynamic page-loading functionality to more complex, application-specific dynamic functions. PHP doesn't have that kind of functionality.
Furthermore, Java has a rich set of libraries for XML processing, whether you're using DOM or SAX. There are complimentary libraries such as Xerces and XMLC that provide even greater functionality.
Java and J2EE offer a wealth of tools for true, large-scale, enterprise application development. PHP does not, at least, not yet.
Re:XML And Java.. (Score:3, Interesting)
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.
Re:XML And Java.. (Score:2)
what exactly are the advantages you see that
Re:XML And Java.. (Score:3, Interesting)
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
Re:XML And Java.. (Score:2, Interesting)
Of course if you were that worried about speed, you would hand-assemble the lot- but who here has hand assembled server apps? I certainly wouldnt like to try.
As for PHP vs Java - I am sure both have their applications.
I am opposed to
Re:XML And Java.. (Score:2)
In the case of an e-commerce app a while back, we cached product info for the items in the cart. What if a price changed between the item entering the cart and checkout? We agreed that the customer should pay the "old" price. However, if the item was no longer available, the customer would have to be told.
The underlying mechanism of persistence is quite simple and can be implemented in any real programming language. I have no idea why anyone makes a big deal about it. Maybe I only think that because of the fluidity of Perl's data structures - it's a no-brainer for us to create arbitrary "trees" of data, serialize and deserialize them.
Re:XML And Java.. (Score:2)
Use the database as your persistence mechanism. Agreed, this won't scale to ebay-size, but that is usually not the target audience anyhow.
Store the screen "image" in the database, for example.
I would tell you to also toss OOP, but there are already plenty of flamewars over that topic right now.
I suppose which language/framework is "best" depends on programming style, application organization style, etc. Try both, and see which you feel the most comfortable with.
I sense a paradigm shift to XWT-like technologies anyhow, so HTML/web-centric stuff will probably have to be mostly tossed anyhow in a handful of years.
Fa la la la la, live for today.
XML+JAVA=wait in line for job (Score:2, Funny)
All you need. (Score:4, Informative)
Apache Java projects [apache.org]
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.
Agreed (Score:2)
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.
Re:All you need. (Score:2)
I don't really see that books are trying to make it look like that, but the reason you see the two things paired together so much is simple: Java is a platform-independent programming language. XML is a platform-independent markup language. They fit together perfectly.
...is love. (Score:2)
Pop quiz: Where does the term markup originate?
Re:...is love. (Score:2)
I prefer to see the scope of XML application as a broadening of the concept of publication rather than a narrowing of the idea of data.
Re:All you need. (Score:2)
Why? With platform independant data you no longer need platform independant languages. You can work with whatever language is easiest to use, or performs best, or whatever your particular criteria are for your project.
The only sense in which they fit together perfectly is in the minds of point haired managers, who completely suck in and accept statements like the above, without questioning their technical merit. In fact, in many ways XML obsoletes the need for languages selling themselves on platform independace.
Re:All you need. (Score:2)
Why? With platform independant data you no longer need platform independant languages. You can work with whatever language is easiest to use, or performs best, or whatever your particular criteria are for your project.
Yes, sure. And I recode my application to let it run on my Palm, because I have no
And then I recode my application to let it run on my mobile phone
Not to talk about the fact to reuse the code for my next enterprise wide project, which definitly is in Java, jsut like all Enterprise I'm involved with are in Java.
Oh, yes. Java runs on nearly all PDAs and on about 90 mobile phones.
Thats why portable data needs portable code, because I like to work with that data everywhere.
Probably you should start to think in "life" and not "projects". The projects in which one particular solution is the only possible/feasable are rather scarse. A nice Java component OTOH may get reused for the next 100 years (I saw COBOL code reused for >35 years
angel'o'sphere
You missed one... (Score:2)
information density (Score:2)
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.
Doesn't Make Sense (Score:2, Insightful)
As far as I can remember, JAXP has little or no implementation code.
Web services are like high school sex.... (Score:5, Insightful)
For good reason. There is zero demand for XML web services on the right now, no real support for security, and still-evolving standards.
Re:Web services are like high school sex.... (Score:5, Insightful)
I think there's zero business model, too. Say FooCorp offers stock quotes on its web site. There are a few business models for that, although some of them might not be all that great. You can offer the service for free, sell advertising on the quotes page, and cross your fingers.
But there's basically no model for web services other than pay-for-play. FooCorp could offer their quotes through a SOAP or XML-RPC service or something, but there'd be no way to get secondary revenue from it. They'd have to just charge for the content directly, which hasn't been a very successful model on the web so far.
The fact that Google offers a web services-style API is cool, but it's unclear to me exactly how it helps their business.
I'm just speculating here, but I think web services will be much more popular in intranets than in commercial settings on the web, assuming somebody comes up with something that can be done better with web services than with a regular browser-based web app or a Java app or something.
Re:Web services are like high school sex.... (Score:2)
But there's basically no model for web services other than pay-for-play. FooCorp could offer their quotes through a SOAP or XML-RPC service or something, but there'd be no way to get secondary revenue from it. They'd have to just charge for the content directly, which hasn't been a very successful model on the web so far.
One of the things Web Services are designed for is what EDI has been used for on private networks. The business model is "Ford says that if we aren't compliant they won't buy from us."
Furthermore, charging for content is very rare in the consumer web but not that rare in the commercial web. There are many extremely expensive newsletters (for example) that businesses are happy to pay for. Release 1.0, Gilder's rag, etc.
I'm just speculating here, but I think web services will be much more popular in intranets than in commercial settings on the web, assuming somebody comes up with something that can be done better with web services than with a regular browser-based web app or a Java app or something.
There is really no comparison with browser based apps. Web services are for solving problems that cannot be solved with browser based apps because they do not involve human interaction. You cannot integrate CRM and accounting systems with a browser-based app.
That all said, I happen to think that current web services standards are poor. The problem domain is real and there is real money in it. The proposed solutions are lacking.
Re:Web services are like high school sex.... (Score:2)
Okay, that's a good point. I was only thinking of using web services protocols for connecting desktop applications to server applications. Connecting two server applications together with web services makes a lot more sense. Thanks for the clarification.
Re:Web services are like high school sex.... (Score:2)
Okay, that's a good point. I was only thinking of using web services protocols for connecting desktop applications to server applications. Connecting two server applications together with web services makes a lot more sense. Thanks for the clarification.
The name of the technology sort of invites confusion. Most people seem to agree that the name is more obfuscating than clarifying but nobody has the ability to change it!
Re:Web services are like high school sex.... (Score:2)
No one is disputing that RPC over the wire has its uses. The point is that no one seems particularly interested in replacing CGI,CORBA,EDI or whatever they are using already with a half baked set of standards.
Furthermore, charging for content is very rare in the consumer web but not that rare in the commercial web. There are many extremely expensive newsletters (for example) that businesses are happy to pay for. Release 1.0, Gilder's rag, etc.
What does this have to do with web services? These are print newsletters.
There is really no comparison with browser based apps. Web services are for solving problems that cannot be solved with browser based apps because they do not involve human interaction. You cannot integrate CRM and accounting systems with a browser-based app.
How do web services solve this problem? Web services only expose existing functionality in a new way. You either have the code available or not. The transport and negotiation methods are not the limiting factor. Once again, there are already standards for doing this stuff.
Re:Web services are like high school sex.... (Score:2)
No one is disputing that RPC over the wire has its uses. The point is that no one seems particularly interested in replacing CGI,CORBA,EDI or whatever they are using already with a half baked set of standards.
First, if you think that the web services standards (half-baked though they are) describe "RPC-over-the-wire" then you are quite out of date with respect to the standards. Second, the original poster argued that there is no *problem domain* for Web services. But businesses would demonstrably love to rip out EDI, which relies on proprietary networks and inscrutable, poorly extensible file formats and CORBA, which was never adopted by Microsoft systems and did not make serious inroads onto the mainframe or into the APIs for enterprise software applications. (does SAP expose CORBA interfaces? Siebel? JD Edwards?) The point of a standard is standardization. There are twenty different not-bad ways to do middleware. That's precisely the problem. Metcalfe's law only kicks in when there are one or two dominant ways.
What does this have to do with web services? These are print newsletters.
The point is that businesses will not hestitate to buy content, even if consumers will not. If constantly knowing the price of wheat in China is important to your business, you will happily buy that information from someone and will be doubly happy if the feed is using standardized formats rather than ad hoc ones. If you want existing examples, look at the billion dollar businesses dominated by Reuters and SWIFT. Those guys are moving to XML-based technologies. (I don't know for sure whether SOAP/WSDL)
How do web services solve this problem? Web services only expose existing functionality in a new way. You either have the code available or not. The transport and negotiation methods are not the limiting factor. Once again, there are already standards for doing this stuff.
Standards nobody is using. Neither CORBA nor EDI are widely deployed at even a fraction of the businesses in North America. Part of it is their technological approaches. Part of it is politics.
I am not claiming that SOAP/WSDL will necessarily succeed. I am making the point that there is in fact a multi-billion dollar pie sitting on the table and there is no question why major software companies want to try and cut it up.
Re:Web services are like high school sex.... (Score:2)
Just for the record, no I didn't. (And neither did the guy above me. I'm not 100% sure who you're calling ``original'' here.)
The guy above me said that there's no demand for web services implementations or applications. I said there's no business model for using them, either. You pointed out that there are software-to-software applications for web services technologies that I hadn't thought of, which I concede, but I'm still not sure that means there's a B-to-B or B-to-C business model that requires them.
Note that I'm not talking about the same thing you're talking about. You're talking about problem spaces. What can we use web services technologies for? I'm talking about business cases. What can we do with web services that will either be profitable by itself, or enhance our profitability in some indirect way? These are two really different things.
Often technologies fail not because they themselves are inferior, or because nobody understands how they could use them. They often fail because nobody understands why they should use them.
Just clarifying my position a bit.
Re:Web services are like high school sex.... (Score:2)
I said there's no business model for using them, either. You pointed out that there are software-to-software applications for web services technologies that I hadn't thought of, which I concede, but I'm still not sure that means there's a B-to-B or B-to-C business model that requires them.
But what does that matter? What business model follows naturally from relational databases? What business model follows naturally from C++? Web services are a technology. When the technology matures, most people will use them to support their existing business models, not to create new business models. Whatever your business, you can use them to integrate legacy systems, purchase syndicated content (like a Reuter's feed) in a standardized form, lower the cost of EDI and get more partners into the EDI game, etc.
Since when do technologies have to support a new and innovative business model?
Re:Web services are like high school sex.... (Score:2)
You're kidding, right? Maintaining large sets of textual information is one of the oldest problems. Companies expend a metric assload of time and effort managing their information stores, from accounting to inventory to HR and on and on. Relational databases, with a few additional bits like form builders and report generators, let companies do that more efficiently. Instant ROI. That's a really clear business case.
What business model follows naturally from C++?
That's admittedly harder to define, but C++ is more abstract than web services technology is. Web services technology is, fundamentally, about exchanging information or commands between two applications over a TCP socket. Everything else is just the specifics of the standard(s). This naturally raises the question, ``Why do you want to exchange data or commands?'' To this question, there are lots of answers. But I can't readily think of a situation in which we need to exchange data or commands between two computers or two programs but can't yet because we don't have a technology for doing so. So the real question behind web services is this: ``What am I doing right now that can be significantly improved with web services technology, in some way that increases my efficiency, or that directly generates a profit for me?''
The direct route would be to use web services technology to offer new services for sale to customers. We've already beaten that dead horse; the bottom line is that companies aren't really rushing to offer for-pay services based on these new technologies.
The indirect route is what we're really talking about here. What can web services technology give me that will improve the way I do business and help me make more money? All of the examples you gave, ``integrate legacy systems, purchase syndicated content (like a Reuter's feed) in a standardized form, lower the cost of EDI and get more partners into the EDI game, etc,'' are already being done on large scales with other technologies. So one is left wondering how, exactly, web services technology will help anybody do those things better than they're currently doing them.
That's what I'm getting at. If an employee came to me and said, ``Let's deploy web services!'' I'd have to ask why. What potential gain can justify the expense and effort required to deploy that kind of technology in place of some other technology that we're already using now.
I guess I just don't see the problem that web services technology is trying to solve.
Re:Web services are like high school sex.... (Score:2)
You're kidding, right? Maintaining large sets of textual information is one of the oldest problems. Companies expend a metric assload of time and
effort managing their information stores, from accounting to inventory to HR and on and on. Relational databases, with a few additional bits like form
builders and report generators, let companies do that more efficiently. Instant ROI. That's a really clear business case.
"do that more efficiently." Web services are intended to allow you to connect disparate systems together _more efficiently_. This is also one of the oldest problems. To me, it therefore has a very clear business case.
All of the examples you gave, ``integrate legacy systems, purchase syndicated content (like a Reuter's feed) in a standardized form, lower the cost of EDI and get more partners into the EDI game, etc,'' are already being done on large scales with other technologies. So one is left wondering how, exactly, web services technology will help anybody do those things better than they're currently doing them.
Before there were relational databases you could manage data also. But what made relational databases so interesting was a *standard model*, *standard syntax* and *standard API*. STANDARDS. There are all kinds of ad hoc ways to glue shit together. To a corporation, "ad hoc" means "expensive" because there are no economies of scale. The HR system uses CORBA, the CRM uses COM and corporate developers must be expert in both of them to build the bridge between them.
Web Services do not allow you to do anything that you couldn't do before them. Standards never do. There was distributed hypertext before the Web and databases before SQL. But when you move to standards you get huge economies of scale and Metcalfe multipliers. That said, the standards have to be right, and today they are not.
What potential gain can justify the expense and effort required to deploy that kind of technology in place of some other technology that we're already using now.
If you deploy it as a replacement for one other technology you were already using you probably don't get much benefit. If you deploy it as a replacement for six or ten or twenty different ways of sending data over sockets then you've got an economy of scale. That's a huge opportunity. Even though I'm not a big fan of RPC, I can see that there is no good reason to have four or five different and incompatible ways to do RPC. But I think that if you go BEYOND RPC you can actually get even greater economies of scale.
Re:Web services are like high school sex.... (Score:2)
Microsoft has enormous clout with software vendors. If every ERP/Accounting app supports the exact same protocols, the impact will be huge.
Re:Web services are like high school sex.... (Score:2)
Salon did $1.1M selling subscriptions with over 30,000 sales. Sounds successful to me.
Now, because they SPENT $75 million, doesn't mean that people "won't pay for content." (Web myth #47)
Re:Web services are like high school sex.... (Score:2)
First of all, it's pretty silly of you to jump from my ``charging for content hasn't been a successful business model'' to ``people won't pay for content.'' These are two entirely different things.
But besides that, I'd say Salon's situation proves my point, not disproves it. Selling subscriptions hasn't helped them break even, so that model has, so far, not succeeded. That's the goal of a business model, after all: to either enable you to break even, or, preferably, make a profit. Salon hasn't done that. QED.
All of this is being written, by the way, by a guy who signed up for a Salon Premium subscription over a year ago.
(Uh-oh. OSQ coming on. Homer: ``Would you look at those morons... I paid my taxes over a year ago!'')
So, you see, the body of evidence available to us would suggest that the idea that the idea that people won't pay for content is a myth is, in fact, a myth. ("Huh?") Most businesses that have tried to turn pay-for-content into a profitable revenue model have failed to do so. So while it's not literally true that people won't pay for content under any circumstances, it's thus far been true that people won't pay in sufficient numbers or at sufficiently high rates to make selling content a profitable enterprise.
Re:Web services are like high school sex.... (Score:2)
Yet they are often confused, and not always inadvertently. A lot of people screech "greedy company!!" when all businesses are trying to do (usually) is provide better service at a lower price.
Selling subscriptions hasn't helped them break even
That's the difference. In other words nobody is getting filthy stinking rich off selling content. Whole different question.
That's the goal of a business model, after all: to either enable you to break even, or, preferably, make a profit. Salon hasn't done that.
Because they overspent. Their problem exists somewhere between the top line and the bottom line (where middle management spends, what a surprise).
it's thus far been true that people won't pay in sufficient numbers or at sufficiently high rates to make selling content a profitable enterprise.
Because Salon's overspending is not limited to Salon. We've all watched the Aeron chair stories.
People will pay for good products, no matter where or how they are made available. Businesses that overspend do not necessarily speak to the quality of a business model.
Re:Web services are like high school sex.... (Score:2)
People will pay for good products, no matter where or how they are made available.
While your statement sounds reasonable enough, I'm not sure we can jump to that conclusion. Can you name one non-informational content company that has broken even or made a profit selling their content through the Internet? By saying ``non-informational'' I mean to exclude companies like WestLaw; their business model is very clear and very solid. But I'm talking about content for which there isn't a fixed demand, like news or entertainment information for the mass market.
Companies like Conde Nast make a decent profit (as far as I know) publishing and selling magazines. Has there been any similar venture that has used the Internet as a delivery channel?
Re:That's not the business model (Score:2)
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.
Re:Web services are like high school sex.... (Score:2)
Yes, and everyone pretends to know all about it.
Microsoft of course is strutting round the playground saying they know how to do it better than anybody.
I still have difficultly explaining to clients what "web services" actually are, and I've been in this industry 10 years now.
I had it once... (Score:2)
Re:Web services are like high school sex.... (Score:2)
And as for security, proper web servers tend to provide security mechanisms which prevents unauthorised users from accessing the url that the service is on.
Re:Web services are like high school sex.... (Score:2)
Well if your services are internal-only, you don't need any security at all, you can simply threaten miscreants with disciplinary behavior.
For web services that exist on the open web, yes, your web server had better provide some security, because you've just routed around your firewall and pointed RPC calls directly to port 80. Even then you still don't have an inherent model for validating users/bots. There is a great deal already written about web services security issues, some good stuff by Schnier. I recommend reading it.
Re:Web services are like high school sex.... (Score:2)
Yeah, right. Which company do you work for? Is this the security policy that you implement for internal systems? Most hacking/misuse of systems happens from internal users. If you have no authentication mechanism, then how do you know who to discipline?
because you've just routed around your firewall and pointed RPC calls directly to port 80.
I don't know how many times I've seen this theory that Web Services have to run on port 80. They don't. They don't even need to run on via http. To quote from the W3C [w3.org] -
Web service
[Definition: A Web service is a software
application identified by a URI, whose interfaces and binding are
capable of being defined, described and discovered by XML artifacts
and supports direct interactions with other software applications
using XML based messages via internet-based protocols]
And in case you want to know what a URI is, again from the W3C [w3.org] -
Every resource available on the Web -- HTML document, image, video clip, program, etc. -- has an address that may be encoded by a Universal Resource Identifier, or "URI".
Other schemes you may see in HTML documents include "mailto" for email and "ftp" for FTP.
You can have a Web Service running via email if you want. I know I talked about Web Server security in the original post, but that was to show that you can implement Web Services (reasonably) securely, within a corporate environment, using built in security.
Anyway, a Web Service is not inherently any less secure than a web page. It depends what you let your service do. Every call to a URL is a call to some function or other on your web server. When you are filling in a web site application form and press submit, the URL that the POST gets sent to is a form of remote method. You can provide Web Services that offer exactly the same functionality that was available through passing POST parameters on your web page. This does not open up any security holes that were not already there. It is perfectly possible to build a web service that opens up huge security holes in your system, but then it's just as easy to build a web site that does the same thing.
Remember the "Push Services" fad? (Score:2)
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.
Re:Web services are like high school sex.... (Score:2)
Your web services code will pile up there beside their failed ERP, CRM, CMS projects as another testament to the power of tech hype.
J2EE and XML for free. (Score:2, Informative)
You can also get a full copy of Bitter Java [slashdot.org] there.
Java is Beautiful (Score:5, Insightful)
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.
Re:Java is Beautiful (Score:2)
The
Go-Mono [go-mono.com] is an open-source, GPL implementation of the
Microsoft had Corel and some of their researchers in Cambridge, UK, develop a clean-room implementation of the
MS has said that it will discuss commericial licenses of Rotor.
If there is sufficient demand,
I don't think
A software world where your main choices are
But, it's equally absurd to think that Java will kill
Anti .NET evangelizing tips (Score:4, Informative)
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 [mortbay.org], a lightweight but powerful persistence solution like Hibernate [sourceforge.net], and you've got a kick-ass application development and deployment solution. Powerful open and extensible IDEs abound, with Eclipse [eclipse.org] 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.]
Re:Java is Beautiful (Not) (Score:2)
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.
Re:my experience with dotNet (Score:2)
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?
Python and XML are a better match (Score:2, Interesting)
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.
Go back a little more... (Score:2)
Exactly, and that would be Perl on Unix. That got it right before Microsoft knew there was such a thing as HTTP.
Remember... (Score:2)
I like the Java language ... but ... (Score:2)
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.
Re:I like the Java language ... but ... (Score:2, Interesting)
For a "server-side" JVM, check out BEA's JRockit [bea.com]. I it is available as a free download [bea.com] (registration required). Right now it only runs on Intel boxes (Linux and Windows) though.
Re:I like the Java language ... but ... (Score:3, Interesting)
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.
Buzzword Compliance That Will Impress Your Manager (Score:2)
One 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.
It speaks volumes that the first sentence of the section on "The Good" concerns "buzzword compliance" that will "impress your manager".
One of the best software engineers I know, who has been writing Java for years and has extensive and ongoing experience with other platforms as well, has said working on Java projects makes him suicidal.
With indicators like the above, I can see why.
Re:Hey old timer (Score:3, Funny)
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".
Re:Hey old timer (Score:2)
Re:Web Applications (Score:5, Insightful)
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.
Re:Web Applications (Score:2)
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.
Re:Web Applications (Score:2)
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.
Re:Web Applications (Score:2)
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.
Re:Web Applications (Score:2)
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.
Re:Web Applications (Score:2)
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.
Re:Web Applications (Score:2)
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.
Re:Web Applications (Score:2)
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?
Re:Data Entry (Score:2)
Re:Web Applications (Score:2)
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.)
Java combo boxes (Score:2)
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.
Re:Web Applications (Score:2)
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.
Re:Web Applications (Score:2)
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.
Re:java the best server side platform. (Score:2)
Re:4.5 Stars at amazon.com, $34.99 (Score:2)
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.
There is no new truth. (Score:2)
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?
Re:There is no new truth. (Score:2)
XSLT, hype to the contrary, does not pretend to be a complete language. It is a simple way to build data-driven, recursive evaluations for the application of alternative markup templates. *MARKUP*. It's a publication system.
If you could see the forest for the parenthesis, you could appreciate seeing good ideas finding new life in new clothes. What the hell does syntax have to do with it, piss-poor or otherwise?
Re:There is no new truth. (Score:2)
My point along has been it is neither _new_ nor _better_, merely useful. What do you _really_ want to do today?
Java static typing an asset for corporate dev. (Score:2)
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.
Re:Java static typing an asset for corporate dev. (Score:2)
But the way I think Perl solves this is with the Package namespace. Variables generally stay in their packages, which should be kept small, or at a lower scope. Of course I have seen plenty of awful older Perl where global variables ran from file to file like wild animals leaving chaos in their wake.
Anyhow, if there is a benefit to typing, the types furnished by Java are not very useful to business apps. Sure, it's nice to distinguish a float, int and string, but how about a zipcode, account number, iso country code? The only way to achieve that level of typing (in Perl and I guess in Java) is to make the variable an instantiation of a class which overrides the assignment operator. For some reason, this hasn't felt worthwhile (I guess because we haven't encountered the Vlad/Raji error above).
But another reason is that we try to keep code generic. There's not likely to be a $zip_code variable in much of my code, because zip_code is just one field in a table. Dynamic typing allows Perl data structures to effortlessly reflect info from databases. For example, several XML APIs I've written perform a SELECT, compute some derived values, and return the whole thing as XML. If columns are added to one of the tables in the SELECT, my code is not affected. Casting todays schema in concrete is not a smart move for maintainability.
Re:Java static typing an asset for corporate dev. (Score:2)
By supporting the definition of types as distinct from any implementation (these are called interfaces in Java), and by checking the types of variables and assignments at compile time, an entire class of errors is caught at compiel time instead of runtime. It's not just about floats and strings, it's about every data type in the system, including complex business types, and every variable in the system, which must have a declared type, and the fact that the integrity of the relationships between values and variables is validated at compile time.
Providing the compiler with all this additional info - specifically, about the types of all your variables - then buys a number of additional capabilities. Your tools now "understand" your code much better, which allows automated refactoring - many Java IDEs support dragging and dropping of methods between classes, classes between packages, renaming of methods, etc., automatically updating the references to those entities as appropriate, because it can tell absolutely where all those references are, which is close to impossible with dynamically typed systems (with the partial exception of academic "soft typing" systems).
So when you talk about "casting schema in concrete", the surprising result is that the dynamic languages can actually end up *less* flexible than a statically-typed language. Take method renaming as an example. If you want to rename a method of a particular class in a dynamically-typed language, no tool can do that for you automatically, because in a reference like "obj.foo()", it's impossible to reliably tell what type "obj" is, and you can't simply rename every "foo" throughout the system, since some of them may belong to a different class than the one whose method you're trying to rename.
In a statically typed language, the type of every variable is known, and this kind of renaming and other refactoring can be performed automatically and reliably throughout a system. In addition, in cases where a refactoring requires some manual changes, the areas requiring changes generate compiler errors, so are clearly identified; again, a dynamic language can't do this, except by crashing at runtime. Static typing allows refactoring to become automated and reliable, which improves the maintainability and flexibility of systems.
BTW, as for generic code and reflection, it's not uncommon to use reflection in Java to map database or other data to Java objects; and interfaces provide a very powerful mechanism for developing generic code in a statically typed environment.
Understand I'm not dissing dynamic languages. I'm a heavy user of a number of dynamic languages, and have developed products for and with dynamic languages. I love the flexibility and ease of prototyping that they provide. However, I am pointing at that there are pros and cons, and that the heavy use of Java in the corporate world is not at all irrational - there are good reasons for it. Another way to think about it is that the type annotations in a program are a kind of documentation that's guaranteed to be in sync with the code.
If you're interested in furthering your education as a programmer, I'd strongly recommend adding a full understanding of static typing to your repertoire. If you can't bring yourself to learn Java in depth, take it to the next level and look at some of the polymorphic type inferencing languages, like Haskell, ML, or OCaml, all of which have the benefit of teaching important functional concepts also. For more rigorous academic coverage of types, check out the book "Types and Programming Languages" by Benjamin C. Pierce.
Re:Java static typing an asset for corporate dev. (Score:2)
Java is not a reinvention of UCSD Pascal. One of the things that's new about Java is the combination of object-orientation (not in Pascal), with interfaces separable from implementation, with static typing, running on a bytecode interpreter which supports runtime loading of modules. This combination is actually quite unique. I don't doubt there are systems, probably academic, that did something along these lines previously, but there's Java was the first to make any kind of impact.
Frankly, if it's anything more than simple trolling, I don't understand the kind of mindless language evangelism that leads someone to try to dismiss a successful language as containing nothing new or no new ideas. This simply implies you don't have very much experience with different languages to realize that there are no perfect languages, everything is a tradeoff, and most languages have some unique strengths and weaknesses. I mentioned Guy Steele in a concise attempt to encapsulate this idea, since he's demonstrated an understanding of these kinds of issues and has created two very different, successful (in different ways) languages.
I said all of those were reinventions (to a certain degree) of Lisp.
Your qualification there is all-important. Reinventing something "to a certain degree" but adding new functionality, like static typing, is not reinventing, it's building on what's come before, which is how nearly all technological and academic progress occurs. Java represents such progress, even over Lisp. No, it doesn't address every niche that Lisp addresses (which is why I use both Scheme and Java myself), but Lisp doesn't address every niche that Java addresses, either. Are you quite sure your reinvention meme isn't simply annoyed FUD, driven by a prejudice against the unfamiliar?
Re:Not Invented Here.. (Score:2)
Re:Not Invented Here.. (Score:2)
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.
Re:A few facts (not that you all care about facts) (Score:2)
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
Re:A few facts (not that you all care about facts) (Score:2)
angel'o'sphere
Re:A few facts (not that you all care about facts) (Score:2)
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..
Re:A few facts (not that you all care about facts) (Score:2)
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...
Re:Java vs .Net (Score:2)
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
Re:Ummm (Score:2)
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 [apache.org]
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.
Re:Ummm (Score:2)
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.