|
|
[an error occurred while processing this directive]
|
|
|
If you've been developing HTML using SilverStream for any length of time, you probably are very familiar with SilverStream Pages (Visual Servlets) and consider them the essential tool in your toolbox. You are also probably aware that, when they run in the server, the Pages are compiled into Java Servlets. You probably have also worked with Java Servlets directly - creating your own Servlets by hand. Because of my position with the Journal, over the past year or so I have had many people ask me many questions about JSP. Weekly, I receive a call from someone just wanting to chat about where I see the world going; whether they should write their application in Forms, in Pages, in handwritten Servlets; and for the past year, JSP has been added to the questioning.
I have become a firm believer that JSP is the best choice for the future and I am very happy that SilverStream has been so strongly committed to working with JSP. This article is the first in a series designed to get you started with JSP. To begin, I am going to answer the majority of questions that people have asked me, or that they should have asked! When you are done reading this article, whether you are a manager or a developer, I trust you will see that JSP is in your future - and that that is a good thing, not a bad thing.
So, without further ado, on to the questions.
 |
what does JSP do? |
|
|
|
|
Well, for starters, JSP stands for JavaServer Pages. Like SilverStream Pages, JSP is a means of creating Java Servlets. When a request comes in for a .JSP page, the server will call up the Java Servlet that answers to that page, and run it. If you look at a JSP page that is compiled into a Java Servlet, you will find it is "just" a plain old boring Servlet. The key is that it is easier to create and maintain the JSP than it is to create and maintain the Servlet.
|
|
|
how does JSP create Java Servlets? |
|
|
|
|
You start out by creating a text file, a .JSP file. This file contains a curious mixture of HTML and Java code. And for good measure it can, of course, consist of any other code that an HTML page might have, like JavaScript or other script language. From JSP's point of view, the JavaScript is just part of the HTML. Once this text file is ready, it is compiled; that is, it is translated from the JSP syntax, into another text file, but this text file is a Java Servlet which can then run on a Java Server - like SilverStream.
|
|
|
does JSP mean to replace SilverStream Pages? |
|
|
|
|
The answer to this question is easy. Yes! JSP is a direct competitor to SilverStream Pages. SilverStream the company, recognizes this and never saw this as a bad thing. The client side tools, like SilverStream Pages exist as a means of taking advantage of the Server, not the other way around.
|
|
|
Is JSP better for managers than pages? |
|
|
|
Yes! JSP is better.
- There are more and more tools being created that work with JSP (J2EE objects and toolkits). This provides low cost products, where the development cost can be spread over many projects and companies.
- The talent pool is greater. In my area of the world, the only talent pool that is larger is the ASP pool. Compare this to trying to find "SilverStream" developers. It is much easier to convince a Java/JSP developer to come work for your company when you tell them you are using Java/JSP than when you tell them you are using Java/SilverStream Pages or Forms.
- More flexibility in team management. It is much easier to have a variety of skills and levels of skills on a JSP-based project than it is on a SilverStream-based project. You can, for example, have a domain expert use a tool like Microsoft FrontPage. Then you can take an artistic/marketing person and have them further develop the exact same file. From there, a junior developer can take the HTML, add a few (or a lot) of lines of code, turning it into a JSP file. Finally, you have a senior/systems developer creating J2EE objects that will be called by the Java in the JSP file.
Also, see the advantages below for Developers and Entrepreneurs. I have put each advantage in the section where I see it has the most significant impact, but there is cross over among all three groups.
|
|
|
Is JSP better for developers than pages? |
|
|
|
- Yes. Years ago, when SUN was promoting "Write once, Run Anywhere" (remember the first few months of Java's popularity?), I coined a phrase in my company and the articles I was writing at the time "Write once, Write Anywhere." I never saw the ability of Java to be written once and run all over the place. I fully admit that Java came closer than any other tool I have ever used; it certainly beat C++ by a country mile. But Java never really, in my opinion, made the success of Write Once, Run Anywhere. But, back in those early Java days, I was able to have a developer work on a Java Applet to run in a Windows browser and, with very little work, modify it to run on a UNIX browser and a Mac browser. That same developer went on in the afternoon to write a Java function that would run inside a beta version of Adaptive Server Anywhere that we had in-house at the time.
JSP has similar advantages. If you write JSP, your skills will be useful no matter what JSP Server you are called to work on. SilverStream today, Sybase tomorrow, and who knows what else next week.
- This is very similar to the first point. I ran across many developers who developed using SilverStream in the daytime, but then for their personal work, or work for friends, had to use a different language/framework. They can now work in JSP at night as well as the day. A little bit less to be proficient in - better transfer of skills - translates into higher proficiency on the job and off.
|
|
|
Is JSP better for entrepreneurs than pages? |
|
|
|
- I'll bet you knew I was going to say "Yes" here! And you would be correct. The first benefit is the opportunity to produce tools that other companies can buy. Creating objects for SilverStream Pages did not garner much interest from entrepreneurs because there wasn't a big enough market to sell into. But with JSP, you have the SilverStream market PLUS you have 1000's of developers doing JSP for other platforms. A much bigger market and, therefore, much better opportunities for developers. If SilverStream (the company) doesn't build a tag library for DSO's, perhaps some enterprising entrepreneur will. Not only will it appeal to SilverStream developers, it would be of interest to many non-SilverStream developers.
- Ability to deploy on lower cost servers. Is this political suicide for me to suggest? No! SilverStream is clearly one of the best, if not the best high end clustering servers. Its performance is phenomenal. But here's the rub. Entrepreneurs, develop products that need to run on very small servers, supporting a very small mom & pop company with only hundreds of users, all the way up to very large companies with many thousands or tens of thousands of users. Let's be clear. SilverStream, the Server, is not a low cost Server. There are servers running as cheap as free (comes with the operating system). SilverStream knows it has one of the fastest, scalable servers and it charges a fair price for what it delivers. But SilverStream does not have a truly low cost option. I have personally come across at least several dozen companies that wanted to use SilverStream for development and deployment, but because they only wanted to create and maintain one product, they chose competing products. That way, they could sell the product to run on low cost servers all the way up to high cost, high performance servers. Unfortunately for them, SilverStream was never one of the options because of its proprietary framework. Now with SilverStream supporting JSP, these same people can add SilverStream to their list of recommended servers to run with their products.
- Ability to deploy on other people's pet server. While Oracle is languishing behind in performance (8x's slower - yes, only 1/8th the speed), there are some companies that insist on using Oracle. (FWIW, I think the reason Oracle is so slow can be found in one of their biggest marketing points. They make a big deal of how every session gets its own JVM. The problem here, is that there is therefore no sharing at the Java Server level. According to the sales rep I chatted with, every object's code is duplicated and compiled for every session. No wonder it is so slow!) But back to JSP. If you develop in JSP, you can use SilverStream for the servers where it makes sense, but your product can also run on other platforms. This may sound "bad" for SilverStream, but remember, prior to JSP, it made sense only to make tools for the competition; the SilverStream market wasn't big enough for this second industry effort. But now with JSP, it makes sense to make tools and resellable applications that can run on any J2EE compliant server.
|
|
|
If I'm going to switch from Pages, should I consider ASP as well? |
|
|
|
I guess you could. Personally, I am not that excited with the option. However, I know that several developers work with ASP for their personal use and for smaller clients.
The big advantage of ASP is that, for deployment, it is as close to free as you are going to get.
The second advantage of ASP is that developers are really low cost. In my area of the world, ASP developers cost about 1/2 what a JSP developer does per hour. But as a manager myself, there is a downside to this. The problem is that the majority of good developers use ASP only to learn, but then switch to the Java side to make more money. The result is that the majority of ASP developers available for hire that I have run across are "Juniors" in skill. (They may have 5 years experience, but in skill level they are Juniors.)
The biggest downside to ASP is scalability. With JSP, the programs are compiled once into Java, and then compiled once into machine code (or once per session if the server opens up a separate JVM for every session). After that, they run compiled. ASP is always interpreted one line at a time, every session, every time through that line of code even in a tight loop, every line is executed every time.
|
|
|
If I'm going to switch from Pages, should I consider Java Applets/Forms? |
|
|
|
|
Again, for most companies/people/projects, the answer will be no. It seems to me, with current bandwidths and current browsers (variety of versions, variety of vendors), that HTML and XML make much more sense for the vast majority of your programming. I know there are special cases where you need the more Client/Server type programs. But for the most part, Pages have been the better way to go and JSP is clearly the direction you want to go for anything where Pages made sense.
|
|
|
Is JSP Scalable in performance? |
|
|
|
|
Yes! Extremely scalable. From the very low end all the way up to the biggest UNIX or other boxes you need. And the scalability is going to continue to grow as manufacturers provide bigger and bigger horsepower machines with more and more CPU's. Not only that, but virtually any JSP server is going to run faster than ASP on the same server (since ASP has to interpret every line of code every time it is executed), and SilverStream in particular is the King on this front.
|
|
|
Is JSP Scalable in development? |
|
|
|
Yes, much more so than Pages. And in at least two planes.
In the first plane, we have teams of developers. In a small, pilot project, you may have as few as two people on the project, the domain leader and the development leader. (You might even just have one, the development person.) In this scenario, the domain leader can use FrontPage to draft what they are looking for, and the development leader fixes up the picky HTML details and implements the business logic.
In a slightly larger project, you add a person to worry about just the picky HTML details, making sure it works on all browsers/platforms that you want it to.
The nice touch here is that the HTML can be used directly from FrontPage. No need to regenerate a similar Page that recreates that HTML. When I work with Pages, I often have a non-developer mock up in FrontPage (or similar product), and then a developer recreates the same thing using the Page designer. With JSP there is no remocking. Tweaking? Yes. Adjusting? Yes. But the starting point is the HTML file, not a rebuilt file.
Then you add a class developer to work on building business logic classes. JSP is designed to have very little of the guts of the Java code in the JSP text file. The guts is the responsibility of a J2EE object. So this development can go on by separate people from those working on the JSP files.
Then you add a tag developer to build custom JSP tags (that, at the risk of oversimplifying), gives a more intuitive interface for the HTML developers to use the Java Class objects. Custom Tags look like HTML tags; they give the JSP a more HTML feel, while behind the scenes, these tags are used to access Java objects. Note that these tags do not end up at the client side. Where appropriate, the custom tags will produce proper HTML tags for the client side. So no special browsers are required.
You can then add one or more testers. Your current Pages testers have exactly the correct skills because from the testers perspective, there are no effective differences between a page generated by Pages and a page generated by JSP.
On the second plane, we can have developers in separate companies. As companies develop custom tags and custom tag libraries and J2EE objects, you can spend more of your time working on the specific problem domain and less time on the generic infrastructure. When the market for entrepreneurs was only SilverStream Page developers, there just wasn't enough market to justify the cost of producing shrink wrap quality products. But there are already companies developing and selling custom tag libraries. This means you have more tools available to you, many at very reasonable prices. And there will be more tools to come as JSP continues to grow in popularity. This clearly increases the scale of development that you can achieve and will be able to achieve in the future.
|
|
|
Is Java Dead now that Microsoft won't be in the family? |
|
|
|
The news of the settlement between Sun and Microsoft has lead many people to conclude that Java is dead. I'm more concerned about Java Applets than I am about JSP. Java Applets have had a hard time of it, what with version problems and different implementations of the JVM. Essentially put, the dream of write once, run anywhere was never achieved. Close. Closer than ever before. But not achieved. In fact, one of the big issues between Sun and Microsoft was over the extensions to the language that Microsoft was creating with the specific intention of making it easier to run Java on a Microsoft machine than on any other machine. The problem was that, if you took advantage of these improvements, you could not deploy to any non-Microsoft box.
With JSP, the incompatibilities lie mostly with the HTML browser, not with the underlying Java. Since the Java never makes it to the client side, all you have to worry about is the JVM you are running on your machine. We already have to worry about differences in HTML between Microsoft IE, Netscape (and to a lesser degree, AOL & all the other also-ran browsers). But even between different releases of IE or Netscape there are huge differences. Most developers, myself included, pick a percentage of the market they are willing to alienate, and then develop for browsers that the rest have. So in my case, I don't want to alienate more than 10% of my target market, so my projects all have to work with IE 4.0 and up. I'd love to be able to rely on some of the IE/Netscape 5.x features, but I am waiting (another year or two perhaps?) for 90% of my target market to be using 5.x up.
Most serious JSP developers on projects bigger than a Mom & Pop or pilot project are going to want to use a server like SilverStream. There are several good servers to use, a couple which are fully JSP compliant already (SilverStream 3.7.x being one), and more are coming. Yes, I know the argument that IBM may drop out of the race now that Microsoft is dropping. But I don't see SilverStream, Sybase or Oracle or other lesser known servers changing gears away from Java any time soon.
So, while I have been cautious about Java Applets for a couple years, and I am even more cautious of them now, I have no fear on the JSP front.
|
|
|
Are you happy with the change from Pages to JSP? |
|
|
|
|
Yes. There is a learning curve. I'm still involved in that learning curve, but I am fully convinced that this is the correct direction to go, and I am very thankful to SilverStream for boldly moving in this direction, as much as a year before I and others realized that it was the correct way to go.
|
|
|
|
|
|
