Java Development News:
TheServerSide at JavaOne 2005 - Day 2
By Floyd Marinescu, Frank Cohen, Doug Bateman, Adib Saikali, Nitin Bharti and Joseph Ottinger
07 Jun 2005 | TheServerSide.com
Day two of Java One contained a lot of focus on getting things done - implementations, networking, with a focus on architecture as well. In many ways, it was very similar to Day One, but moved faster in part because of accumulated momentum. Bookended by keynotes from BEA and Oracle, end-to-end development and deployment cycles were covered - and, of course, after the "formal day" had ended, there were some great parties and other, more formal, get-togethers.
The keynote began on a mildly more subdued tone compared to Monday morning, possibly due to all the hangovers people experienced from the night’s festivities before. John Gage began the morning session listing some of the most popular sessions from the day before, measured by attendance.
Surprisingly, the most popular session was on JBI, followed by Java Puzzlers, and the session on Mustang and Dolphin that TSS covered yesterday.
But the morning was Scott McNealy’s, who began the morning announcing that Sun had just purchased integration vendor SeeBeyond, for 387 million dollars. Jim Demetriades, CEO of SeeBeyond was brought to stage to explain what’s going on. SeeBeyond is an enterprise application integration software vendor, maker of ICAN which is a composite application orchestration/SOA server. ICAN works on windows, mainframes, Linux, etc. It can combine services across modern and legacy systems into new flexible workflows.
Scott McNealy then did his annual look at how Sun and Java is doing, recounting various metrics important to Java. There are 4.5M Java developers in the world, according to Sun’s latest figures. There are 550 Java user’s groups world wide. There are 912 members of the JCP (why aren’t you a member yet?). There are 1.5 billion Java Card’s deployed worldwide. 18 java.net communities, 150,000 java.net members. 28 unique J2EE appserver vendors. 78% of all handsets in 2005 ran up to 45,000 Java programs. “The Java Community Process is a very special innovation, a very special model. I would argue in many ways that it is the most successful community development model out there”.
McNealy later spoke about unique problems in the healthcare space. “If there was ever a need for an SOA based, JBI solution, it’s the whole healthcare IT environment”. Sun has been working on HL7 Java special interest group, focused on message and data exchange between hospitals. Following up on the “growing crisis” in healthcare, a video was shown of Brazil National Healthcare system. Brazil offers free healthcare to every citizen. Each citizen in Brazil has a unique identifier, allowing them to be tracked in any medical institution. The ID gives access to a database showing all patient history. The healthcare system is based entirely on J2EE – it’s platform independence being the main reason for choosing it, as well as Java’s security features.
Fabiani Nardon, CTO of the Brazilian national health systems was invited up to the stage. She mentioned how easy the system to use. No matter where you are in Brazil, you just present your ID and your medical database will be available. She mentioned how many people can now get instant consultations, where in the past it would take over 3 months. 2.5 million lines of Java code were written over a 4 month period to make the system work. She mentioned that their entire system is open source, allowing other countries to easily adopt and begin using it.
Scott briefly mentioned a number of other initiatives to look at, including GELC, a Java.NET community focused on open sourcing free and available kindergarten throughy grade 12 educational curriculum. It would one day have tests, text books, educational materials, all online. Scott layed down the vision of how cool it would be to have a JCP-like community process where the best minds in the world get together to create the best educational materials, which would save a lot of money for students anywhere in the world.
The keynote concluded with a special Dukie lift time achievement award to James Gosling. The award was a surprise to James, who blushed after they put up a video in tribute to him. The hero worship was oozing, with a number of people singing praise to James in the video. Where is Hani Suleiman when you need him?
Weblogic Server 9, Diablo
Gary McBride pitched WebLogic Server 9 is as featuring an Enterprise grade kernel. The kernel allows very high failover capabilities, the ability to do a live upgrade of a new application with two versions running simultaneously while the new version phases out the old one.
WAN and MAN (metropolitan wide) network clustering and failover support is also supported. For example, you can designate a node in London to be a failover node for one in New York.
Gary McBride then went on to talk about how the enterprise grade kernel is supporting open source frameworks. You can develop on Spring and deploy on Weblogic.
Messaging support goes beyond JMS and J2EE, they have created a message bus that also supports:
- store and forward – a technology from Tuxedo. It gives the ability to forward messages to other nodes when the main consumer of the messages is down.
- JMS messaging bridge
- Auto-migration – ability to migrate JMS to another server when the current one is not ‘healthy’
- JSR 88 – based JMS deployment modules
- The ability to inspect messages on the JMS queue and perform operations on them
- C API into JMS
- they have the ability to anticipate the speed of the hard disk, in a pure java fashion, in order to optimize the timing of read and writes
- this will mean a significant improvement when using persistent messages
- Web services
- they are supporting XMLBeans v2 for data binding and any data type including xml, pojo’s, etc
- Support for WS-Policy and other WS-standards
- Long running processes with a state/persistent implementation
- The BIG story is the management features
- Configuration and management tools
- Auditing of configuration changes
- The WebLogic console is based on WL Portal, BEA is eating it’s own dog food. J
- As a result, you can skin and re-brand portions of the console, modify existing pages, etc.
- Configuration assistants to help with common operations
- Add your own modules into the admin console
- Diagnostics and monitoring
- WebLogic Diagnostic Framework – allows WL to introspect itself at any given time. You can work with the framework to implement any custom monitoring you might need in response to your company’s SLA (service level agreement)
- Request “dyeing” and context tracing, even across containers – this allows you to trace
- BEA is the only application server on the market with a pluggable SPI for their security container
- RDBMS authentication providers
- Windows NT authentication provider
- LDAP X509 Identity Assertion
- SAML 1.1 IA and credential manager and more
- Configuration and management tools
The talk concludes that WL 9 is fully J2EE 1.4 compliant, with full web services support, management and deployment API’s, JCA 1.5 and full bi-directionality, Servlet 2.4, etc.
The key take aways from the presentation are:
- Enterprise Grade kernel
- Much closer to zero downtime
- Multi-programming model interfaces (ie: spring)
- Reliable messaging
- Full support for SOA
- Enhanced management and security
- General availability in August, 2005
“Java is being implemented at the core of the enterprise, and with that comes the expectation that WL can be easily managed”
Leading portal vendors debate architectures and development approaches
BEA, Plumtree, Sun, and Vignette representatives held a panel discussing portal technology. The panel started off explaining what portals are and how people are using them.
Vignette began explaining that the purpose of portals is to aggregate multiple data sources easily and support exposing mu ltiple websites on top of the same backend, combining services and data across sites in flexible ways.
Plumtree said that Portals began as intranets but then moved into being used to blend intranet and extranet environments, becoming an “application composition and deployment environment.”
Sun chimed in agreeing that these features are important, but that portals are also an important integration technology and with JBI support will become an important front end to SOA applications.
BEA said that the vast majority of deployments are deploying portlets on their appserver. In the old days portals used to be applications, but today portals are just an infrastructure, a presentation layer for an SOA.
Although the room was completely full, the jargon started to wear on people.
The moderator asked: how do we decide when to use a server, vs. doing it yourself?
Vignette said that if you don’t have problems such as how do you integrate single sign on across applications, how do you combine data from a number of different sources and such, how do you provision content, and such, then you don’t need a portal. Vignette also disagreed with BEA on the infrastructure comment: “We do not see Vignette as all infrastructure, because the portal is an application.”
Plumtree further explained that the abstracts you get with using a portal will give you a way to be agile in the face of changing requirements. For example, supporting user login when users are stored in different data sources, some in LDAP and some in other sources for example.
Sun commented that in a large corporation where they could be tens of different internal portals, using a Portal product enforces a consistency that will be far more maintainable, saving money and time. She further added that many companies need to implement integration with legacy back end systems – rather than write that from scratch, portal products have often already done that. Using a portal, you can spend your time working on content instead of infrastructure.
Plumtree- the portal runs on tier as a the middle tier infrastructure provider, and the portlets run in a different container and are called over http. So portlets can be deployed without affecting your portal infrastructure at all.
Plumtree sees WSRP becoming the remoting protocol for the portlets interface.
The moderator asked: are portlets still relevant? Vignette responded that you don’t have to build a new site with JSR 168. Plumtree said ‘Say you want to build an application, do you want to think in terms of little boxes and not have total control over the graphics? Or support AJAX? You can’t do that with portlets. Portlets are good for a lot of the important basic functions you need in business apps now, but they will not scale to the requirements of tomorrow. As a result, Plumtree is looking at ways to let developers own the application and UI but leverage the portal “application framework”.’
BEA responded that developers shouldn’t consider themselves bound by the portlet container, so BEA is providing in an upcoming release, the ability to allow developers to deploy things in packages, combining portlets together into larger more cohesive units.
Audience question: what is the future of JSR168? Sun responded that IBM and BEA are discussing 2.0 and are discussing who should be the leader of it.
Latest trends and management and monitoring
The BOF began with a definition of management and monitoring. Management is defined by dimensions of monitoring, tracking and control. Monitoring is the first step where you modify your app to expose stats for analysis. Tracking constitutes digging into the analysis data for bottlenecks and root cause detection of problems.. Control defines the steps to be taken when a certain situation is encountered.
The presenter made the distinction that we should not be just trying to monitor the application layer, but also look at the application server layer, the JVM layer, and the system/OS layer. The following things can be tracked at each layer:
- System/os: Memory free, pages read per second, CPU time, disk I/O, network bandwidth, network queue length, packets sent/received per second.
- JVM layer – heap memory usage, object life cycles, garbage collections, synchronizations and locks, optimizations, and methods inlining
- Application server layer 0 queue depths, utilization of thread pools, and database connection pools. Number of active passivated/expired session beans.
- JavaEE application layer 0 workload specific performance metrics like transactions per second, response time, order cycle times, through put, waiting time in blocked state.
The preesentor then described what tools are available at each layer:
- Os/hardware: vmstat, iostat, netstat, cpustat (or on windows: perfmon)
- JVM layer – command line utilities like verbose:gc, --xprof, and JSR 174
- Appserver layer – JMX interfaces, SNMP, JVMPI, JVMTI, Byte code instrumentation (BCI), CIM/WBEM, etc.
- Application layer – custom instrumentation (tracking method entry and exit), custom logging, log4J API, ARM API, Custom M Beans, JSR 77
After going into a tutorial into what JMX is, the tutorial moved into practical how-to’s.
A vmstat printout was shown, illustrating 4 groups of processes, each of which was not receiving any CPU cycles. The problem in this case was identified as being insufficient CPU power, and upgradingthe CPU could help.
How to find a memory short fall was looked at. By analyzing the “sr” column from vmstat, which donates memory shortfalls for groups of processes, one can determine if paging is occurring. Paging occurs when memory availability falls below a certain threshold, and paging memory to disk is a major cause of performance shortfall.
Verbose:gc command line utility: pauses due to GC are easily estimated by inspecting the diagnostic output of the JVM itself. The command line argument –verbose:gc prints information at every garbage collection. The command can show how much memory was available before and after GC, and how long it took. The presenter indicated that JVM 1.5 has made great strides in performance, and acts just as good as a very well-tuned 1.4 JVM.
HProf. The hot spot profiler has been around since JDK 1.2 and illustrates the sort of data that can be captured through JVMPI. The output of hprof reveals information that can be used to build a performance analyzer.
This talk wasn’t that good. It was touted as a talk on latest trends but was actually a very introductory talk on JMX and some loosely related tools.
Tangosol Solarmetric Party
One of the hidden jewels of Java One is the joint Tangosol & Solarmetr ic party. These two companies, Tangosol being the clustered caching product vendor, and Solarmetric as one of the best of breed commercial persistence tool vendor (supporting both EJB 3 and JDO) organized their second annual party at a near by club to Java One. What makes each party special is the people that attend.
Their parties are a literal who’s who in the Java community, with people from representing most of the major groups in the Java industry in attendance. A fun atmosphere for mingling and an open minded, smart group of people drinking a lot of alcohol made for a great time.
Building the Compelling Case for JavaServer Faces
During the afternoon technical sessions, the Yuerba Buena Theatre hosted a series of talks of on JavaServer Faces of particular interest to web developers. At 12:15, developers lined up outside the door to gain entrance to "Struts to JavaServer Faces: A Programmers Guide" where Kevin Hinners, Senior Technical Analyst at FedEx Services, laid out three very effective migration strategies for projects seeking to migrate from Struts to JSF:
- Containment Strategy:
- Summary: Reuse your Struts ActionForm beans and Action classes by containing them using JSF Managed Beans. This gives the developer the freedom to rewrite the views using JSF tags, levering the JSF component model, while avoiding the need to rewrite the entire application.
- Pros: This approach has the shortest learning curve while getting project deep into JSF. By quickly embracing JSF tags, developers will be able to leverage the added functionality and power of JSF components while preserving much of the existing application logic inside the contained struts classes.
- Cons: Projects making extensive use of Struts DynaBeans, Struts Validators, or Struts Tiles will have trouble leveraging their investment using this approach.
- Bottom Line: This strategy has the shortest learning curve and quickly provides the project with the benefits of JSF.
- Rewrite Strategy:
- Summary: Rewrite the application logic to make use of JSF. This entails rewriting the Structs ActionForm beans and Action handlers as JSF managed beans (POJOs), replacing the struts tags with JSF components, and moving the struts navigation logic into the faces-config.xml.
- Pros: Provides a clean-room implementation of the application using JSF without intrusion by legacy Struts.
- Cons: Entails an application rewrite, which is often hard to justify if the application is already working as expected.
- Bottom Line: This strategy is ideal when project needs already necessitate a rewrite/refactor of the application independent of the switch to Struts.
- Integration Strategy:
- Summary: Use the JSF-Struts Integration toolkit available from the Struts project to allow Struts and JSF components to coexist in the same application.
- Pros: This approach allows you to preserve all of your existing Struts logic and Struts presentation while making use of JSF components for new logic.
- Cons: This approach requires everyone on the project team to know JSF, Struts, and the integration library, leaving a rather steep learning curve for new project developers. Additionally, this duel-frameworks approach can leave application logic rather spread out.
- Bottom Line: Use this strategy only when the project must preserve a significant investment in custom Struts logic such as dynabeans, tiles, or Struts validators
During the session Kevin also laid out a list of best practices to use when conducting a Struts to JSF migration, which happen to also qualify as best practices for web projects in general:
- Unit-Tests first, prior to migrating or refactoring. This will help eliminate bugs in business objects that cause hidden errors and prevent breakage while converting.
- Stub-out pages and navigation early. This will help provide visibility into how the entire application will fit together.
- Eliminate Java from JSPs.
During the Q&A session which followed, there was a great deal of questioning as to why Struts developers should consider moving to JSF. Kevin quickly listed a number of benefits:
- More advanced rendering for much more rich user interfaces through the component model
- Application logic is contained in POJOs (Plain old Java Objects) through the JSF Managed Bean facility, rather than in struts specific classes.
- More powerful validation than in struts... JSF has all the facilities of struts validation, plus more.
In the end, it was clear there was quite a bit of excitement in the audience about JSF. It appears that project teams may finally be ready to break free of Struts and adopt JSF as the next-generation web framework. And with this presentation, developers are now armed with 3 very powerful migration strategies.
As if the excitement following that session wasn’t enough, at 2:45 in the very same room, JBoss’s MyFaces guru Stan Silvert presented “How to Build Killer Portlets Using JavaServer Faces Technology”. Room was again packed with a line out the door, as even more people came to attend this presentation. This shows two key things: People want to write Portlets, and they are looking to JSF to help them. And this talk showed just how powerful JSF can be in the portal environment. In presentation, Stan answered the following key questions:
- Why you should use JSF to create Portlets: JSF is the only major web framework built from the ground up with Portlets in mind. Changing a JSF application to run in portal takes very little work compared to changing a Struts app or an app written on an in-house framework.
- What a JSF technology developer needs to know about Portlets: Portlets are essentially self-contained mini-applications that run inside a region in a larger portal page. In order for portlets to co-exist as independent apps running in the same webpage, there is a special contract Portlets must follow which differs from the Servlet model, such as strict adherence to a 2-phase request servicing lifecycle. Additionally, Portlets may not redirect the browser, as this might break other Portlets on the same page.
- What a Portlet developer needs to know about JSF technology: Here, Stan
presented a very effective and condensed summary of the main features of JSF, including:
- The Managed Bean Facility which lets POJOs be bound to JSF application pages
- The Validation Facility which allows development of a reusable set of validation rules to be applied to user input
- The Rich and Extensible Component Library, JSF's biggest strength which allows for development of complex components such as a calendar control or data table which can easily and quickly be embedded in a page and handle user input via the JSF contract
- Pluggable Render Kits which allow components to have multiple renderings, similar to how Swing has Pluggable Look and Feel, but here it's pluggable markup rendering for different components running on different types of devices.
- Navigation (page-flow) to decide which page to go to next
- Preserving application state across requests... the managed bean facility removes the need to constantly be stuffing state into the session manually.
- Conversion Model to facilitate the conversion of data-types to and from Strings.
- How to convert a JSF app to run as a Portlet: This was the truly impressive part of the presentation. Whereas converting a Struts application to run involves a long and drawn-out process involving pages and pages of instructions, converting a JSF app to portlets is truly simple… with just a few configuration file changes Stan was able to turn his stand-alone application into a tiny portlet running inside a much larger portal page.
- How JSF Portlet Integration Works: JSF hides the Servlet specific API, so the ExternalContext simply gets switched over to use the Portlet API underneight instead. The Faces controller portlet then supports the 2-phase lifecycle required by portlets. JSF has a "view-handler" that knows how to render URLs that support portlets. So you'd never hard-code URLs into your JSP... you want to let JSF create the URLs.
- Examples of Advanced JSF Portlets
At the end, Stan brilliantly summarized the bottom line in what is perhaps the most compelling case for JSF in Portlets yet… "If you're going to build a portlet, why not use a framework. If you're going to use a framework, why not use the framework that was built for portlets from the beginning."
Keynote from Thomas Kurian, Oracle VP
The keynote started off with Thomas Kurian talking about Oracle’s support of Java from the beginning, and he then launched into a definition of what service oriented architecture is – small surprise, considering JDeveloper’s recent release, with a heavy focus on services and user experience.
The talk was titled “SOA and the Agile Enterprise.” He went into the lifecycle of application development, with special emphasis on enterprise development, focusing on how businesses want to cross silos, even though silos tend to focus on local requirements instead of enterprise requirements.
· Changing business requirements
· Emerging technologies
· Growing complexity
· Designing applications for change
From this, he said, “Develop, integrate, orchestrate, secure, manage, monitor, change. This is the SOA blueprint for success.”
He then went into a set of demos, first focusing on client side with JSF. They showed a “classic” simple loan application, with multiple pages and a plain UI. Then they showed how a JSF implementation might look, presumably with fairly little customization based on the render kit capability. It looks very nice – as most of the AJAX demos do. This is definitely the year of AJAX, especially here where they're pushing AJAX behind JSF components.
Back to Thomas: “We believe JSF has such promise that we're doing two things: we're contributing to MyFaces.” (This was announced on TSS.) “Secondly, we're taking the environment in Jdeveloper, and allowing it to be used in Eclipse.” (Also announced on TSS.)
He then launched into an EJB3 section. EJB3 simplifies programming by making any POJO an EJB, so anyone who knows how to write Java knows how to write EJB. It also simplifies the way you build EJBs.
He then showed a standard EJB 2.1 session bean, with two methods – which, of course, was surrounded by a ton of EJB methods required by the infrastructure.
The EJB 3 version was a simple interface and implementation. The deployment descriptor for the bean also went away entirely. (As in, no text.) This got a round of laughter from the crowd.
He then went into integration points. He described services as being accessed through five mechanisms: In-memory (i.e., Java); REST (e.g., Yahoo); JCA (SAP, for example); COM+ (.NET); SOAP (Oracle). He then introduced WSIF, which allows you to abstract all of these into abstractions, as provided through JBI. JSR-227 (data binding API) also factors in.
He then jumped into the heart of SOA, providing some simple definitions. An ESB is a message infrastructure that supports synchronous and asynchronous calls and allows you to bind services in a common way. Second, SOA refers to the architecture that using an ESB more or less requires – considering uses as silos of functionality, and calling them as parts of a process. Thirdly, JBI is a standard for creating and using an ESB with Java, one that leverages WSIF and BPEL, the Business Process Expression Language, a standard for orchestrating services.
They brought up another developer to show EJB and BPEL. He showed a BPEL console, which showed services as well as a transaction that is in-process. This is very nice. If you drilled down far enough, you get to see the specific XML passed around.
Building process orchestration is two parts: build the services, and then tying them together in a process. There was very little code involved; it was all very linear, very clear. He showed off the web services metadata JSR while making a EJB 3 session bean a service. He then went to the BPEL console. He named the service, browsed for the service, and configured properties for it. He then created a processing node, then tied it to the service. It was very quick.
The next topic he covered was security. When building services, you don't know what the security policies are, necessarily, or the SLAs such as failover, performance requirements, etc. He said that what you needed was a declarative way to manage such services.
All in all, the keynote was very interesting, very well done. It’s not likely that real-world processes would come together as quickly as it did there, but overall, the possibilities looked very good.
Oracle heads persistence, open source initiatives
Oracle Corp. made significant strides in the Java and open source communities this week, taking a leadership role for a key Java specification and announcing that it will spearhead several Eclipse projects.
The Redwood City, Calif.-based company announced that it will become co-specification lead for the Enterprise JavaBeans 3.0 specification and that Oracle TopLink, a platform that let’s developers map Java objects to relational databases, will form the basis for the persistence engine in the Java Enterprise Edition (EE) platform 5.
“Sun has never been willing to share the co-spec lead role in any of the J2EE [Java 2 Enterprise Edition] technology,” said Anne Thomas Manes, Vice President and Research Director at the Midvale, Utah-based Burton Group. The fact that Sun is sharing this position means that Oracle will play a key role in shaping the EJB 3.0 persistence model, “which includes delivering the reference implementation,” she said.
But the JCP is only one area where the company is focusing its efforts. Oracle also announced that it will donate its EJB 3.0 and JavaServer Faces (JSF) implementations to the open source community.
JSF, a standard that both Oracle and Sun Microsystems, Inc. are working on, simplifies the development of user interfaces for J2EE applications by encapsulating event and state management in the component itself, making them reusable.
“We’re making our JSF technology available to all application developers by contributing it to the MyFaces open source effort,” said Thomas Kurian, senior vice president of development at Oracle in a keynote presentation. “We’re also taking the visual environment we’re using in JDeveloper and building it in the Eclipse community.
On Wednesday, Oracle proposed to lead a third project to develop a Business Process Execution (BPEL) language tool under the Eclipse Public License. The tool would be based on Oracle’s BPEL Process Manager and BPEL Designer.
BPEL, which allows Web services to be orchestrated and aligned with business processes in a service-oriented architecture, would make a key addition to the rapidly growing gallery of Eclipse plug-ins.
“We’re giving away lot’s to the open source community,” Kurian said.
Kurian announced that Oracle will also contribute its EJB 3.0 reference implementation to project GlassFish, Sun's open source implementation of the Sun Java System Application Server 9.