Enter The JBoss Matrix

Various JBoss dudes post.

Available categories: [/]

Sun vs Red Hat, who is more Open Source [Permalink]

Tue Sep 28 15:42:14 EDT 2004
Category [mfleury/]

I have just read this article about the recent blog war between SUN's Jonathan Schwartz and RedHat's Tielman. I must that I am a bit annoyed by this war of words and for various reasons. First of all, I am pissed off that there is a blog war with SUN in which I have no part to play. It annoys me given my long nasty history there. In this particular case, I am actually more on the side of SUN. RedHat is really out of line in its criticism of SUN. They should look at themselves.

I have several problems with the RH position and how they claim to represent the open source community with sentences such as, "We the open source community".

  • SUN is right to call RH on this. Today RH *IS* a proprietary vendor. Their whole business is around proprietary wrappers to Open Source Linux to drive the subscription business.
  • RH is a PACKAGER, not a technology house. How do they DARE call SUN on technology innovation. SUN by all measures has been a star in technology. SUN created more technology over the years than RH ever will, JAVA, NFS (open source) etc. RH is a packager, it doesn't create JACK, it doesn't create Linux, it wraps it up in proprietary shit. And no the contributions that they make don't really count. Linus Torvalds creates Linux.
  • RH likes to pretend they are the open source community, waiving its flag. While this used to impress Wall Street it doesn't impress us. RH is really a LINUX PACKAGER (and a proprietary one at that), today the Open Source != Linux. MySQL and JBoss are the new stack players up from the operating system. Don't speak for me.
  • Instead of asking SUN to open source java, why doesn't RH create the best VM for linux? that would boost the adoption of Linux in the enterprise. Today Windows is still a better platform to deploy Java, period. Oh yeah, I forgot, RH doesn't actually create any significant technology.
  • Professional Open Source, a la JBoss/mySQL, to me is the real open source. We professionalize our communities and make money FOR OURSELVES AND OUR FAMILIES not for some greedy 3rd party packager.
  • But what really gets me is this: Our own talks with RH broke down, RH is NOT IN THE BUSINESS OF PAYING OPEN SOURCE DEVELOPERS, we are, that is why we created JBoss inc. RH wanted to keep the services revenues all to themselves. That is the dirty little secret, so for them to come out and claim they are the open source when we know the reality is distasteful. How can RedHat have the guts to say they represent the open source community when they balked at a simple deal with us where the actual developers of open source would make money (aka professional open source)? Companies such as HP, Novell, CA and Unisys are today our partners, and don't balk at paying us, in fact they are happy to do so as it keeps the open source communities we sponsor healthy and running.

Not to say that I completely side with Mr Schwartz on this one. We have had our differences with SUN in the past and still today in the field they try to compete with us in sales (emphasis on "try to"). SUN is always a bit hypocritical when talking about open source, just like IBM is. These companies embrace open source where and when it enables them to compete against MSFT but when it comes to their own beef (do you see IBM open sourcing DB2/Websphere?) they show their true colors, and trust me it isn't pretty. We know, we deal with the "real politik" side of this every day in our sales organizations.

So to me both SUN and RH are open source "wannabees", or as one of my developers put "open source girly men". They all want to represent themselves as "friends" of open source. One thing that Tielman is right about is that "open source doesn't care about you". I agree, stop talking in our name, today it is a mosaic of people and models. We push our "professional open source" model. We think of ourselves as the "REAL open source". We are open source professionals that make a good living at it, built companies out it. We are not third party packagers fleecing open source developers and refusing to pay them or corporate entities desperate for some buzz and OSS credibility.



PS: So my wish came true and I joined the blog war in the press. ZDnet covers these points in a radio interview.

Posted by: admin
Comments [15] | Trackbacks [1]

From GPL to BSD to LGPL: On the Issue of Business Friendliness [Permalink]

Mon Aug 02 12:27:50 EDT 2004
Category [mfleury/]

Open Source starts with licenses. The topic of the "business friendliness" of licenses is a recurring one. We will argue here that LGPL is the most business friendly license around. We will also argue that "business friendliness" is something that goes way beyond the licenses.

The GPL license comes from the Free Software Foundation (FSF). FSF licenses have a strong notion of property. Communal property is strictly enforced by quid pro quo that is built into the licenses. It basically says that if we give you something, you must give back. It is that simple, FSF licenses create a positive feedback loop.

The main difference between GPL, LGPL and BSD is that the BSD does not have this notion of quid-pro-quo. Yet many BSD fanatics rant about "business friendliness." "Steal this code" is what the BSD license basically reads. It is a license to steal. And who does that benefit? "License to steal" licenses are friendly to the very small subset of vendors, those who are in the business of creating proprietary software derivatives and selling them (Apple OS/X based on BSD, IBM WebServices based on Apache Axis). BSD IS GOOD FOR A MINORITY OF VENDORS BUT LEAVES EVERYONE ELSE IN THE COLD. LGPL is the opposite. It is friendly to the majority of actors, including developers, third party vendors and, most importantly, the end-user. In terms of business friendliness we believe the LGPL is a far better choice.

