Building Java Enterprise Applications Volume I: Architecture phần 8 pps

Building Java™ Enterprise Applications Volume I: Architecture

182

standard programming techniques using documented APIs are in play. Again, some rather

simple (and logical) decisions early on can greatly increase the flexibility of your applications

in the long run.

10.2 Decision Point

I don't want to leave you completely on your own in terms of what to program next.

Obviously, you need some sort of user interface on top of the infrastructure put together so

far, and of course it needs to fit in with the architecture described up to this point. The two

most common application front-end paradigms, as of this writing, are the standard web

application (servlets, JSP) and the web services framework (SOAP, UDDI, WSDL). I'll

briefly touch on each. This will also give you some insight as to what the next volumes will

cover.

10.2.1 Web Applications

A web application, in the context of this book, is meant to refer to a J2EE-centric application

programming model. This means that servlets are used for application logic, and either

provide presentation on their own or defer to some other presentation technology. Popular

options in this area are JavaServer Pages (JSP), frameworks like Apache Turbine

(http://jakarta.apache.org/turbine), and Apache Cocoon (http://xml.apache.org/cocoon). While

these are just a few of many examples for handling content and presentation, they all build on

the J2EE core APIs (usually servlets), and well-understood Java and XML APIs like SAX,

DOM, and JDOM.

If you don't know what type of front-end you want to provide to the end user, this is almost

certainly the best choice. It is the most common, and as a result you can easily find resources

on the relevant technologies. Books like Java Servlet Programming and JavaServer Pages

(both from O'Reilly) provide good introductions to these APIs, and will get you quickly up

and running. Additionally, building web services and other front-ends can most easily be done

upon an existing web application. And, obviously, a web application provides access through

any standard web browser, as well as providing easy inroads into web-enabled phones, PDAs,

and other mobile devices.

If you do decide to move into the web application world, you should employ the same

principles endorsed in this book. Start with a layer for application logic, using servlets. Ensure

that any content is handled independently of presentation details, so the same data can be

shown to an HTML browser, an XML viewer, or a WML phone; this is in the same vein as

the clean separation of data and business logic detailed in this book. From there, move into

presentation technologies, and try not to code in such a way that only specifically formatted

content is accepted. In other words, developing an engine for converting data into presentation

is a better idea than simply taking very specific data and creating a very specific screen for

viewing. I will focus on these very ideas in Volume II of this series, Web Applications.

10.2.2 Web Services

Coming in a close second to the traditional web application is the web services paradigm. I

should start by saying that web services are still young enough that any predictions here or

anywhere else are just that: predictions. Don't depend on them, as things could easily change a

year, a month, or even a week from now. That said, it does appear that web services are going

Building Java™ Enterprise Applications Volume I: Architecture

183

to play an important part in the next generation of web-enabled applications. The emergence

of semi-standards like WSDL and full-blown standards like UDDI and SOAP offer a lot of

promise to a higher degree of application interoperation than what is currently available.

If you do want to web-service-enable your application, you should probably start by adding

some application logic on top of what was discussed in this book. Remember, the more

context you can add to your data, the more useful it becomes to other companies. A book is

more useful than a collection of titles and ISBN numbers, and a "library" (in some object

form) is generally more useful than just a book. Although it is certainly possible to expose

EJBs directly as web services, it is generally a better idea to add some layer of functionality

on top of these beans.

You should also begin to dig into the various web services specifications, like SOAP and

UDDI. You may also want to check out related books, like Programming Web Services with

SOAP (O'Reilly), a language-independent look at web applications, and Java & XML

(O'Reilly), which covers SOAP, WSDL, and UDDI for Java specifically. You can also find

example code online at locations like http://xml.apache.org/soap. Many application server

vendors, like BEA Weblogic and Lutris Enhydra, also offer web services "packs" or add-ons

to their server products, which provide tools to aid in conversion from beans and Java classes

to web services. I won't cover web services in detail until Volume III of this series, in order to

let some of the glitter shake off the paradigm in favor of stability and proven techniques.

10.3 What's Next?

Despite all of the information covered, it can still be confusing to decide what to do next.

With over a thousand lines of code in this book, you still do not have a complete application.

And while I hope you pick up Volume II of this series when it becomes available, I certainly

wouldn't advise you not to press on in the interim. So, in closing, I want to provide some

suggestions on how to proceed in your enterprise application programming.

First, take some time to understand the supplemental code in Appendix E. While I didn't

cover all of this in detail in the various chapters, there is quite a bit of information stuffed in

between curly braces and brackets. The code (particularly when downloaded from

http://www.newinstance.com/) is loaded with comments and Javadoc, and illustrates some

concepts in addition to those explicitly covered in the text of the book. You can also gain a

good bit of insight about container-managed persistence in EJB 2.0, the nuts and bolts of the

Java Message Service and message-driven beans, and more. I've included all of this code in

printed form in Appendix E, so take advantage of the listings.

Next, try to find something at your job to apply these concepts to. Your own assignments in

the enterprise application space should allow you a test bed for the concepts mentioned here

and for techniques of your own. My ideas all stem from actual problems I've had to solve; you

should assemble your own toolkit of similar ideas and programming idioms. In other words,

practice makes perfect, and you need to do more than simply read through this book to master

application programming in Java.

Finally, don't wait on a book to start building out your application. Develop a servlet front￾end, code up some JSPs, or delve into web services, using either the Forethought backbone or

an application of your own. This will put you ahead of those who won't venture into new

territory without a roadmap, and you may find yourself teaching them before long. Future