In Neuchâtel, pretty much all public parking slots are now time limited (in order to incent people to go down town using public transportations and probably also because cars are increasingly considered as evil in this 21st century). However, if you do live down town and have a car, you can pay a yearly fee and obtain a certificate that permit parking in the street where you live with no time limit. Fine.
Recently, I thought about obtaining such a “parking certificate” from the local authority. So I went there and the dialog went pretty much like that:
- Hello, I’d like to get a parking certificate.
- OK, no problem. I will need a copy of your certificate of establishment  and a copy of your car certificate.
- OK, but, I know the ID number of my car and I know my name, so why do you need copies of documents you have in the computer next to you?
- Well, but I need to build up a folder with all of that information and send it for approval
- Sure, but if I give you my name and car ID, you can check all of that information, put it in an e-mail and we are done in 5 minutes
- What?!? You want me to do this work for you?
- Huh… yes…
- But, I am telling you I need paper copies that I can forward somewhere else?
- OK, whatever…
This very 19th’ish century discussion took place in 2008, in a canton who was the first one to provide online e-voting (and a bunch of online administration services). Better, all information that person needed is already online: the identity check has been on the police intranet for more than a decade (hey, that is their job after all!) and the car ID validation is publicly available on the Internet. Bottom line, in 2008 some still think that stapling together fakable paper copies of official documents proves more efficient and secure than an online verification against live data.
“If you don’t like change, you’re going to like irrelevance even less.” 
 Document proving that you are living where you say you are living.
 General Eric Shinseki, Chief of Staff, U.S. Army as quoted by Tom Peters in Reimagine, DK 2003.
