 |
|
 |
 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
 Roberto Chinnici's Blog
More fun sessions at and around JavaOnePosted by robc on April 28, 2008 at 04:05 PM | Permalink | Comments (1)In addition to the Java EE 6 talks, there are a few more events on my calendar for the week of JavaOne. On Sunday, when I'm not caught up in rehearsals and last-minute slide editing, I'll check out the GlassFish Unconference and party. Since the agenda is entirely up to participants, bring your best topics and suggestions! On Monday, I'll be at CommunityOne. As Tim Bray pointed out, it's free and packed with great talks, so you'd be crazy to spend the day elsewhere. On Tuesday at 3:20pm I'm doing a session on "JavaScript: The Language Everybody Loves to Hate" (TS-4986). In this talk I'll try to convince a predictably skeptical audience that JavaScript is a real programming language. I'll focus on functional and object-oriented programming, explaining all the arcana. The samples I'll show are mostly taken from popular frameworks, like jQuery, Prototype and jMaki. I'll also touch on some smaller topics, like modules and fluid interfaces. The focus is not on Ajax programming, so I will not cover browser differences or DOM at all, just core language concepts and how they scale. By the way, as I prepared the slides I thought of expanding this material into a series of blog entries. If you are interested, please leave a comment. On Wednesday at 9:30am I'll be at "The Script Bowl: A Rapid-Fire Comparison of Scripting Languages" (PAN-5435). Somehow I got persuaded to act as a judge in this American Idol-like elimination show. I'll try to keep my snide remarks to a minimum and I promise not to try and affect a British accent. Charles Nutter broke the embargo on the super-secret list of tasks that our panelists have been asked to perform. But he may have got the list of participants wrong: we will have JRuby, Jython, Groovy and Scala representatives on stage, ready to dazzle the audience with their best work. In the rocket science department, on Wednesday at 2:40pm I'm registered to attend a session on "Transactional Memory in Java Based Systems" (TS-6316). A bit dry maybe, but On Friday, at 12:10pm I'll attend Kohsuke Kawaguchi's Hudson talk (TS-6547) to pay homage to this irreplaceable tool and its equally irreplaceable author. I think that without Hudson all software development around here would stop; furthermore, at the rate it's spreading Hudson will soon run the entire software industry. Not too shabby for a butler! Finally, after much session and party attendance, I plan to end the week on Saturday at the Scala Lift-off unconference (no ties to JavaOne). Right now I'm more interested in Scala than the lift web framework, but in any case it's going to be a great opportunity to meet other Scala-heads. Overall it looks like a great (and exhausting) week in the making! Java EE 6 at JavaOnePosted by robc on April 25, 2008 at 10:43 AM | Permalink | Comments (0)JavaOne 2008 is around the corner, so I thought I'd compile a list of sessions touching on Java EE 6 technologies. Let's start with the platform itself. As part of the Sun Technical General Session (Tuesday, 1:30pm) I'll be giving an overview on EE 6 and show some cool GlassFish V3 demos. Then you are all invited to the Java EE 6 Platform Community BOF (BOF-4984, Wednesday, 7:30pm) to talk about profiles and other features in the platform. Several expert group members will be there (12, at last count) and we are looking forward to a very interactive conversation with the audience. Moving on to the main EE 6 components, here is a list of talks by the various spec leads:
(I just noticed the overlap between the EJB and JAX-RS talks. I wonder if it's too late to move one of them, or schedule a repeat session. I'll check with the conference organizers.) Update: The JAX-RS talk will be repeated on Friday at 2:50pm. I would also recommend the session on JSR-303 (Bean Validation, TS-5616), which we are tracking closely for inclusion in the platform. Finally, here are the community discussion BOFs:
If you like the demos I'll show during the keynote, you owe it to yourself to attend the GlassFish V3 session (TS-5921, Tuesday 4:40pm). Extensibility and modularityPosted by robc on March 17, 2008 at 05:00 PM | Permalink | Comments (1)Thanks to everyone who left comments on my previous blog entry on profiles, as well as on the related TSS and InfoQ articles. Also to the 700+ folks who voted on the poll on java.net or commented on it either on-site or on TSS. At a high level, I have to say that the feedback reflects quite closely the discussion in the JSR-316 EG. Perhaps the EG composition is even more representative of the whole community than we originally thought! Unfortunately, the poll results are a masterpiece of indecision: large preference for including JSF 2.0 and WebBeans 1.0, but short of a majority (46.7%). A smaller profile without JSF and WebBeans at 28.9%, but even that camp is split nicely in two (at 17% and 11.9%). A full 24.2% of respondents who don't care. Conclusion #1: There is strong demand for JSF 2.0 and WebBeans 1.0. Conclusion #2: We cannot please everyone (we kind of knew that). Having read all the comments, there seems to be a bit of confusion about the way that extensibility would work. In my original blog post I didn't go in depth into it, mostly to avoid breaking the record for the longest and most boring blog entry on java.net, but the subject deserves a few more words. For clarity, I find it convenient to distinguish two cases, based on whether a technology can be added to an application by a user or by a server vendor. I will reserve the term "extensibility" for the first case, and use "modularity" for the latter. ExtensibilityAt first sight, making it possible to add any technology via extensibility seems desirable. (Incidentally, this may well be the Spring tack on the whole thing.) In reality, this would require a lot of contracts to be standardized. Since standardization has a cost and the returns would be diminishing, I doubt that it will ever cover 100% of the functionality. Performance-wise, going through standard contracts at this level of granularity may turn out to be sub-optimal, so I imagine there'd always be an incentive for vendors to bundle the implementation of certain APIs with their application server to try and squeeze every bit of performance out of it. At the same time, extensibility is a great thing if it captures the 20% of functionality that covers 80% of the needs, thus enabling a lot of developers to painlessly use a lot of technologies at essentially no cost in complexity or performance. In essence, this is the reasoning behind making extensibility in the web container a key goal for Java EE 6. A lot of the APIs we've been considering for the Web Profile can be handled via extensibility: drop one jar into the WEB-INF/lib directory of your application (or in some suitable shared directory on your server) and you get JAX-RS, or JSF, or JPA, or WebBeans, or server-side JAX-WS, or... The key factors here are the availability of the technology in standalone form (which requires a separate TCK to exist) and the adequacy of the extensibility contracts in the servlet container. We certainly want to make sure that the latter are sufficient to plug in pretty much any web framework worth using, so please keep an eye on the Servlet 3.0 developments and let us know if you find any holes. On the TCK front, we are resource-constrained on what we can do with respect to existing technologies, but for new ones (including all the ones listed earlier) we will make sure suitable TCKs exist. ModularityThe second case, modularity, covers pretty much everything else. In a number of cases, which hopefully will get smaller over time, there is no independent TCK for a technology, so an implementation cannot consist a jar separate from a full Java EE server. In some other cases, there is no standard contract that would enable you to plug an arbitrary implementation into an application server. (EJB 3.1 is a good example.) Designing these contracts is non-trivial, so we need to accept as a fact of life that we won't have them in Java EE 6. Luckily, we got a bunch of new contracts done recently, e.g. the security-related ones in JSR-115 and JSR-196, so things are moving in the right direction. As part of the work on profiles, we've been trying to improve on the situation as much as time and resources allow. In the case of EJB, we've been prodding the EJB EG to define a "lite" subset of EJB 3.1 which can be run on top of the Web Profile. This way, application server vendors will be able to offer a "EJB 3.1 Lite" implementation in their Web Profile products even if we went with a "small" Web Profile (e.g. option (A) in my previous blog entry). So, why am I using the word "modularity" for this case? It's because it fits well with the trend we are seeing towards more modular application servers like GlassFish V3. Rather than having a monolithic server, you'd be running a small core and an initial set of containers, with some baseline functionality. You could then download/install/activate as needed any number of new modules providing additional functionality, like EJB 3.1 Lite. Of course, you could handle this way modules that use extensibility too, especially when they are shared by multiple applications, but for things like EJB 3.1 Lite there literally wouldn't be another option: absent an SPI, the choice of what EJB 3.1 Lite implementation you run would be limited by what your server vendor offers. Reality bitesOnce you look more closely at the different APIs, you start realizing that there are some "gray" cases too, like JPA. In fact, although it's possible to add JPA to a web application via extensibility, your application will be restricted to using the SE-based programming model (i.e. using the javax.persistence.Persistence class as an entry point). Enabling the resource injection-based EE model is non-trivial and would require quite a bit of work. Is the SE model good enough? Does extensibility have to go all the way in all cases? I hope not, but it will take time to figure out where to draw the line for maximum effectiveness. As a coda, I should talk briefly about JAX-WS. It wasn't very clear in my previous entry, but since Java EE 6 requires Java SE 6, the JAXB and JAX-WS APIs would be present in *any* profile. Unfortunately, what's left out is the ability to define web service endpoints on EE, which traditionally follows the JSR-109 model. We'd like to see this case handled via extensibility, so that it'd be possible to drop a "server-side JAX-WS" jar into WEB-INF/lib and have the application work in any servlet container, especially those that don't support JSR-109. In this case, we'd also like this extension library to use the version of JAX-WS that comes with the JDK. Currently there are some missing bits in the JAX-WS API that prevent this from working, but we're looking into adding a small SPI for this purpose to the JAX-WS 2.2 release. Profiles in the Java EE 6 PlatformPosted by robc on February 22, 2008 at 11:38 AM | Permalink | Comments (20)Update: See the related stories on The ServerSide and on InfoQ. It's been several months since my last update on the work going on in the Java EE 6 Platform Expert Group (JSR-316). The main topic of discussion in the EG has been profiles. There are several aspects to this, ranging from the number and contents of profiles to the somewhat more general subject of SPIs and pluggability. By the far the most animated part has been the discussion around the Web Profile, with several definitions being proposed. Personally, I found it very interesting to see how EG members crafted their proposals by following different routes and aiming for somewhat different goals. This is a testament to the activity and liveliness of the platform. At this stage, we think that the best path forward consists of polling the community for feedback on which definition of Web Profile they'd most like to see adopted by the expert group. One reaction that people sometimes have is to ask: Why should we choose? So, as a premise, I should point out that profiles come at a cost. As the specification lead for JSR-316, Sun is responsible for delivering a Reference Implementation (RI) and a Technology Compatibility Kit (TCK) for each profile. Additionally, Sun needs to take all the legal and business steps to license the platform and each profile, provide support to licensees (including no-cost support for qualified ones), etc. This does not come for free. In very practical terms, then, we cannot support a large number of profiles in the desired timeframe for the Java EE 6 platform. Here "large" really means "more than one". Not all is lost though. One of the driving ideas around profiles is to move away from a big-bang model for the delivery of the platform, enabling smaller, focused communities to forge ahead in the context of a profile they define. It is natural then to achieve as much decoupling as possible from the beginning and push profiles into separate JSRs, to be finalized on their own timeline. This said, we originally proposed defining a Web Profile as part of the Java EE 6 JSR because (1) it's helpful to have a use case at hand when developing the notion of profiles, as opposed to doing so in the vacuum, and (2) we believe that there is interest in the market and in the community for a web-centered profile of the EE platform. Incidentally, the amount and depth of EG mail that the Web Profile generated more than proved the first point. To come to the central part of this post, here are the two profile proposals that got the most interest in the EG. I've tried to come up with a characterization of them in five words or less, but in the interest of not attaching strong labels or identifying the proponents, in what follows we'll simply call them A and B. As a reference, I also listed the contents of the full platform in the third column.
In (B), the inclusion of JSF 2.0 and WebBeans 1.0 is controversial, so we marked them with an asterisk (*). Not coincidentally, these are technologies which could be handled via extensibility (keep reading for more details). Some clarifications are in order. "EJB 3.1 (Lite)" refers to the idea of allowing implementations to deliver a subset of EJB 3.1. The contents of this "lite" subset are wholly undecided at this point, but as an example it might include the annotation-based programming model introduced in EJB 3.0, restricted to session beans with local interfaces (only). In other words, you could write an annotated session bean with a local interface and use it in your Web Profile-compliant product (assuming (B) is accepted, that is). But, for example, you could not write a EJB 2.1-style session bean, or an EJB 3.0 message-driven bean, or a EJB 3.0 stateful session bean with a remote interface. It's important to note that proposal (B) assumes that "EJB 3.1 (Lite)" will exist, but this is a decision that is entirely up to the EJB 3.1 expert group (JSR-318), where it's going to be prioritized against other features. The precise definition of what comprises "EJB 3.1 (Lite)" is also left to the EJB 3.1 expert group, with no particular proposal being put forward as of today. A second point worth discussing in some detail is related to extensibility, which you may remember is one of the goals of Java EE 6. As a feature, extensibility interacts with profiles, allowing some interesting scenarios to be played out. First of all, in the web tier extensibility refers to the ability of taking advantage of third-party frameworks with a much simplified programming model. Developers won't need to manually edit the web.xml descriptor to add context listeners, filters, servlets and servlet mappings per the instructions given by their favorite web framework. Rather, adding a third-party jar to the web application will trigger the addition of all these elements, with no developer intervention. We expect that this feature will cover the requirements of all major web frameworks such as JSF, Struts and Spring MVC, scripting solutions like JRuby on Rails and Grails, WS-* web services following the JAX-WS 2.0/JSR-109 model and RESTful web services written to JAX-RS 1.0. One important point to note here is that extensibility is agnostic to whether a technology is based on a JCP standard or not. Extensibility though is not limited to web technologies. Looking at existing JCP standards, it's going to be possible for a product that implements the Web Profile to also include additional technologies. The required precondition is that the technology in question must have a standalone TCK. This applies not only to technologies which are independently defined, but also to those who are required components of the full platform. For example, assume that JAX-RS 1.0 (JSR-311) becomes part of Java EE 6. None of the two Web Profiles (A/B) includes it as a required component. Still, since JAX-RS 1.0 plans to offer a standalone TCK, Web Profile products may decide to offer support for it out-of-the-box. The difference with the case of a developer dropping a jar file for a JAX-RS implementation into the WEB-INF/lib directory is that the vendor of the Web Profile product would have certified the JAX-RS implementation and would presumably be supporting it. Currently, not all technologies in Java EE 5 have a standalone TCK. For example, neither EJB 3.0 nor JTA 1.1 do. As part of the conversation in the EG around profiles, we at Sun have offered to make many more TCKs available in a form that is suitable for running them on a Web Profile product. These include TCKs for technologies like EJB 3.1 Lite, JTA 1.1 and Connectors 1.6. We believe that this will empower application vendors to ship Web Profile-compliant products that offer more than the minimally required technologies, to help bridge the gap with the full platform. As an aside, I should point out that the recent trend toward more modularization in application servers will work very well with extensibility, by delivering a simpler, more effective way to manage the versioning and availability of libraries to applications. As we expand the freedom to combine technologies in a product, the issue of compatibility requirements that span multiple technologies comes to the fore. For example, the Java EE 5 specification contains requirements that servlet containers must honor wrt the availability of JTA. The plan for Java EE 6 is to rewrite such requirements so that they will apply to any profiles and implementations thereof that contain the relevant combination of technologies. Going back to the example, any product conforming to any Java EE profile that includes both servlets and JTA will have to honor those requirements. The rationale has two components: on one hand, we think that the Java EE requirements add significant value to standalone technologies, as testified e.g. by the large number of servlet containers which implement JTA in a way that is compatible with what Java EE mandates; at the same time, calling out the requirements will help ensure that applications that target profiles will work on the full platform. Overall, this makes profiles more than just collections of independently tested technologies, because those technologies will be tied together in interesting ways, deliver more functionality than they would on their own. This brings me to the last point I'd like to make. One concern we heard around profiles is that they might weaken compatibility. Essentially, if my application targets the Web Profile (however defined) + JAX-RS 1.0, then it won't run on any plain Web Profile product. Although that's technically true, it's important to recognize that there is an upward compatibility guarantee in the form of the full platform, at least when the added technologies are required components, as JAX-RS is. This is no worse than (and, in fact, better than) the current compatibility story for, say, servlets + Struts. We do expect though that, whatever choice is made re the Web Profile, we may enter an "experimental" phase in which products with different feature sets will compete in the Web Profile space, until one feature set prevails. I'd describe that development as welcome and look forward to standardizing the winning feature set in a future Java EE profile. The Web Profile itself may evolve in the future by adding more technologies (but not by subtracting them, except via pruning), based on experience acquired after its first release. It's also the case that the full Java EE 6 platform will always be there, offering an ample choice of certified Java EE 6 products from different vendors, to address needs that go well beyond what the Web Profile offers.  |
|
May 2008
Search this blog:CategoriesCommunity: Java EnterpriseJavaOne Archives
April 2008 Recent EntriesMore fun sessions at and around JavaOne | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
Roberto Chinnici is a senior staff engineer at Sun Microsystems, Inc.
where he works on the JavaTM Platform, Enterprise Edition, with
particular focus on Web Services and Ease of Development. He is the
specification lead for the JAX-RPC 1.1 and JAX-WS 2.0 technologies
and an active participant in W3C and WS-I working groups.
 java.net RSS Feeds
|