BSD is not friendly to developers. Let me explain. They get ripped off by or, ultimately to make ends meet, must seek employment with proprietary software companies that compete with their products. Interestingly enough, predominantly FSF style licenses historically have led to companies where the community of the core developers professionalizes itself (Linux, MySQL, JBoss). Second generation open source companies control their destinies. The quid-pro-quo mechanism says that we usually see the QA patches coming back and that there is no benefit for our proprietary competition to fork our codebase to build theirs. The success of Linux over FreeBSD is usually historically attributed to this very feature of the FSF licenses, lack of proprietary forking. Solaris however was loosely based on BSD and overtook BSD quickly. As a developer, the choice of BSD licencing means giving your competition the rope with which to hang you. LGPL, on the other hand, protects the developer while allowing third party applications to embed. FSF licenses are developer friendly.

But most importantly, the LGPL is friendlier to third party vendors, the mass of OEM/ISV channel users as well as end-user IT organizations. BSD fanatics fail to recognize the difference between third party vendors and competing vendors. The difference is huge. First of all, the LGPL license, unlike the more stringent GPL cousin, actually allows for embedding in third party applications for redistribution. IT WAS DESIGNED FOR THAT. This third party embedding has been the only factual advantage touted by the BSD crowd over GPL. It is a false and moot point of comparison against the LGPL. Today JBoss, which is licensed under the LGPL, holds the #1 market share as the application server of choice for third party embedding.

But it gets better than this, the one critical advantage the LGPL holds over the BSD is that feature of quid-pro-quo and thus project stability. Projects fork less and positive feedback keeps them growing. BSD fanatics tend to point to the success of Apache as proof of the superiority of the BSD license. When they blather on about the greater business friendliness of the BSD license, they conveniently forget to point out the far greater success of GPL-licensed Linux. In fact, I submit that the Apache project would have been successful if it had been licensed under the "walla walla" open source license. Apache was successful because it was the first decent http server, and it was released at the time that market was being born. Apache was first in the market, got big fast and essentially "nuked" the possibility of a profitable market for the core product. There is no billion dollar http market, the way there is in the app server/data base/operating systems spaces. In those smaller spaces where there is value add in http land, such as SSL, this has been done as a proprietary forks by multiple vendors.

Let's take an example we at JBoss had to live through, the ill-fated Axis project. JBoss Inc. was a third party packager of the technology. When we initially saw the Axis project (IBM's implementation of SOAP distributed under BSD style licenses at Apache) we first thought it looked good on the surface of things. We started building our own solution on top of Axis. We are paying the price of this decision today. IBM pulled support away and forked internally, something encouraged by BSD licenses. With a semi-stalled Axis codebase, JBoss Inc. needed to rewrite a lot of Axis code just to be up-to-snuff with the J2EE testsuite. Since we have no professional interest in giving this code back to our competitors, we will not release our commits under BSD. We have committed this code in the JBoss source tree under LGPL, ironcically participating in yet another mini-fork of a BSD-style codebase.

That kind of instability in a BSD-licensed project, allowed by the license and compounded by the interests of a minority of vendors (including us), is the worse thing for an end-user. IBM has burnt a lot of third party ISVs with their fork of BSD Axis. When I hear the pony-tail fringe of the open source community chanting peace and love, the virtues of BSD licenses being "more open," I think to myself "more open to getting screwed by your own competition."

Bottom line is that LGPL and GPL, by disallowing proprietary forks, are friendly to developers and end-user communities, as well as the vast majority of third party vendors that will commit and invest in those projects. Stabilization of open source communities under FSF licenses is something that is getting clearer by the day. FSF creates stability for end-users, third party vendors and the developers themselves--and that is business friendly.

Finally I will argue that all the previous argumentation about licences and the past 5 years of religious debate on this theme is mostly irrelevant noise. At the end of the day, licensing is but one aspect of business friendliness. The truth is that without a company or companies which employ the core developers of open source, it doesn't work. It comes down to open source projects controlled by a single company or multiple companies, as well as the few individuals who made enough money in the Linux boom to contribute to that project without a professional employer. Linus Torvalds told me that the Linux project has about 1000 read-write committers, 900 of which gave one patch and twenty of whom write 80% of the Linux kernel code--all of them funded full-time.

"There is no such thing as a free lunch." These words by Nobel prize-winning economist Milton Friedman are as applicable to open source today as they are to general economics. The unfounded optimism with which businesses and individuals believe that open source is some sort of magic medium that will grow successful open source projects and communities out of nothing never ceases to amaze me. At the end of the day, it is all about the money. Yes, individuals will devote time to open source because this is what they enjoy doing, because they wish to learn, because they want to build a solution that is not currently available. I started out this way, as did some of the key developers hired by JBoss Inc. However, there comes a time when reality comes knocking at the door, when developers need to earn a living, when they need a personal life, and devoting every spare minute to open source, that is every spare minute left after a demanding full-time job, this just doesn't cut the mustard. People may contribute the occasional patch and bug fix to an open source project, they may start pet projects, however, in order for them to commit long-term, in order for them to structure the development of the project in a professional manner, to offer the level of support demanded by enterprise consumers--open source eventually needs to become their full-time job, hence "professional open source."

