在正式开幕的第二天，JavaOne大会渐入佳境。Marc Fleury的演讲、JBoss AOP展示、Rave（Sun的全新Java开发工具）的Demo、“敏捷方法 vs. MDA”、“重负荷网站的设计模式”、J2SE 1.5的新增安全特性……我已经垂涎三尺了。如果能参加这样一天的会议，再跟Marc Fleury、Joshua Bloch、Richard Oberg等久仰大名的高手合个影，该有多幸福。
——————————————————
TheServerSide@JavaOne 2003
By Dion Almaer, Nitin Bharti, Stuart Charlton, Doug Bateman, Frank Cohen
June 2003
The Wednesday morning keynote looked at the new Java.net portal, stirred some controversy amongst Jython supporters, and gave a demo of Project Rave. Throughout the day and into the evening there were several key, forward-looking talks and discussions on EJB 3.0 by Linda DeMichiel. JBossTwo featured 'The Marc Fleury Show' and a fascinating AOP Panel. Other sessions covered at JavaOne were 'Agile Methods vs. MDA', 'Design Patterns for Heavy Load Websites', Web Services EAI using JCA, and New Security Features in J2SE 1.5.
Wednesday Morning General Session: Java.net, Jython slighted, What's all the Rave?
At the general session on Wednesday morning more was talked about the new developer portal http://www.java.net. The site is edited by Tim O'Reilly and the chief web dog is James. Tim describes himself as the Colonel Sanders of the site; he jokes that it's really a group of O'Reilly Associates editors that will be editing the site. Rumour has it that java.net is a private-labeled version of SourceForge with a bunch of new bells and whistles added (blogs, wikis, forums.) So it is open for anyone to host a public project, open-source projects included.
There seems to be lack of support for Jython at Sun. To thier credit Sun did mention Jython when talking about JSR-223 (Java support for Scripting Languages) and scheduled a birds-of-a-feather session. However, Jython was slighted too: The BOF would start at 11:20 pm, and Tim O'Reilly messed up and said "Jython is a good combination of Pearl and Java." He meant to say Python and Java. Sun seems to be missing-the-boat on what Jython really brings to Java: "It's the Byte-Codes Stupid!" Jython compiles into Java byte-codes and runs natively on the Java VM. To a Java developer that means full access to all of Python's objects and also to all of Java's objects. Sun should throw away JSR-223 and start again. They should start by writing a specification that lets all scripting languages compile to Java byte-codes. That would be progress.
Project Rave looks just like Visual Studio.NET but everything is real Java. Sun showed building a Web application using JavaServer Faces. Rave features a simple graphical layout tool and provides standard JDBC rowset support. Rave style sheets control default colors, type, sizes, and styles. The query editor provides mapping to define SQL schemas. Datasources use standard JAX-RPC calls to make Web Service calls. To make it a perfect demonstration, the example code crashed during the demo. Not to be outdone by a crash, the engineer on stage rebuilt the application from scratch in about 90 seconds. The audience loved it!
JBossTwo
The doors were meant to open at 9:30. The people here missed the morning JavaOne keynote, and weren't let in. The security guard wouldn't answer anyones questions :)
The operation wasn't slick like JavaOne, but it felt kinda nice. This was a small, cozy area for people to talk about things. The music that was playing in the theatre was from Windows Media Player on Marc's laptop. As he closed down his apps, there were several emails showing, one with "Core Dev Network" in the title.
People had been talking about the "split" outside of the conference, and most of them saw that it was just a new venture... and one that didn't have to hurt JBoss at all. Would Marc mention it? Not directly, but there were some subtly comments. "...all of THE developers HERE understand ...", "We are staffed as we want to be right now", etc.
Marc took the stage, letting us know that "Today is the Marc Fleury Show". It certainly was, he was presenting and moderating all day. You know who is at the wheel of the Jboss bus. He started the morning with an introduction, that was on the lines of the BLUE whitepaper. A core message was "Open Source Is Safe".
He delved into the AOP framework, and what he thinks it means. He thinks that for users, "AOP is trivial". Writing the aspect framework, and aspects are complex, but using them is very easy. "Microsoft got it right wrt ease of use". Sound familiar? (there's a whole lot of ease of use talk going on). The holy grail is complete non-invansive system code. An application developer should not have to care about system fluff, they should be building business applications.
JBoss and Microsoft are in the same camp: Simplify framework, and tools can follow BEA and IBM Camp: Add GUI tools on top of the existing world.
Can we leave the app guys in J2SE? Marc thinks we can, and we should.
Some questions that came up:
Q. "Isn't it hard to debug Aspects?"
Marc: "You don't have to. JBoss has already debugged the aspects for you. They are solid" [can you ever just trust services like these?]
Q. "If we jump into the new JBoss was of doing things with POJO's and Aspects, haven't we lost interopobility?"
Marc: "Do you mind being stuck in a free world?"
Q. "How do you roll back a call chain?"
Marc: "This requires a versioning system with a state change history. There is already some support for this"
Q. "Can we be assured that JBoss will continue to support the full J2EE spec?"
Marc: "Rest assured."
* * *
The JBoss core developers were brought on stage and introduced next, and then a customer panel was introduced. The panelists were all proponents of JBoss, and Marc probed them to get info of their successes, and to show that JBoss is a solid production product, and that the JBoss group is a good organization.
* * *
The part of the show that people were waiting for was the AOP panel. The panel consisted of Dean Wampler of Rational (now IBM: or "I've Been Moved" as he called it!), Professor Shigeru Chiba (javassist, bytecode level library, creator), and Bill Burke (JBoss chief architect). Marc moderated of course. Each of the participants went through some slides on what they thought AOP was about.
Dean:
We modularized the problem domain with OOP
- He thought the push behind OOP was GUI development
We modularize the cross cutting concerns with AOP
- He thinks that the widespread development of distributed apps will spur AOP
The Rational side of him only came out when he talked about the idea that Use Cases can be mapped as aspects themselves. I think this slide existed to fulfill the prophecy that all Rational slides have to have some use cases on them.
The Prof:
Shigeru had slides that were trying to progressively make a point. However Marc kept butting in, and not letting him just go through the motions. This led to funny moments of "er, just let me go to the next slide... and voila!".
He answered the "is debugging aspects hard?" question by saying that tools need to help out, and reminding everyone that people used to say that polymorphism is bad, as it makes debugging hard.
When an example was shown, that had a Tracer, Marc groaned "NOT A LOGGING EXAMPLE AGAIN". When you see anything to do with AOP, logging is always the example.... so one can feel Marc's pain with that one.
With OOP we have "IS A", "HAS A", "IS PART OF", etc. AOP now gives us a way to express "NEEDS".
Bill:
Instead of saying "AOP compliments OOP", Bill made a great slip of the tongue and said "AOP complicated OOP". That got a good laugh.
Bill showed some demos of the JBoss AOP framework
It was interesting to see that you can even weave the setting of fields, E.g. tx.begin();
some.field = 2;
some.otherfield = "whee";
...
tx.commit();
if the transaction failed, the aspect could roll back the field values to what they were before the tx began. Compare that to what we have in J2EE now.
This can't even be done in most areas. Stateful Session Beans can let us do things like this, but not without a lot of work. Will this mean the end of set*() get*() methods?
Agile Methods vs Model Driven Development
Borland chief scientist Blake Stone’s session "Model vs Code, Practical Strategies for Agile Developers" drew quite a crowd. During his session, Blake described the many synergies that can exist between Agile Methods and Model Driven Development, guiding developers on how to strike a balance between the two extremes. Lashing out at the misconception that software may one day be written strictly using modeling tools, Blake argued "Code isn’t going away. Modeling won’t replace traditional coding any more than the written word will be replaced by picture books." On the flip side, he pointed out, a picture can be worth a thousand words. It’s a tradeoff between precision of code and information density of diagrams.
For any given problem, "you’re going to look at the densest, most accurate way of communicating." Sometimes the formal grammars of code will most effectively communicate the system to future programmers. Other times, we want the distillation provided by pictures. "Why choose just one? Use diagrams to clarify code," explained Blake, as he demoed TogetherJ’s ability to keep system diagrams in sync with application code, providing highly agile, model driven, development. The fundamental realization" models and code are "two sides of the same coin, you simply can’t separate them."
EJB 2.1 Architecture and a Preview of EJB 3.0
Linda DeMichiel, spec lead for JSR 153 (EJB 2.1) and JSR 220 (EJB 3.0), spoke Wednesday afternoon to a near capacity crowd on the new features of EJB 2.1. The discussion on EJB 2.1 outlined familiar new features: improved Web services support, the Timer Service, extension of MDB's beyond JMS, and support for the ORDER BY clause in EJB-QL.
She did a walk-through of how to implement a Web service in EJB using a JAX-RPC interface, which enables the sending and receiving of messages to look like regular RPC calls to a client. She showed the code for a Web service endpoint interface and the client view of the Web service. Mildly amusing, but it seemed the crowed was really waiting to hear more about EJB 3.0.
If the focus of EJB 2.1 is Web services, then the main theme of EJB 3.0 will be ease of development. JSR 175 on metadata annotations, aims to get deployment descriptors out of the developer's way. At the same time, she emphasized that we should be careful how we use metadata. "We don't want to shovel a deployment descriptor into an EJB class file." The spec will also 'leverage defaulting' (using stateless session beans as a default since stateful beans are rarely used). Another ease-of-use item will be the use of factory patterns (or something more user friendly) in place of cumbersome JNDI lookups. And of course, when she said "deployment descriptors must die!", the crowd broke out into applause.
To prove her point about ease-of-development, she compared the way we write EJBs today to the way we WILL write EJBs tomorrow. She showed code for a 'simple' HelloWorld Stateless Session bean, with all the required methods, the implementation of home and remote interfaces, the deployment descriptor, etc. This was all replaced with 5 lines of EJB 3.0 code. An @session annotation in front of the class name and an @remote in front of the getter and voila, all the complexity of lifecyle methods and interfaces has been avoided! Cheers and applause ensued when the slide for the deployment descriptor was shown for this ejb: it was blank.
Birds of a Feather Sessions - Future of EJB spec, JMX Demo
Linda continued her EJB crusade in the evening with a 2 hour marathon session with hard core EJB developers, holding a "town hall" style discussion where EJB developers could give feedback to which features and simplifications to prioritize for the upcoming EJB 2.1 and EJB 3.0 specs. Judging by the issues raised, it was clear this crowd wanted to see new features and capabilities in the EJB more than improvements in "Ease of Development" as Sun has prioritized. As one developer put it "I think ease of development is very oversold," quietly admitting "I really don’t want to see the army of VB developers coming into our land." It was clear only the hardest of the hard-core EJB developers had been attracted to this session.
Topics discussed for potential inclusion in future releases of EJB included standardized hooks in Message Driven Beans for handling poison messages, instance level security checks for entity beans, more flexible security group mappings and rules, support for adding arbitrary interceptors (a favorite feature of those familiar with JBoss’s design), and portable descriptors for mapping entity beans to databases. The subject of deprecating EJB entirely in favor of Aspect Oriented Programming also briefly came up, but it was clear Linda and a significant portion of the crowd felt AOP needed to mature in terms of best practices and design patterns before EJB could be effectively replaced by AOP.
Features People Asked For
Instance based security: Basically, the security model doesn't work for a LOT of people in the real world. The simple declaritive model only works for simple cases, and it needs to be made more flexible. There was talk of being able to plugin rules engines.
Interceptors: People really want to see these. Even the future (AOP) was mentioned.
Deployment descriptor defaults: People would like to put in default values for the items that we always have to put into vendor specific files. For example, let us just put in the damn JNDI name, and <*-ref> end points etc etc.
Mapping standard: If you use CMP, and use multiple app servers, the mapping is totally different. Some people want to try to have some kind of base standard that would work as a default, and minimal information.
Clustering: Quality of service items like clustering have always been kept out of the spec, but people would like some guidelines standardized. There *is* always a difference between writing code to a single server, or to a cluster of servers (programatically you may want to retry methods on a stub if something went wrong on an idempotent operation).
Threads: This is enterprise computing, and sometimes you want to be able to spawn threads to do parallel work, and don't want to use JMS to get this affect. It would be nice to be able to context.getThread() that would give you a safe thread from a pool.
Transaction Timeout configuration: There are some times, when you know a certain operation needs a long tx timeout (as it will take awhile). Instead of having to drop to bean managed transactions, how about being able to use declaritive programming to set a longer timeout that the default for a particular method/bean.
EJBQL:
Dynamic EJBQL: There was a hint that this will be in EJB 3.0.
Would be nice to be able to run queries that return a data structure which spans multiple tables, without having to go to multiple entities. At the moment people use fast reader patterns to bypass EJB for this task
Things people would want to change / pet peeves:
*NOTE: we are too far down the road to make a lot of these changes ;)*
Stateless Session doesn't make sense!
It should be:
Service Bean - what a stateless sb is now
Session Bean - what a stateful sb is now
Split interfaces and make methods that make sense Instead of having ejbRemove() mean totally different things, don't try to put as much in the EnterpriseBean interface but do the right thing (tm).
Service Bean: no need for ejbActivate/Passivate etc
Entity Bean: ejbDelete, ejbInsert, etc
Ease of Development vs. Enterprise Objects
We all know that EoD is the big thing at J1. Some of these features "don't seem to help with EoD". However, people quickly mentioned that these items are NEEDED FOR ENTERPRISE DEVELOPMENT. These are Enterprise JavaBeans aren't they? Sure cleaning up EJB will be really nice, but can't we clean them up AND make them more useful in the enterprise world?
It is going to be very interesting to see the impact of metadata, and how we may not have home/remote interfaces if we don't want/need them.
Following Linda’s BOF, BEA JMX architects illustrated how JMX can be used to gather performance monitoring and tuning statistics in "J2EE Performance Monitoring and Tuning Using JMX". Utilizing Petstore as an example, developers were shown how to create "JMX Loggers" to log active thread counts, entity cache hits, leaked connection counts, and other critical performance data to a log file at 2 second intervals during load testing. Then this logged data was shown plotted versus both time and load so that developers could then see a clear picture of the potential performance bottlenecks as their applications scale.
Technical Session: Design Patterns for Heavy Load Websites
The developers from the Wall Street Journal (WSJ.com) website presented their strategies for designing heavy load websites. WSJ.com, originally on Vignette/TCL, now runs on J2EE 1.3 using a combination of Struts, JSTL, and Web Services. It uses Web services to provide flexible licensing of its content and services to provide WSJ content in various venues, and to slice its content in a variety of ways, and has heavy reliance on authentication and authorization mechanisms with its Web services and web applications.
The MVC paradigm is pervasive in WSJ's architecture, and they spoke at length about the various design tradeoffs possible with Struts, and how Struts definitely stood up to the challenge of delivering a large scale, high volume website, that serves over 700,000 subscribers.
Technical Session: Designing Scalable Servers
The java.nio APIs provide for a very powerful approach to designing scalable servers in Java, and was a crucial piece for web application servers to be written in 100% pure Java.
In this advanced session, the speaker proposed a set of six different architectures for servers, micro-benchmarking them against Apache 2.0.42 for small file (1 KB) operations and thttpd 2.20c for large file (1 MB throttled to 56kb/sec) operations. httperf from HP Labs measured the small file operations benchmark, and http_load (from the same author as thttpd) measured the large file operations. The test server was a 4x480 MHZ Sun Enterprise 450, as were the two client machines in the load test, all connected with point-to-point Gigabit Ethernet.
The six proposed architectures for the servers were: 3 Blocking I/O Servers: Single Threaded, Multi-Dedicated Thread, Multi-Thread Pool 3 Non-Blocking I/O Servers: Single Threaded, 2 Threads, and 4 Threads
Both approaches used the java.nio.* APIs, except that the last 3 architectures took advantage of the new java.nio.Selector approach to multiplex many concurrent socket channels. The blocking I/O servers would be the only way that old-style java.io based servers could be written.
The speaker took us through the source code to each of the first three blocking I/O architectures, beginning with a server that was designed in the prior session on "Building a Simple Server". The Multi-Dedicated Thread server was nearly on par with thttpd for large file operations, and the Multi-Thread Pool server was nearly on par with both Apache for small files, and thttpd for large files.
Unfortunately, both approaches were scarred by having a linear increase of memory requirements as the server load increased, getting so bad that for large file operations, the Java server required over 600 MB of resident set size (RSS), whereas thttpd only required 8 MB!
The speaker then digressed to explain the java.nio.Selector model to the audience, showing gradually more complex examples, up to the actual single-threaded non-blocking web server. The single-treaded server exhibited somewhat chaotic behavior, and generally poor performance. The two-thread server dedicated one thread to accepting incoming connections, and one to dispatch data to all other connections. The four-thread server dedicated two threads to accepting and two threads to dispatching.
The four-thread server surprisingly showed near-on-par performance with both thttpd and Apache, with only memory consumption being the major difference (200 MB of RSS at peak, though the growth was not linear).
Many of the performance results in this demo were the result of changes in J2SE 1.4.2, so be sure to grab it! It's clear that the Java NIO API works quite well for what it was designed to do: provide the Java language with the ability to write servers that can be potentially as scalable as native-OS servers.
Complementing Web-Services-Ready EAI with the J2EE Connector Architecture and Federated Authentication
This technical session spoke to the synergies between the J2EE Connector Architecture (JCA), Web services, and federated identity management with Project Liberty.
Enterprise Application Integration (EAI) is a large marketplace for tools to increase the productivity of integrating disparate legacy applications both within and outside of companies. In large part, the biggest hype in EAI today is the impact of Web services on integration technologies.
The tradeoff with Web services is that they tend to be somewhat intrusive on the legacy: one would need to wrap the legacy service in the legacy development environment and generate XML out of that, something that might not be very productive if the environment is very old, brittle, or lacking XML tools.
The J2EE Connector Architecture (JCA), on the other hand, provides a non-intrusive way of integrating with legacy systems, because it relies on a connector, which is effectively a "device driver" to talk to the legacy system.
The final challenge in cross-systems integration is about federating identity among the servers collaborating together, and facilitating single sign-on. Project LIberty is a Web services enabled approach to asserting credentials and mutually authenticating servers.
Put together, the J2EE application server serves as the perfect hub for integration, by providing for JCA access to legacy systems, wrapping this JCA access with a Web service, and then enabling this Web service to be part of a federation of servers that share identities.
The productivity of the J2EE environment allows you to leverage your legacy investments and add to them using the emerging Web services technologies for integration and security. The talk showed code and diagram examples of using the JCA, Project Liberty, and JAX-RPC toolkits, and screenshots of an end-to-end demo that was developed offsite.
J2SE Security Looks Ahead: New Features from Cryptography to XML Security
This security session, hosted by two members of Sun's J2SE security team, gave a detailed overview of where the security API's are today, in J2SE 1.4.2, and where they're headed to in J2SE 1.5.
J2SE 1.5 will include major enhancements to cryptography, XML securitiy, Public Key Infrastructure (PKI), Kerberos, and ease of maintenance.
In particular, J2SE 1.5 will:
Make the cryptography API ready for Elliptic Curve Cryptography (ECC), an emerging approach to cryptography algorithms. An ECC provider may be provided after 1.5, depending on demand.
Allows you to encrypt and decrypt to java.nio.ByteBuffers
Provide support for PKCS 11, the de facto, standard cryptographic token interface. This will enable JCE to leverage external cryptographic providers such as smart cards, hardware cryptography accelerators, and optimized native-platform crypto implementations.
XML security will support both XML Digital Signatures and Encryption/Decryption. These efforts are supported by JSR's 105 and 106, with JSR 105 still in public review until June 29th. These JSRs Java-enable several W3C recommendations including XML Signature Syntax and Processing, Exclusive XML Canonicalization Algorithm, XPath Filter-2 Transform Algorithm, and the XML Encryption Syntax and Processing.
Allow certificate revocation checking via the Online Certificate Status Protocol (OCSP), allowing the Java platform to validate certificates without having to carry around cumbersome CRLs.
Include a helper class known as SSLEngine that will enable any java.io stream or java.nio channel to leverage SSL. U.S. export restrictions have been relaxed, and now Sun will allow for full pluggability of the underlying SSL implementation.
It's clear by all of the work happening on the security front, the J2SE platform's security model is evolving to support both emerging standards and to provide rich support to solid standards used in enterprise mission critical applications today.