JBoss AS 5.0: Status June 28, 2008Posted by Sacha in JBoss.
Many have been wondering about the status of JBoss AS 5.0, so I thought I would give more visibility in what we are achieving.
First, a bit of history. In 2001, JBoss was the first application server to feature a complete micro-kernel architecture (based on JMX) – both for applications and for services. In the following years, we gathered a great amount of expertise in that field. In parallel, we did a lot of research in projects like JBoss AOP, JBoss Remoting, embedded EJB3 and decided we needed to be ready for the “next generation” AS architecture. This led to the start of “JBoss AS 5.0” three years ago. The idea was to move to a much more generic micro-kernel architecture that could suit multiple “personalities” (OSGi, JMX, pure POJO, etc.) and fully componentize (through APIs and SPIs) and aspectize our AS down to the bare minimum “Lego blocks”. Also, we wanted our new runtime to have full manageability features as a core aspect, not as an afterthought. The magnitude of these core changes came at the expenses of a reliable roadmap – hence the multiple delays in releasing JBoss AS 5.0. BTW, if you want to read more about the new architecture of JBoss AS, you should definitively read Dimitris Andreadis’s excellent interview at InfoQ.
So, was all of this just a fancy engineering exercise? No, not at all. This investment will have a drastic impact on the overall JBoss Enterprise Middleware offering, its longevity and its ability to adapt to market changes. If you take a 40’000 foot view of the AS market, you can essentially split it in three layers:
- The base runtime
- The core middleware services
- The programming model/API & language
In the case of JBoss, the runtime is the JVM. You can find many non-Java VMs regularly pop-up here and there, but none of them is close to approaching the level of engineering this ecosystem has put into the JVM. The JVM is pretty generic, can support multiple languages and has about 15 years of heavy engineering practice behind it. From mobile phones to Azul appliances, the JVM has shown great abilities. Would another VM come up with better features, fine, let’s move to it: now that the JDK has been made open source, we could adapt it to any other environment while keeping compatibility with the previous generation JVM.
As for the second layer, the middleware services, this is where JBoss excels. We have built rock solid, scalable and flexible middleware services (security, persistence, transactions, remoting, clustering, etc.) that can be re-used among our various platforms, they are our “Enterprise Lego Blocks”. JBoss AS 5.0 will make use of the last generation of all of these services: JBoss Messaging, JBoss TS (ex-Arjuna/HP TM), etc. Again, unfocusing from JBoss AS for a minute, these are Lego blocks that can be leveraged by *any* middleware environment, any platform: you can be a EE5 developer, a web developer using so-called “thin-frameworks” or integrating two legacy systems, this doesn’t change anything: you’ll always need to rely on security, transactions, remoting, clustering, etc. And you want those services to be the best ones. We have spent a enormous amount of work in the last years to build and strengthen those.
The last layer, the language/programming model/API, is what developers will interact with. Which one is best? EE5? Seam? Spring? Grails? Well, you’ll end up with as many opinions as developers. The rule usually being that the more fashionable these APIs are, the less they will last (i.e. boring == good). Consequently, this third layer needs to be the most flexible and rely as much as possible on the enterprises Lego blocks from the layer below. Languages and APIs are often a matter of taste; relying on secure, scalable, stable, manageable and clustered services is usually NOT a matter of taste. Our architecture has been designed from its foundation to accommodate huge agility in the programming model, at a low R&D marginal cost.
So, where does that put us? JBoss AS 5.0 is the first release which will give us the ability to cleanly separate those three layers. The JBoss Microcontainer abstracts us from the runtime environment and our core enterprise services have been completely componentized and aspectized so they can be fully leveraged from any higher level framework/API/language.
This new architecture means your investment in JBoss is a long term one. Our core architecture is not dependent on any fashionable spec or language du jour: personalities can be plugged in and out, à la carte, you don’t have to make a bet on which API is “the” API you need, and then be locked in one of the few AS implementations that implement such API – possibly relying on weaker core middleware services.
Now, while the decision to move to this next generation architecture was very strategic and will prove to be a key differentiator in the next few years, it is fair to wonder what was the impact of such a decision on the availability of an EE5-certified AS. Did we alienate many customers by being so late with an EE5-certified offering? Truth be said, not really. JBoss AS 4.2/EAP4.x already provides compatibility with the key EE5 specs (including EJB3) and this was more than enough for most of our customers, and by no means a show stopper. We do have a number of customers who are eagerly waiting for a 5.0 release and we are in close touch with them. But what is interesting is that about 80% of those customers are not waiting for an EE5-certified application server, but want to leverage specific features of our AS 5.0 architecture (mostly our JBoss Microcontainer).
Anyway, onto some more specifics now. JBoss AS5.0 RC1 just got frozen and will be released this week. This is a very important release as the release criteria were aggressive . We are now working against RC2 (count 6-7 weeks – summer time) and GA should follow closely thereafter
: we are now above 99.x% EE5 TCK and our AS5 testsuite has less than 1% tests failing.
1’000’000 transactions per second? Safe bet. June 27, 2008Posted by Sacha in JBoss.
Interesting article on Betfair’s JBoss-based solution enabling their web platform to reach 1 million transactions per second.
WebSphere’s history June 24, 2008Posted by Sacha in IT, JBoss.
add a comment
You should really take a look at Darryl Taft’s excellent article on the History of the WebSphere line of business, it is very interesting.
It describes how this adventure started:
Only Sabbah remains at IBM of the three lieutenants. Sabbah, who was Mills’ CTO at the time, is now general manager of IBM’s Rational business unit. Swainson is CEO of CA, and Spector is vice president of research and special initiatives at Google
And how they then initiated the WebSphere (WS) effort with just 25 engineers and how WS moved from an Apache httpd server to a full fledge transactional container, a similar maturation all middleware vendors went through.
It also explains one of the key reason of its sucess: Senior management involvment.
In an e-mail exchange with eWEEK, Trimble added that other factors leading to the success of WebSphere included, “The senior management team was directly involved, in a critical way, by closely managing the interactions between nascent businesses like WebSphere and the rest of the company, ensuring that the WebSphere could leverage IBM’s massive assets without getting destroyed by quarter-to-quarter hit-the-numbers imperatives. And IBM invested steadily in WebSphere over 10 years, even as the rest of the industry went through the dot-com boom and bust.”
It also describes what we have seen for a long time at JBoss: BEA was really the one suffering from JBoss, not IBM. This actually made a lot of sense. Early version of WS were pretty bad – which means that WS users were betting on IBM as large vendor, not on a “best of breed” product vendor. However, that wasn’t the case for BEA customers, which meant that as JBoss was maturing its offering (as of 2004), many BEA customers moved away to the new best of breed product, JBoss.
The article ends with a funny quote from Mills which shows IBM’s love/hate relationship with Open Source:
“Something of this class of software could never be free,” he said. In the mainframe world, IBM has delivered software as source code, but that is not likely to occur with WebSphere, Mills said.
Mr Mills, that’s a great marketing encouragement for your co-workers trying to sell Open Source based products… ;)
No worries, the giant squid is here to help June 23, 2008Posted by Sacha in JBoss.
add a comment
- Quality software
- Quality subscriptions
If we didn’t deliver any quality software, we would not exist – easy. That’s trivial to understand and hopefully applies to all software vendors, not just open source. But that is where the comparison ends:when open source vendors provide great software, they still don’t make any money.
The monetization takes place through our subscriptions offering. And here, the bar is set very high: not only do we have to deliver great value but “every year is an election year”: our customers can decide – on a yearly basis – if they want to renew or not the subscription they have with Red Hat. (Hint: for our business model to be sound, we have to make sure our renewal rate is as high as possible i.e. we have to make sure that we consistently deliver value to our customers.)
What’s great is that these constraints are part of our business model: it is not because we are Nice Guys(TM) (we are), it is really *by design* of our business model. Open Source is one of these rare paradigm shifts which displaced most of the value and decision power in the hands of the end-customers, not in the hands of the vendors.
Obviously, this model is a bit simplistic. In reality, specific contexts apply to each vendor/customer relationship and the end-result is probably a continuum of different relationships, ranging from “provides real value” to “provides real lock-in“, with most open source vendors aggregated at the left of this continuum.
Now, if we were to look at the extreme right of this range, I would not be surprised to see ORCL sailing there. Many companies rely on ORCL DB today to drive their business. This is usually not an easy decision to make given that the ability to migrate from one database to the other is very very limited in practice (database business is known to be very “sticky”). Which means that once a DB vendor “owns” your data, it can pretty much play with you like a cat would play with a mouse. Consequently, it came at no surprise that ORCL just increased their prices by 15-20%. The Giant Squid owns your infrastructure, why not leverage that position in sales? Easy.
Now, if you have too much IT budget and don’t know what to do with it for the next 5 years or so, you should really consider buying some BEA WebLogic licenses. Not only you would have no visibility in what this product will become in the next few years, but you can further lock-in your infrastructure; wouldn’t that be great? Hence, not only would ORCL own your data, but they would also own your business applications. Delicious.
add a comment
Two years ago, Firestar sued Red Hat alleging that Hibernate was infringing one of their patents.
The good news is that in the last days, Red Hat has settled the Firestar lawsuit. What’s even better is that the settlement terms not only cover Red Hat but also cover any upstream developer or downstream distributor and much more. If you want to know more about these terms, a quite extensive FAQ has been posted on the Red Hat web site.
Also, it is worth mentioning that this is the first known settlement patents that satisfies the requirements of both the GPLv2 and GPLv3.
1 comment so far
Sometimes you take things for granted, they are what I would call “technical truisms”. Some examples? Well, you are most probably intuitively expecting that the various Web Services stacks out there will interoperate, that the next.gen CPU to be released will be faster than the previous generation and that using a Mac will make you look way cooler than if you had to carry a disgracious 5kg laptop.
In the same vein, you would probably expect JSF to smoothly integrate with “the” other obvious Java front-end specification, Portlets, right? Well, slow down cow-boy, we actually had to wait for a dedicated spec to solve that limitation (!). That’s what I learned recently while chatting with Thomas Heute (JBoss Portal product lead) about Seam’s level of integration with JBoss Portal.
That “freedom spec” is called “Portlet Bridge Specification for JavaServer Faces” (Early Draft Review 3) and has been implemented by the JBoss Portal as part of the JBoss Portlet Bridge project hosted on JBoss.org. Instead of badly paraphrasing what it does, let me quote the documentation:
The JBoss Portlet Bridge (or JBPB for short) is an implementation of the JSR-301 specification which supports JSF within a portlet and with added enhancements to support other web frameworks (such as Seam and RichFaces). It basically allows any Java developer to get started quickly with their JSF web application running in a portal environment. The developer no longer needs to worry about the underlying portlet development, Portlet concepts, or the API.
Where things really become interesting is when you start leveraging the powerful features of Seam or RichFaces (from inside JBoss Developer Studio‘s IDE for example) to develop a Portlet.
This is very good tech and address a gap that should have not existed in the first place. If you want to follow what’s going on, the JBoss Portlet Bridge Wiki is the best place for this.
Follow-Up: Railo Announcement June 10, 2008Posted by Sacha in JBoss.
It was interesting to analyze the reactions which followed the Railo announcement.
The reactions of the ColdFusion community quickly showed up on blogs and have been very positive overall. I have linked several of these here:
- Ben Forta, a legend in the CF community, gives his opinion on the announcement,
- Adam Lehman, chief evangelist for ColdFusion at Adobe, on the announcement,
- A good summary post by Peter Boughton,
- … and many others, google is your friend :)
On the other hand, it took much more time for this news to show up on the Java community websites/blogs (and it didn’t generate as much noise). Funnily enough, most reactions (should I say “coming-out”?) I received from Java developers on that topic took place in private communications (“You know, I used to be a CFML developer, I really loved it! This is great news!”).
Would we, Java developers, have some kind of superiority complex? I hope not, this complex is exactly what led to the complexification of the Java platform. And now is time to go back to the drawing board.
WELCOME: Railo goes Open Source on JBoss.org June 5, 2008Posted by Sacha in JBoss.
I am very happy to welcome Railo as part of the (growing!) JBoss.org community.
Railo announced today at the “Scotch on the Rocks 2008” conference in Edinburgh its plans to release an open source version of the Railo CFML® engine hosted at JBoss.org (under the LGPL license). The codebase should be fully open sourced by the end of 2008 at the latest and will be available for download from the JBoss.org community website. Just to make it clear, they are not going to open source just a “baby edition”. Instead, they will open source the complete codebase except a few components they are licensing from a thirdparty (such as the PDF generation and their online admin console) and which cannot be open sourced.
For the EE-monomaniacs, let me share more about CFML®. CFML® (ColdFusion Markup Language) is a scripting language based on standard HTML (Hyper Text Markup Language) that is used to write dynamic Web pages. Railo is a CFML® engine that converts CFML® code into executable Java bytecode, which can be run on JBoss (as well as other environments). This provides programmers the well-known productivity of CFML® development with the high performance and scalability of the Java and JBoss runtime environments.
But the teams won’t just stop there. Railo and the JBoss.org community will be working on several enhancements to provide CFML® developers tag-based access to some core services available in JBoss AS today, including JBoss Cache, Hibernate and JBoss Messaging. This is a great opportunity for the massive CFML® developer community to extend their possibilities beyond the traditional CFML® environment: it gives this community access to our complete enterprise feature set (best transaction monitor, security, SSO, etc.) as well as a direct access to our SOA products (JBoss Rules, jBPM, JBoss ESB, etc.) or even our JSLEE/SIP server!
There is like a fresh breeze blowing through the CFML® community today :)
P.S.: Next week, JBoss.org will feature a video interview of Gert Franz (CEO and founder of Railo) and Luc Texier (JBoss EMEA+APAC Support Lead – ex-CFML programmer).
Addenda: I’ve posted a follow-up blog entry on that very topic…
Mobicents 1.2 is around the corner! June 2, 2008Posted by Sacha in JBoss.
The Mobicents team has just released their third beta of Mobicents 1.2. The feature list is very impressive, including:
- Full JSLEE, SIP Services and SIP Servlets implementations
- Management console
- Media server (JSR 309) – audio recording, playback, etc.
- loads of resource adapters (SIP, Media, MGCP, XMPP, SMPP, Asterisk, etc.)
Essentially, you have access to everything that’s needed to implement standard-based, converged, telco applications in Java. What’s more, all of this is based on the JBoss Microkernel and JBoss AS services – which means you benefit from its same rock-solid foundations (transactions, security, clustering, etc.)
Also, while JBoss has always made sure to provide easy-to-use runtime for developers, Mobicents is, much like JBoss AS, a full-fledge production ready implementation. This version of Mobicents JSLEE and SIP Servlets has been tested for sustained 24 hours load at 100 calls per seconds on a pretty basic dual core server with 8GB RAM.
On the business side, Ivelin Ivanov and the Mobicents team are currently working with several customers and partners on some interesting projects. For example, we are working with several American and European ISVs who have built their custom solution on top of JBoss Communication Platform (itself based on Mobicents) and a French SI, Nexcom, recently contributed an initial version of an IP PBX and are working with us several Mobicents-based RFP in France.
If you are interested to join forces with us, let us know, we are already in touch with many companies in that sector and would be glad to extend our community and partner ecosystem.
BTW, Mobicents 1.2 GA will be released in the second half of 2008, so stay tuned!
P.S.: If you want to see a demo of a Facebook Click-2-Call application, you can learn more about it (a the server side code is a few screens of code!) here.