In JBoss we achieve business friendliness by "professional open source." By enabling developers to transform open source into their full-time job, to structure their open source communities, indeed professionalizing them, we are able to not only enable them to earn a living but also facilitate their interaction with third party business interests, end users and OEMs alike. Companies all of the sudden have an entity to deal with. THAT is business friendly.

Growing a business out of the community and standing up to take professional responsibility for our software is business friendly. Computer Associates, Unisys, AtosOrigin, Intel, Novell and Hewlett Packard are JBoss Inc. partners. JBoss Inc. presents a business face they can interact with. End users, OEMs, ISVs and SIs want to know that there is a company directly accountable for the codebase on which they will build and deploy business critical applications--not some loose affiliation of goodwill that will fall apart when the going gets tough. They don't want to do business with a website, they want to do business with a real company, they want a "throat to choke." In short, JBoss Inc. looks like a traditional software vendor with the exception that we don't charge for our licenses.

Comments [1] | Trackbacks [0]

EJB3.0 JUG tour feedback [Permalink]

Mon May 24 12:09:20 EDT 2004
Category [mfleury/]

I have been touring the US with Gavin, doing JUG talks (Java User Groups). Gavin opens up with from EJB2 to hibernate to EJB3. Then I talk about "transparent middleware" and systematic use of annotations in J2EE. We have been doing a lot of work on the Expert Group for EJB3.0, time to get it public, the crowds are usually big for the respective JUGS.

The first result that is very popular with developers in JUG talks is the demise of ejb-jar.xml. With systematic use of annotations, basically the XML in ejb-jar.xml is GONE. We always get laugh and cheering when we show that slide. Inevitably there is someone in the audience wondering about "how do I over-ride the defaults".

The answer to that question is clear and we need to articulate it at the specification level as it would put that question to bed. Basically the first layer is annotations with defaults, then on top you can provide an XML file (ejb-jar.xml) that selectively and differentially over-ride defaults.

There is invariably someone who is pissed off for some reason and that goes in a rant AGAINST annotations. I am very tired of these guys. Basically XDoclet and .net show that use of annotations are a good thing. Even mark happner (J2EE honcho at SUN) says annotations is the biggest thing to hit middleware. POJO middleware is done with annotations.

Instead of working from interfaces that your objects must implement (thing javax.ejb.*) you just tag an existing class with @session or @entity. That is goodness because instead of starting your object inheritance tree with the spec class you start with your own class. You can apply EJB behavior at any level of the graph.

Another thing that is fairly popular is the use of IoC to manage dependencies in the container. We use the @inject tag on a reference to instruct the container to provide it. Then a thread of 2100 posts disected whether "@inject" was a good name or not.I like tags to be COMMANDS BY THE DEVELOPER TO THE SYSTEM. Hence the use of VERBS. They are ACTIONS.

Obviously we get great feedback on the standardization of advanced Hibernate features. Gavin explains the intertwined history of EJBQL and Hibernate QL. A full POJO model for transparent O/R persistence seems to really grasp your attention. Questions on JDO always pop up, rarely followed once we explain focus on O/R mapping.

Entity model seems to be solid. Essentially we have removed the use of Homes entirely from the Entity view. You can now use the new() operator on entities and removed CMR as a result. We replace the home with a generic "Persistence Manager" that exposes the queries. We rarely get questions on that part, which may indicate silent approval?

But probably the biggest nod I get from the audience is on simplification of programming models. We also removed the home model for session (as well as entity), although sessions can be remote still through JNDI lookup (I am arguing for client IoC as well). The programming model is pure POJO and I can see some guys having "ahhh!" moments right there.

Briefly put, the new session EJB is the old fa├žade and it can control the Hibernate session association under the covers for example. This is something that has confused many people in hibernate. Also sessions talk to entities and it has the potential of helping us rethink how we use EJB to build web solutions. That part I don't go into that much.

In some talks some guys hit the nail on the fact that we are talking "light-weight" containers. While I think the discussion is a bit of a red-herring (you can make JBoss as lightweight as you want from a codebase standpoint), the discussion on light-weight programming models and "POJO programming" is raging. POJO middleware is the future.

All in all I think the feedback is pretty good. Seeing the faces and reactions in the crowd, it seems our simplification effort is hitting home. The work is all about the word "simplification". Removal of artifacts and systematic use of annotation is making EJB3.0 a lot simpler but also we hope more powerful to use.

One thing I am dissapointed in is the lack of advanced discussions in the JUGS. Maybe they are not the right forums? It seems most just try to digest the information, it is very normal I guess. Bill Burke is working on a EJB3.0 prototype that should be ready in a couple of days/weeks. Then you guys will have something real to play with.

The full spec may be ready for public review by J1. Maybe, that part is out of my control. I know that we plan on making more noise at JavaOne with Linda and the rest of the crew. Also read bill's post below on annotations and AO. Bill has finished the annotations framework for AO so we can start implementing all of this easily.

We hope to see you on the road and we will be in the following cities on the following dates.

June 8 :: Los Angeles (http://www.lajug.org)
June 9 :: Silicon Valley (http://svjug.org)
June 15 :: Toronto (http://www.j2u.org)

Have a great professional open source day.

Comments [4] | Trackbacks [0]

Response to JBoss Fake Posting Allegations [Permalink]

Fri May 21 11:20:06 EDT 2004
Category [mfleury/]

You may have heard about recent charges in online forums that some JBoss employees, including me, were personally involved in anonymous postings on developer sites. The practice, known as "astroturfing", is wildly popular on sites like Slashdot that actually let you post as "anonymous coward". JBoss has the reputation as an in your face, straight up, tell it like it is company. I personally don't need a mask to speak my mind and one thing I can't stand is two faced hypocrisy. This has made us many friends and a few critics.

As you may know, the open source community would not be what it is today -- a real challenge to traditional software models -- without the strong opinions and outspoken voices of the developers. I myself am among these voices. But we do not always see eye to eye on the evolution of the open source movement. Some prefer subsidized open source, whereby they work corporate jobs and contribute/moonlight on the side. Many others, including us at JBoss, prefer the "Professional Open Source" model, whereby it is our job to work on open source and free software all day long, all the time. We all passionately believe in the standalone potential of professional open source. JBoss' growing traction in the enterprise market, our expansion of products and services beyond the original JBoss Application Server and our recent funding from VCs have intensified scrutiny on our community and company, for good and bad.

JBoss is transitioning as a company to deliver on our commitment to make open source a safe and viable alternative for companies such as yours. We have hired the most talented developers - many of whom are innovators and lead developers of popular open source projects. We provide them with the means to continue developing and support these products while creating value for our community and wealth for themselves. As a company we are growing rapidly to meet the expert professional services needs of our customers and partners. We want to be role models for open source developers around the world. To do so, we must hold ourselves to a higher standard. Our visibility and success puts our customers and partners in a situation where you expect and demand that employees of JBoss Inc. hold themselves to that higher standard. Let's put the professional back in professional open source. "Astroturfing" is hereby banned at JBoss, starting with me.


Marc Fleury
Founder, Chairman and CEO
JBoss, Inc.

Comments [136] | Trackbacks [1]

Transparent middleware, EJB3.0, Las Vegas TSS [Permalink]

Tue May 04 10:27:40 EDT 2004
Category [mfleury/]

Transparent middleware (tm) at AOSD

So I took my own sweet time to finally blog about the AOSD conference. Sorry for the delay. AOSD was a good event. It definitely is refreshing to go for a full 3 days and listen to the latest innovation in AO. The conference is still a bit young, when it comes to integrating industry players, but it is on a good growth path. The focus on aspectJ was lesser this year (which I feel is a good thing) and new innovative technology seems to be addressed by the community.

The first thing I want to mention, if you haven't seen it already, was the very public commitment by Daniel Sabbath to AO technology internally at IBM. We had met with Danny back in the fall and essentially pitched him AO hard. It was good to see the announcement rehash a lot of the themes that are dear to us, mostly the applications of AO to middleware. IBM backing is good.

Ok, the next big thing to hit me was a little session on the first day, in a workgroup, where some guy was presenting an AO IDE. His IDE dealt with C code and he could highlight pieces of code, remove others from the view. Code showed up in different colors that he could identify as belonging to an aspect. By switching on/off he could look at a given 'concern' in code. And then it sort of hit me. It WAS AO. It dealt with untangling of code and how a programmers addresses concerns individually. Doing it with interceptors is definitely a GoF compliant way of doing it but that approach was still valid. AO is about untangling code and about presenting to the developer simplified ways to look at his code concerns. I understood that the IDE WAS in fact very AOish.

Fine. So AO enables us to untangle code. But what does that mean for the J2EE developer. Take EJB. EJB has powerful set of services that you can leverage but the programming model to do it is still intrusive. In short you code to interfaces, you know about abstract getters and setters and you write a ton of XML. In AO talk, programming an EJB is tangled code.

Transparent middleware, simplifies programming models, keeps them as close as possible to POJOs. This is where EJB3.0 is going, pojo persistence for entities and pojo programming models around. The closer the programming model is to pure java the closer you are to untangling the code, since the J2EE programming model doesn't intrude on your source. AO middleware is about transparently (or as transparently as possible) weaving aspects in Pojos. Once you built your graph of objects you apply the aspects of persistence, remoteness, cacheability, transactions, security, yada yada. But these behaviors are not inherited from a framework superclass.

Aspect weaving, use of annotations, and non-intrusive programming models.

One of the simplest ways to weave behaviour in POJOs is the use of annotations. Developers have grown to use and love XDoclet style approaches. With the advent of JDK1.5 and its native support for java annotations, we are in a position to standardize their usage in J2EE.

I can see the day where someone will drag and drop a standard O-R mapping aspect (hibernate and/or EJB3.0) onto an object and a pop-up diagram comes up and asks for the fields to mapped and the tables to map it to and then generates the annotations or the XML file.

What we are aiming for is a simplification of J2EE. J2EE 1.5s theme is going to be SIMPLIFICATION and EJB3.0 is the first serious attempt at drastic simplification.

.NET makes extensive use of the annotations approach. In that sense .NET is an AO framework already, simplified development. C# leverages the .NET features through AO constructs. .NET for example provides trivial ways of making an object remote and/or webservice. A simple tag saying 'this is a webservice' will do. To make an object remote in J2EE by contrast, is more complex today, in you can either work with EJB interfaces or RMIC extending UnicastRemoteObject, etc etc. We are addressing that complexity in EJB3.0.

Simplify the framework and you will have development environment that even more simple. We are talking about a drastic simplification of the J2EE programming model itself as opposed to the current status quo with wizards on top. There is so far the wizards can go with complex underlying frameworks.

Middleware as a collection of aspects, the path to custom middleware.

Something very interesting is going on right now in the industry. Large corporations are rethinking their middleware infrastructure. The way they think about their infrastructure departs from the traditional 'buy vs make' and open source offers a third way which combines the best of both worlds. Many banks, many telcos, many industry heavyweights build their own framework at great cost. Well that gets to be a pricey proposal as middleware continues to evolve.

On the other hand, the buy decision many not work as it means lack of control of the infrastructure if it is a proprietary black box. Many companies have years of investment in parts of the infrastructure. The key of course is modularity of the JBoss framework. A CTO can now keep its value add and reassign people where it makes business, building on a open source codebase while retaining their differentiators.

Aspects bring a new dimension to middleware assembly. Middleware is a collection of aspects with many of them being completely standard (OR persistence, transactions, remoteness) while there are many extensions to these that are highly proprietary. Think about the custom encryption for example. We have seen military agencies secure connections on JBoss by adding aspects in the flow of invokers that encrypt and decrypt the message with the latest and greatest NSA algorithm. Great usage of AO in JBoss3.x. Now apply this to any object as we are doing in JBoss4 (not just EJBs or MBeans) and you have created a new container with secure communications.

Creating ad-hoc containers is what we are talking about. When the standard, out of the box, J2EE container doesn't fit the bill, an AO middleware construct with usable aspects enables vertical industries to extend the behavior for their own needs. Add to that the open source nature of JBoss and the stability of the aspects we have been shipping as part of our containers for the past 3 years and you have a brand new way for these commercial entities to think about their infrastructure.

IBM is right in saying that 'middleware is everywhere' in their commercials, but we feel it will be 'transparent middleware'. The future of middleware may look very different than it does today, generic containers, certified by these architecture committees is a simple way for them to protect their existing investements while transitioning to a more modern and commoditized infrastructure a la JBoss.

New Aspects

One of the net positives we came out with from the conference is new aspects. It turns out for example that Observer/Observable, the pattern, is an aspect. There are research papers being published on most of the GOF patterns appearing as aspects. That is very interesting as they used to be implemented in Object Oriented fashion. Turns out that behavioural patterns are good candidates for Aspectization. Any object with state can be made observable by adding the self-described observable aspect. What was funny is that the presentation that showed it was actually a bit boring and Adrian Brock stepped out of the room to go code it. By the end of the day he had the observable aspect all done. It is in CVS and there is a wiki entry on our website.

Bill has recently come to the realization that IoC was also an aspect, he recently blogged about that as well. A good discussion ensued on TSS. We are at a point where JBoss4.0 going to JB5 will be more and more aspect based.

So what does AO mean for middleware end user?

This is still a hot debate. I argue that it doesn't mean much, yet it will change the way we build middleware as an industry. I am of the school of thought that AO is still too early for end-users as a raw construct. However AO as a middleware base is a god send. It enables us at JBoss to easily assemble a container (including an EJB container) and DELIVER SIMPLE AND TRANSPARENT PROGRAMMING MODELS TO END USER DEVELOPERS. If we can come up with tags and simple metadata for end-user developers to work with then we have greatly simplified middleware development.

As said above, today most middleware development is done through API standardization and clear semantic standardization. Remove the API, keep the semantics of the aspects crisply defined (say the tag definitions of declarative transactions and what they do) and you simplify the development. So what AO is bringing to the table, whether it be based on real AO framework or just leveraging tag driven development and you simplify J2EE development as a whole. Again start with the frameworks and libraries instead of relying on the tool to simplify your job. AO in its raw state will most likely not be used by many developers. Meaning that there won't be thousands of Bill Burkes, Adrian Brocks and Jonas Boners writing AO frameworks. I don't even think you will have thousands of aspect developers. The guys who write these generic aspects themselves will be a few guys on large companies standard efforts perhaps. Granted JBoss inc is a hotbed of aspect heads. You may have 2 or 3 guys like that in the next coming 2 years per company. These will be the framework guardians, the guys who assemble proprietary containers for companies leveraging existing infrastructure and open source code like JBoss. What you will have in the millions though, are guys that reap the benefits of AO with tag driven development either in .NET of JBoss like Java frameworks. Millions will use transparent middleware, that is the whole point, if AO is successful it will mostly be INVISIBLE and TRANSPARENT to end-user programmers. One day you will all walk through walls.

EJB 3.0, the birth of transparent middleware.

But until that day, the day where you all walk through walls, let's make sure you don't bang your head on the walls for simple stuff. EJB3.0, of which JBoss is a contributing expert member, greatly simplifies the programming model. To lay rumors, yes both Gavin King and myself are on the committee. We are working on lightweight persistence (POJO persistence) and simplified programming models. EJB3.0 will be big, it will be surrounded by buzz by the javaone timeframe and it will be good. We will be pre-announcing it at TSS, the Server Side symposium in Las Vegas at the end of the week. Linda deMichiel, the speak lead will be talking about EJB3.0 be sure to not miss it. I will talk about it in my keynote. Gavin King will be talking about Hibernate and EJB3.0, Cedric Beust of BEA is putting together a panel discussion where we will all show up. Be sure to not miss any of this. It will be the talk of the town at Javaone and you want to be up on that tsunami by then.

Simplifying EJB relies on a lot of concepts that I have just introduced. EJB will not be an AO framework per se but EJB3.0 will make extensive use of annotations, will introduce many concepts of hibernate, the HQL language is being looked at which was an extension of EJBQL in the first place. We will give you transparent and lightweight persistence for Pojos as entities with advanced queries. We will greatly simplify the programming model (no more factories and such) and will even introduce some IoC for good measure and buzz-word compliance. So anyway it will be great stuff, the kind of stuff that lasts for 5 years. And Vegas TSS will be the coming out party.

Remember we love you and we hope to see you in Vegas.

Comments [7] | Trackbacks [0]

AOSD 2004--Looking at the future of AOP [Permalink]

Mon Feb 09 23:04:10 EST 2004
Category [mfleury/]

One of the big advantages of Open Source is its symbiotic relationship with academia. Because the code is open and free, academics get a public codebase on which to test their ideas. In return, I believe that Professional Open Source software benefits from academia.

In graduate school for my Ph.D. in Physics, I remember a common fear among academics--the fear of "ivory tower" isolation and "the real world out there." Computer scientists are a different breed. They already embrace open source as the favored way to distribute their work to a wider audience. More often than not, their work makes it to the "real world."

We have benefited from this phenomenon at JBoss. Already we use JacORB, which was developed in academia. Professor Francisco Reverbel maintains our IIOP base. Francisco is based out of Brazil and we sponsor some of his grad students at the University of Sao Paulo with a JBoss grant. Our own Bela Ban, the lead on JGroups, developed JGroups while doing his postdoc at Cornell. More local to Atlanta, we have done work in the past with Professor Smardakakis at Georgia Tech, where we integrated NRMI as a set of client-server aspects to deliver pass-by-copy-restore semantics on RMI calls. Finally, we base our own AOP framework, JBossAOP, on Professor Chiba from Tokyo Institute of Technology's excellent Javassist.

Bottom line is that I like to browse what is going on in academia. This year, as a member of the selection committee for the AOSD 2004 (Aspect Oriented Software Development) conference to be held in Lancaster, UK this March, I got to be the eye in the sky for a little while and survey the state of the art in academia. The paper review process provided an exciting preview of the things to come in AOP. Here is clearly one field of computing where academia is leading the industry.

AOSD 2004 is a young and booming conference. It used to be a conference for experts, the kind I went to when I was a grad student, where you got to meet the 5 other people interested in a narrow field of research. AOSD aims higher. AOSD wants to grow into a wider conference with more industry appeal, while retaining quality...along the lines of Oopsla or the annual Middleware conference. We believe AOP is ready at JBoss, ready for mass adoption, and this is also the belief of the academics who are leading the way. AOSD is traditionally a very selective conference. This year was no exception, even with the wider focus. Out of hundreds of papers submitted from around the world, many of them high quality, we had to pick 1 out of 10. It was a competitive selection process and only the best papers were discussed.

While I can't talk about papers in particular, I can give an overview of some of the broad trends.

Not surprisingly many of the papers had to do with AspectJ. AspectJ is still the dominant platform at AOSD. Most research is done on it. There were extensions to AspectJ, refining AspectJ. Papers on scopes were particularly interesting to me. AspectJ is today under the capable leadership of Adrian Colyer from IBM.

Other papers that caught the interest of the committee discussed automated refactoring techniques and "identifying aspects" automatically. It seems promising on the surface of things and a sure sign of the wider adoption of AOP and refactoring techniques. I am not personally a big believer of these automated approaches (and therefore didn't review them) but the promise of being able to find an aspect in your code by pressing a button does seem like a valid field of research.

Some papers discussed the applicability of AOP to middleware. These were very relevant to me, not only as JBoss, but in general as a tremendous use case for AOP. These papers were of great quality, and I am sorry not all of them made the final cut. I encourage you to go the conference if anything to get the primer on middleware applicability. A lot of these papers referenced JBoss as an example platform and it is good to see the AOP'ers look at middleware as an AOP poster child.

I will make a special note about Gregor Kiczales, Gregor really pushed for the open source frameworks to be represented with a definite game plan to promote all of the frameworks that did AOP. It was a laudable effort even if most of us aren't versed in the writing of academic papers. We at JBoss didn't have the time to submit a paper on JBossAOP, which we will probably do next year, but we do have a long tutorial session you may want to check out.

Then there were purely theoretical advances. Some of the papers that stick in my mind are those that dealt with combinatorials of aspects. That, in my opinion, is one of the most important fields of research. I'll elaborate. The promise of aspect oriented middleware is the capacity to mix and match aspects and apply them to POJO/POJI, thereby building the equivalent of custom containers. The question that always arises has to do with the validity and predictability of the semantics such an assembled container offers.

For example, the EJB spec defines very precisely how transactions interact with persistence and cache, etc; the semantics of such a container are extensively documented in the specification. This is important as developers can then have predictable behavior of applications. The aspects that share state can be interdependent, almost by definition. Some aspects are "commutative" where order doesn't matter; some aren't and order matters. Some papers introduced notions of loose and strong dependency of aspects. Good stuff. Understanding and modeling these interdependencies with a formal model is the basic theoretical work that will prove the correctness of our POJO middleware future.

I also believe in a brute force approach to solving the problem of combinatorials (I was an experimentalist in my Ph.D.) since we have a finite number of aspects for systems: persistence, cache, transaction, remoteness, acidity, retry, security, monitoring. Thus, bruteforcing our way through all possibilities seems feasible. I made that very point at IBM research when I was giving my presentation. It got a lukewarm reception. In any case, a real theoretical framework is useful in general, not just for middleware. My problem is that I don't know the first thing about algorithmic formalism, so the formalisms used for proofs were WAY above my head.

Last but not least, we looked at papers covering the standalone aspects usable in middleware. This was my favorite category. It deals with identifying truly orthogonal middleware system aspects. Some papers identified Quality of Service as an aspect, for example. Other stream-based semantics for remote calls, like NRMI, were already introduced as aspects. It is very promising to think about the possibility of "bolting-on" the quality of service aspect with a framework that controls client- and server-side communication for objects in your application.

Why am I so excited about system aspects? Well, it is rather clear that middleware is really a collection of system aspects--JBoss is already implemented that way. Therefore, these system aspects are candidates for JBoss'ification, thereby enhancing the semantics of the EJB container or the JBossAOP container in general. In fact, most the papers in that category were talking about CORBA proof of concepts and J2EE/JBoss proof of concepts. That is very exciting to me, since it means low hanging fruit, where most of the hard work has been done and we just "package" these innovative aspects for the larger industrial consumption.

Future direction? I would like to see more of these system aspects formally presented in papers, so we have an archive and recipe of what the aspects do. I would have liked to see more about scoping of configurations, since this leads to context-aware computing. I think the AOP frameworks are at a point of sophistication where we can start using them systematically to identify aspects. It is time that AOP came out of academia and toy-level usage by industry. A clear way to get there is to package useful aspects as part of the modern middleware offerings.

So anyway, the field is very alive, indeed growing in the right direction. I encourage you to come to this conference and hope to see many of you there. The conference is in Lancaster, March 22-26. JBoss is a proud sponsor of the conference (alongside IBM and Microsoft Research). Registrations are open and about 450 Euros for early registration. Tutorials are at about 120 euros. We are giving a long tutorial on JBossAOP. Bill Burke, Adrian Brock and myself will be there.


PS: Academics in the field get in free at Advanced JBoss trainings, just in case you didn't know.

Comments [7] | Trackbacks [0]

He's a Techie! [Permalink]

Wed Jan 28 13:07:38 EST 2004
Category [mfleury/]

When I was 16 years old, I was trying to decide whether I should study business or engineering. I was good at math and sciences, so I was drawn to engineering. Also, in France, engineering is viewed as a prestigious job path. I wanted advice, so I talked to my father about this. He was a French business school grad and a successful manager at Procter & Gamble, where he spent his entire career.

I remember that talk. He thought that, in the future, technical skills would be more important. He explained that it was easier for techies to become businessmen than the other way around. I needed to learn the hard-core skills, I needed hard science it seemed. That was the gist of the message.

So I went for it and was good at it. I liked hard-core stuff. Math, Physics. I was your typical nerd. At the time when American kids go to university, many French kids prepare 2 to 3 years for the competitive exams for the Grandes Ecoles, considered to be the country's top schools. I remember my 3rd year in "Mathematiques Speciales;" I remember doing industrial drawing on Saturday nights, a mandatory discipline at the time of my prepa "preparatory classes," around '86. In France, growing up as a geek was OK. It was even good.

In France, (as it appears to me to be in countries like Germany or India?), engineering is the top profession. In France, the social status of a graduate of Ecole Polytechnique rocks. The fact that you don't have to exactly prove much after graduating from Polytechnique or the other French Grandes Ecoles, and the fact most people will or will not have certain opportunities in France on the basis of what they achieved at nineteen or twenty years of age is another issue. I wasn't thinking about that. I was young and I happened to have the skills my country favored. If you are American, imagine Stanford or Harvard MBA, Law or MD and you are getting warm. You are looking forward to the money, the good jobs, the chicks.

Obviously, this is not the case in the US. An American who was visiting France once told me over lunch "did you ever realize that in the French word ingenieur you have the word genie or 'genius,' while in the American word engineer you have the word 'engine'?" That should have been a warning sign.

Like the Russian cabbie in NYC who was a nuclear engineer back home, I was somebody where I came from and I hadn't crawled through 10 years of differential equations to be talked down to by some pretty boy with half a brain. The reality of the situation was that I was in a second-class job at a large US technology firm.

I started out in sales in France, then transitioned to engineering, I was offered a full sales job at Sun, but wanted to code. For me, hard-core technology was always glamourous. I was in awe of anyone who could code. Through my position at the Sun/SAP Competency center, I started working in SAP Labs in the Silicon Valley, while still with Sun. At that point, Silicon Valley was pumping in engineers from the entire world, people who felt that they were going to "Rome," the center of it all, a place where their skills were needed and would be appreciated. With certain exceptions, a few teams, titles like "distinguished engineer," or a few icons, it didn't take me long to figure out that most engineering jobs there weren't "real." It was '98, the boom days and so many of us were part of "head-count" operations, whose numbers only served to justify the importance of the managers to whom we reported. I made friends among my colleagues, but started to feel like the Internet was where it was at, where I wanted to go with engineering.

'98 was the onset of the Open Source movement as a mass media phenomenon. There were the hard-core techies. I wanted to be one of them, I wanted to be Linus Torvalds. So I took the plunge, left Sun, consulted in the Valley for a little while and made enough money to start JBoss. I digged deeper and deeper and eventually found myself at a place where there was no digging deeper in Java. After three years, I had gotten to the place where I wanted to be in Open Source.

I remember when I left Sun, one of my friends telling me that I was "moving down the food chain". It seemed odd that people perceived my career as "going down" because, in my mind, I was going up. I am very proud I made it as a developer in Open Source, one of the most competitive grounds for developers.

I guess the point of this whole rant is to challenge the attitude reflected in He's Just a Techie-type articles. They demonstrate how engineers fall victim to reasoning along the lines of "I am down and probably deserve it, I am not sure if I am good enough, but please respect me..." Respect? Bah, as if respect was given. Respect yourself! Know your place in the information foodchain. Know your skills are UNIQUE. I was lucky enough to come from a society that puts engineers at the top, which gave me enough of an "ego boost" to cross the desert of a large tech company.

You don't beg for respect. Like the saying in the Godfather, "Real power can never be given, it must be taken," social positions are about power. So for the elite engineering ranks in the US to make it as one of the top professional classes, they need to assert their own power--not adopt a ghetto mentality and feel like they need to mimic the mediocrities in the management ranks, to whose positions they aspire.

For too many engineers the soft "social" skills seem glamorous. Like in a bad 80's commercial, they want to be able to "talk the talk" and imagine board rooms that applaud them for their "MBA brilliance" reflected by some bullshit in a piechart. In fact, I think the Microsoft commercials are great in that way because they spoof the "success guy". They crack me up.

It's a lot easier to become a good presenter than wrap your head around important technical issues. I have seen technical people who were mediocre presenters become superior teachers. It comes with practice. What makes those people UNIQUE is their abililty to create and understand technology in a way that others cannot. THAT is unique, that is hard. Compared to that, the rest is a piece of cake. Engineers, don't throw away and undervalue hard skills and real knowledge just because people who don't have them downplay them. Remember the American Indians in Manhattan who gave up their land for a couple of shiny glass trinkets; stick to your real assets.

The marketing and management people in this industry are fallible. Look at all the Tech Bubble companies that came and went with their hype and their buzzwords. There are plenty of factors that play into a company's success, luck among them; however, it's never a good sign when the promised technology offering has no substance or relevance whatsoever. And I think that if those people had the skills to quickly determine whether the technology was real or bullshit and the ability to scope where certain sectors of the technology market were going to evolve, they definitely would have been better off.

I think characters like Bill Gates are perfect icons for American engineers. Bill is a "freak" in that he codes, runs (or ran for a long time) one of the largest companies in the world and he makes money. In the US, you are almost always either on the engineering side or the business side, but not both. But business is easy, it is about maximizing the money functions, think of it as numbers and don't be too impressed by the hype, the smoke and the mirrors.

One day we will all walk through walls; one day we will rule this joint.


Comments [6] | Trackbacks [0]

October 2004
Sun  Mon  Tue  Wed  Thu  Fri  Sat 
<  Sep   Today    Nov  >

Available categories: [/]

Powered By blojsom   RSS Feed  RSS2 Feed  RDF Feed

html hits: 220