Skip navigation
1 2 Previous Next

Sacha Labourey's Blog

16 posts

 

This year, I have been following the advice from my Zen Teacher on how to properly relax: take three weeks off in a row. I was usually taking 2 weeks but that didn't work for me: I was spending the first 7 days to try stop thinking about work and the last 7 thinking about my restart. 3 weeks worked like a charm! Still, this week, when I checked my e-mail, I felt a bit anxious: "Did a drama take place in my absence?". Nothing! Nada, rien, nichts! It could not have been quieter. Well, let me state that more accurately. It is not that nothing took place;it is just that traditional non-events took place, and that, in some sense, is very reassuring. I guess I wasn't alone in taking some time off. So, let me go through some of the best non-events I found in my inbox.

 

First of all, the winner is certainly BEA with yet another wagon of rumors concerning its possible acquisition. This one has been going on for years, much like a good old Summer Soap Opera. BEA is certainly the most-frequently acquired company. Except it rarely happens. Anyway, something tells me not everybody took some time off this Summer at BEA [1, 2, 3]. Anyway, we will see...

 

Second on my list is Novell with IBM. They made a HUGE announcement: Novell will package (and resell support for) Websphere Children's Edition with SUSE Linux. Damned, that's big news! But wait... wasn't that reactive move already announced 10 months ago... Maybe somebody screwed up in their PR department and re-issued an old announcement.... Well, let's be fair, I know that some evil minds might criticize that alliance a bit too fast by saying this is very much the wedding of two lousy products. That would indeed be an over-simplification. Websphere Children's Edition is, it seems, growing very fast and SLES is number two on the market (even if SLES worldwide sales would equal RHEL sales in Antartica, that would still makes it a #2 -- formally at least). Anyway, if you want to look different, now you have the choice: you can either opt for a nose-piercing or for a SLES/Children's Edition bundle.

 

And last but not least, Oracle. Oracle is still arguing that Unbreakable Linux is not a fork of RHEL. Damned, that is starting to be embarrassing... Someone needs to go there and explain to Larry how it really works, maybe he *really* thinks this is not a fork... Look, he somehow has an excuse: he has been busy fishing in Spanish waters in the last few month, so maybe he didn't give full attention to this issue. Now that he is back, it might be a good time to sit down with him.

 

To be frank, I am slightly exaggerating: some important news indeed took place in the IT space during my holidays, but that didn't impact our business too much...

 

 

 

Onward,

 

 

 

 

 

Sacha

slaboure

Lost on the MetaMatrix?

Posted by slaboure Jul 13, 2007

 

A few weeks ago we finally closed the acquisition of MetaMatrix. MetaMatrix is a pioneer in federated data services and metadata management. I am not sure you all understood what MetaMatrix is about when we initially released the formal press announcement back in April. At least I didn't ;) Consequently, now that we have closed this acquisition, I thought I would take time to describe in more technical term what MetaMatrix is all about.

 

For the busy developers, here is the “(Eiffel Tower) Elevator Pitch”®:

“MetaMatrix provides a way to aggregate disparate (and possibly heterogeneous) data sources (databases, mainframes, XML documents, etc.) and make them look like a single unified virtual database that you can access through standard interfaces like ODBC or JDBC or even as an XML document (XQuery interface) and accessible through Web Services. You can obviously perform a multitude of transformations on these various back-end database schema and even perform joins between multiple heterogeneous sources. MetaMatrix works both with Read and Write/Update/Delete operations.”

 

Now, for the less busy ones, let's go through a typical MetaMatrix use case. Let's say your company uses to store customer information in an Oracle DB. Over time, around 10 applications (Java, C, etc.) have been deployed and directly leverage this data source. At some point, your company merges with a competitor. This competitor stores its customer information in a DB2 DB and has a similar number of applications directly leveraging it.

 

When working out the IT integration plan, the CIO makes the following decisions:

  • Over the next 24 months, existing applications will be migrated to a new unique schema that will contemplate the specificities of both legacy DBs; this means that on an average, about one application will be migrated every month.
  • A set of new applications will be developed ASAP so that the company can start rolling out new services to the combined customers of the merged entities. Given that each system has its own concept of essential business metadata like "customer" and "account", this will have to somehow be unified.

 

The typical problems faced with that kind of realistic) scenario are the following:

  1. You cannot migrate all existing applications in one shot, which means various applications will be using the old and the new schema at the same time;
  2. You don't want to develop brand new applications on top of what's now considered a pair of legacy schema: you want to use the new schema for all new applications, otherwise you are just making your migration issue worse;
  3. You might not be able to replicate data contained in the “old DBs” into a new fresh DB: data inconsistencies or synchronization delays are not compatible with most applications, which means you must keep a single repository of the data.

 

See where I am going? One easy way to solve that solution is to use MetaMatrix. This is the typical steps you would follow:

  • Your architects would define a clean and new DB schema (probably based on the concepts of the two legacy ones);
  • Using the MetaMatrix Eclipse-based tools, architects will graphically implement the new schema i) by capturing the 2 legacy schemas in a graphical representation and then ii) by defining any required transformation to perform the mapping. Architects are also able to set a load of settings such as security scheme, caching, etc
  • Once defined, the new schema and transformation logic is stored in MetaMatrix's meta-data repository;
  • The team developing the new applications (based on JBoss AS and Hibernate, obviously) use the MetaMatrix JDBC driver and the newly defined schema. At runtime, MetaMatrix loads the referenced schema from the repository (it can load and run several schema at the same time obviously) and acts as a SQL database.
  • In parallel, the team dedicated to the migration of existing applications will focus on one application at a time and upgrade each to the new data model according to their migration schedule: each application can be migrated to the new schema independently of the others.

 

Once all applications have been migrated to the new schema (if such a thing is possible in the first place), the company can either decide to keep running things this way or migrate the database itself to the new schema, possibly getting rid of the MetaMatrix mediating layer. However, keeping this mediator can have several advantages, for example:

  • During the 24 months of the migration program, maybe other mergers take place or the new schema itself has to be modified/improved, hence leading to several versions of the unified schema running in parallel;
  • Even if the physical database itself is being migrated to the new schema, it might still make sense to keep MetaMatrix in the middle with a null “identity” mapping. That way you can make schema changes without affecting your applications–. At worse you will need modeling changes (all the benefits of model-driven architecture).
  • Perhaps add the following....Even after the DB is migrated to the new schema, it is likely that requests from other departments will come up, asking to combine both departments' databases for reporting purposes. Rather than providing another copy or an extract of the data, MetaMatrix can provide a view that combines both departments's data for a variety of reporting purposes.

 

What has been described above is a typical scenario where several relational databases are seen as a single one through a relational interface. However, MetaMatrix also provides the following features:

  • On the back-end: ability to aggregate relational and non-relational data sources. Typical examples include mainframes API (through adapters), XML documents and even Excel documents.
  • On the front-end: ability to represent the aggregated information not only as a relational source but also as an XML source and perform queries through the XQuery interface or as a Web Service, for example.

 

Hence MetaMatrix is not just a one-to-many relational aggregation layer, but really a many-to-many aggregation layer, relational or not.

 

As you can guess, MetaMatrix products will be open sourced at JBoss.org. We've already opened up a forum there, so you can start discussing new approaches for using MetaMatrix, including its roadmap and schedule for open sourcing.

 

Onward,

 

 

 

Sacha

The Background

 

This week is an important week for the JBoss division: we've released our first Enterprise Platform. A few months back, I had blogged about how we had decided to split our release work into two “branches”: the JBoss.org releases (i.e. JBoss as you always knew it) and the Enterprise releases (the only ones we will sell support for).

 

As you can imagine (if you cannot, I am telling you), such a new release and productization scheme required quite a few changes in engineering. While we have been able to leverage a lot of what RHT has been building in the last few years to put in place the RHEL/Fedora model, there was no ready-to-consume pattern we could apply to make it happen. For example, JBoss software is by definition OS-agnostic. What seems like a simple requirement à priori has immediate consequences on what tools we were able to reuse as-is (or not) from the RHEL team. We are going to drive a post-mortem of this first Enterprise Platform in the near future so we can improve our processes and tools for the next platforms to be released this year (including the EAP 5.0 and SOA 4.2 platforms – more on this below).

EAP 4.2

 

EAP 4.2 features many new components including JBoss 4.2.0, Tomcat 6, Hibernate 3.2.4SP1, Seam 1.2.0 as well as newcomers such as our new Web Services stack, a preview of EJB3 and the new transaction monitor acquired from Arjuna.

 

When defining what would make it into EAP 4.2 we had two main goals in mind:

  1. We wanted to offer a stabilized EE1.4-based environment for which we could commit to provide support for the next 5 years (with backward compatible fixes), and
  2. we wanted to provide a stepping stone towards EE5/EAP 5.0 (to be released later this year) by making sure we bundle in EAP4.2 as many EE5-based modules that had already been finalized.

 

EAP 4.2 has been tested on many different OSes (HP-UX, RHEL, Solaris, Windows), JVMs (BEA, HP, SUN) and DBs (MS SQL, MySQL, Oracle, Postgres SQL) and will be available in 7 languages. From a dependency standpoint, EAP 4.2 will be used as the foundation for the future SOA platform 4.2 and JBoss Communication Platform.

 

I told you, big engineering changes :)

Next...

 

Now that EAP 4.2 is out, we can fully focus our efforts on EAP 5.0, which will feature JBoss AS 5.0.

 

Practically, most of the work that remains to be done for JBoss AS 5.0 has not much to do with the implementation of the EE5 services themselves (we are in the high ninety percent TCK completion with not too much time spent on it), but mostly around the new JBoss Microcontainer and some long due refactoring we wanted to do (invokers, interceptors, metadata, etc.). With its new core (and its long awaited profile service), a new administration console, JBoss Messaging as its default broker, JBoss AS 5.0 will set a new standard in the JBoss AS releases. So stay tuned!

 

Onward,

 

 

 

 

 

Sacha

 

We have been working on it for quite a bit of time and now it is a reality: JBoss is entering the Telco market with a unique offering.

 

The Telco market is currently going through a major paradigm shift. Let me go through some general background information on that shift.

Telco 1.0

 

The good old telephone network is usually based on a (mostly)voice-dedicated network featured as the “intelligent network”. What it means is that all of the services/features are provided by the network itself while the devices hooking into that network are so-called “dumb devices”. While an “intelligent network” might seem like a great idea at first, it is not really. First of all, it means this network is pretty much only used for voice-traffic: that's not a good way to amortize it. Second, these networks are usually based on proprietary technologies which makes them very costly and almost always a show-stopper when you want to migrate to another vendor. Last but not least, because the “services” are hosted by this “intelligent network”, the deployment of any new service/feature requires an update of significant parts of the network: this is slow and costly and doesn't allow user-specific services. Furthermore, if you want to make that new service (let's say, video) available between two “very remote” users, all operators sitting between these two users must upgrade their network to provide that services, what's more, in a compatible way.

Telco 2.0

 

So, where is the Telco market going? It is moving (this started quite a while ago in fact) towards the “dumb network”. While calling your future strategy a “dumb network” might not seem a very smart career move at first, well, it is. Leveraging a dumb network means that the next-gen Telco will be able to leverage the omnipresent and highly redundant IP network called the Internet (possibly backed by private redundant paths) for all of their “communications” (voice, messenger, video, smoke signals, etc.) and services. That provides two key advantages: first, it is cheap as there is no need to build and maintain a dedicated network and, second, it is very agile (Need to setup a new route? Want to upgrade to a new IP router vendor? Want more bandwidth? Easy.) Then, as you know, IP networks do not own any “intelligence” outside of the base routing features. Which, in turn, means that the features are hosted in the devices. That is what makes this network dumb; it hosts no logic or services. The devices do: they become “intelligent devices” - see the twist?. What that means is that if you want to deploy a new service, it is enough for the two end-users to upgrade their software or hardware equipment and voilà, they're done: there is no need for the core network to be upgraded. Obviously, that's a simplification, but you get the idea: the Next-Gen Telco (Telco 2.0) will run on much cheaper and flexible networks and provide new services that would remain a nice dream with the good old legacy Telco paradigm.

 

As with any paradigm shift, existing players have to migrate to a new territory while protecting (and growing) their existing revenues. While the IP/data market is growing faster than the voice-only market, it remains 8 to 10 times smaller today. One of the consequences of this is that operators will have to innovate and create new services that can compensate for that transitional gap. At the end of the day, the great winners in that game are the customers: basic service will be cheaper and they will be able to benefit from (and pay for) new innovative services.

 

Consequently, Telco 2.0 is as much about a new agile infrastructure as it is a challenge for existing operators, an opportunity for new ones and a new landscape for Telco vendors. OK, I am done with the educational part. Amazon is full of great books on that topic if you are interested to know more about that passionate topic.

JBoss, where do you want to go today?

 

So where does JBoss and Red Hat fit in this picture? We announced this week that JBoss will lead the development and productization of the Mobicents project into a fully supported “JBoss Communications Platform”. Mobicents is the first and only Open Source Platform certified for both SIP and JSLEE compliance, complementing J2EE to enable convergence of voice, video, instant messaging and data in next generation intelligent applications. Ivelin Ivanov, founder and lead of the Mobicents project and a long-timer JBossian will lead our Telco development and strategy. If you are interested to contribute to Mobicents, here is a good way to start.

 

The availability of a strong JBoss-led solution will further enable and accelerate that Telco 2.0 paradigm shift. It also means that Telco vendors and operators can now get a complete Telco 2.0 stack, covering both the OS and the middleware layers, from a single OSS vendor. Telcos using our platform will enable the community of creative open source developers to contribute higher level buildings blocks, thus nurturing the ecosystem of new converged applications. That is unique. Unique.

 

 

 

Onward!

More information is available on Ivelin's blog
slaboure

JavaOne 2007

Posted by slaboure Jun 15, 2007

 

I know, I certainly look a bit "has-been" to only blog about JavaOne now, but guess what, I had the choice between i) being one of the 2'000 guys blogging about JavaOne *during* JavaOne or ii) being the only one blogging about it one month after. I've opted for differentiation on that one.

 

I was positively surprised by JavaOne this year. Attendance was good, show-floor was busy, some very good technical sessions and, more importantly, the spirit was high. What's more, the JBoss booth was very busy, and not only because we gave away very nice T-Shirts (congrats to the JBoss.org team!). Many users showed up at the booth and spoke about their existing and future projects and migrations. While it is always difficult to estimate the proportion of JBoss users vs. customers and what that proportion will be tomorrow, there is clearly much much more to come. We are just at the beginning of this massive OSS-led market disruption. Much like for global warming, the sea level of software market consolidation is slowly but surely rising.

 

There was also loads of interest in EJB3/EE5 and how to migrate legacy applications (either based on EE1.4 or Spring) to EE5. Many companies that thought EE1.4 was too complex opted for some non-standard "helper" tools/frameworks/wrappers to achieve their IT goal more efficiently. However, I haven't met a single user or customer who wanted to keep this situation in the mid- or long-run. That's good. It means the market is increasingly and inevitably attracted by Open Standards. Today, companies are more conscious than ever of the cost of locking themselves into a non-standardized API/product, i.e., disastrous. We call that "the cost of exit". When companies perform TCO studies, they take into account a large number of parameters, including migration cost, team education, new licenses, support, etc. but they very rarely take this "cost of exit" into account. Big mistake. In many cases, this cost might be prohibitive and put a halt to new projects or to integrations with new systems, which means you'll have to live with your locked-in solution until you decide to drop it altogether, which might not be possible before a very looooong time.

 

On the JBoss project front, Seam and Web Beans (JSR-299) generated a lot of interest, sessions were very busy and people loved its simplicity (integration with Google Guice was also very positively perceived - bye bye XML configuration hell). In fact, the Seam book ended-up being a JavaOne best seller AND the “best stolen” book at JavaOne. BTW, Seam integration with Web Services and JBoss ESB are on their way, so stay tuned.

 

Also a special mention to "Hibernate Search". The problem with this project is its name - it is too "shy". When you hear about "Hibernate Search" for the first time you probably think "well, yeah, it is just a way to populate an index file based on you Hibernate CRUD actions...no big deal.” What a mistake! When you actually look at what it does, how flexible it is, how simple it is to configure it and how smoothly it integrates with the EJB3/Seam programming model, you'll quickly realize how powerful it really is. After all, "Hibernate Search" is in fact a pretty good name, it is just just too "simple" (I am convinced "Hibernate FreeParisHilton" would have generated more interest). Go Emmanuel, go!

 

Last but not least, the Open Sourcing of Java is some kind of recurring party. We partied when SUN announced they'd do it, we partied when they actually OSSed the JVM, then they OSSed the JDK minus some classes, etc. SUNW's PR team must have never been so busy than in the last 12 months. Anyway, the reason I am so excited about all of this is that what SUNW has built is a *very impressive* multi-billion dollar ecosystem that has gathered almost all top software vendors and this, for more than 10 years! But all ecosystems have cycles and >10 years is a long time. Something big had to take place to rejuvenate it and this is exactly what just happened. Now that a quality JVM+JDK is available in OSS, I predict you'll start seeing a new batch of innovations in the Java space. In fact, it already started, talk to Bela Ban if you want to share some ideas on the standardization of byte-code enhancement at the JVM-level. We just started a new 10-year cycle, so tighten your seat belt.

 

Onward,

 

 

 

Sacha

 

This week is a very important week for JBoss, not only because we are announcing the strategic acquisition of MetaMatrix, but also because we are evolving our development, distribution and support model. Let me dig into what it means.

 

 

 

Historically, JBoss has developed and supported projects on a “single branch model”. That is, we supported every release for all of the JEMS projects. That created a natural tension between the community on one side and the business on the other side, as they both have different goals. As we see it, the role of the community is to innovate, develop new features and release early, release often. The role of the business is to support existing installations with minimal disruption, providing backward compatible fixes and this over a long period of time.

 

 

 

For example, if a project lead produced two minor releases in a week, for whatever reasons, it meant that our support team would have to support both of these releases for several years. Imagine how complex this gets when you mix all of possible project releases with all possible permutations of JEMS software (e.g., JBoss AS with JBoss Cache with jBPM with Drools with Hibernate), you end up with a combinatorial explosion that is very difficult to manage, even more as you expand your customer base -- and that is exactly what's happening thanks to the JBoss/Red Hat merger.

 

 

 

Instead of coping with that growing tension, we decided to drop it by eliminating this conflict of interest altogether. We will now work on two “branches”: i) the “JBoss.org” community branch and ii) the “Enterprise” branch. Let me explain how they relate.

 

 

 

The JBoss.org software is JBoss as you've always known it: everything you know and are used to getting from JBoss is what we will refer to as “JBoss.org” or “community” releases. Nothing will change on that front except, as we further grow our product/platform teams (we are hiring BTW!), project developers will have more time to focus on innovation and pure development work as they will have less productization constraints.

 

 

 

What's really new is that we will work on “Enterprise” releases. Here is how it works. At very specific points in time (usually when a JBoss.org project reaches feature completeness and proved high stability – but at least every 12 to 18 months), a “product team” will branch that code base (it will be hosted in the same CVS/SVN public tree). This separate product team, with the help of the project team, will perform three type of actions on that branch:

  1.  

    Sanitization: This first action is to remove from the original code base the features that we do not think our customers should be using in production. As you know, most projects have optional or experimental features as part of their code base. We want to make sure that those are not present or at least not enabled in the Enterprise branch to satisfy our support organization's motto that “if we ship it, we support it”. Tomcat native clustering is a perfect example of this. For various technical reasons, we typically advise our customers to use JBoss Clustering over Tomcat clustering. Through sanitization, we can avoid this confusion and simply make sure that our “Enterprise-blessed” version of Tomcat includes the “recommended” version of clustering, i.e. JBoss's.

  2.  

    Productization: In this step, we will fine-tune and improve the usability of our software so that it matches the expectations of our customers. All of the improvements we will perform will be applied “upstream-first,” i.e., we will first apply the changes in the Community code base so that the next release of our software (both Community and Enterprise) can benefit from the enhancements.

  3.  

    Aggregation/Packaging (optional): Today, we are also improving the way we package our software so that our offering focuses more on “customer use cases” rather than on “specific technical features” by aggregating several projects in what we call “enterprise platforms.” You can read more about these platforms and roadmap in Shaun's blog. Essentially, our productization teams will pull together the most commonly used JEMS components in their best versions, integrate them and perform cross-testing for these components. Each platform will be available as a single download, with all components guaranteed to work together seamlessly out of the box.

 

 

 

From a distribution standpoint, source code and binary for Community releases will continue to be made available like they are today with no changes. For the Enterprise releases, the source code will obviously be freely accessible (we are using the exact same CVS/SVN servers/trees for platform development) but the binaries will only be accessible if you build it yourself or subscribe to our developer subscription, production subscription, or Red Hat Developer Studio (future name of the Exadel Studio Pro IDE).

 

 

 

Let's be clear that the “Enterprise” software will NOT be a “blended” community version with non-open source features; it is exactly the opposite in fact. The Enterprise version is a subset of the Community version that is enterprise-ready and we can guarantee support for up to 5 years. While this new development, distribution and support model looks and smells a lot like the good old RHEL/Fedora model applied to Red Hat's Linux distribution, it is not exactly the same. While the rules are the same with regard to the binaries, the JBoss source code will remain public and accessible during the complete Enterprise lifecycle activity, not just for specific release snapshots.

 

 

 

From a support standpoint, we will only support the Enterprise versions of our software. This enables us to support you even better and for a much longer period (up to 5 years) with quarterly cumulative patches (bugs only) and bi-annual updates. We are also offering development subscriptions where some community versions of our software will be supported, but not with the same SLA (see Shaun's blog on that topic). BTW, existing users of JBoss 3.x or 4.0.x will still be able to get support for these versions. The new rules only apply to new releases of our Enterprise Platforms and Frameworks, so none of the previous releases are affected by this change.

 

 

 

The bottom line is that since we will be focusing on stabilizing features on Enterprise Platforms, it means in turn that the JBoss.org community will have even more freedom and flexibility and will be able to focus on what it does best: innovate. JBoss.org is where we will continue to innovate JBoss Enterprise Middleware. But now, projects are no longer tied to productization cycles. That means you can expect more bleeding edge technologies, more often. Once these technologies are enterprise-ready, we'll integrate them into JBoss Enterprise Platforms. As a sign of that change, you should visit the newly redesigned and enhanced JBoss.org Community web site.

 

 

 

Onward,

 

 

 

Sacha

 

 

 

Since RHT's acquisition of JBoss last June, ORCL keeps reacting.

 

 

 

As soon as the JBoss acquisition was announced, last April, Larry vented his frustration and unhappiness in the press and made public all of the bad he thinks of open source business models. Then, 6 months after, he announced ORCL was now a Linux vendor: when Larry has twice the same opinion, the only thing you know is that he changed his mind an even number of times.

 

 

 

Truth is that Larry knows very well that Open Source is real and is here to stay. Open Source is one of these radical paradigm shifts that take place on the market and put in danger existing business models that are forced to adapt to these new rules. What are the options? Essentially, there are three.

 

 

 

The first option is to try hard to ignore the shift. That is what most software vendors have been doing until recently, but Larry is too wise and paranoiac to hide behind his finger.

 

 

 

The second option was for ORCL to take the lead of that shift and become the new Microsoft of Open Source. The problem is that the 14B USD gorilla hasn't been agile enough to align his ducks and is now left with a situation that shows how he has been unable to properly execute on an Open Source strategy.

 

 

 

Then remains the third option: If ORCL is not going to lead that shift, they'd better try to slow it down. In case you were still wondering, make no mistake, ORCL is not serious about building a Linux business, they are just trying to impact RHT's growth and margin, hence its ability to further invest and grow the stack in Open Source. This is not about giving value back to the customers, this is about keeping value in-house a bit longer. And in order to prove they are getting some traction, ORCL is willing to slightly stretch the reality.

 

 

 

I bet ORCL is going to announce other b-plans in the near future. As an example, the recent acquisition of Tangosol by ORCL was one of those IMO. ORCL knew they had to find a replacement for JGroups in their Oracle Application Server: in the last months, it must have been quite an embarrassment for ORCL to rely on JBoss to power their Oracle AS clustering and high-availability features.

 

 

 

So Larry, what is going to be your next b-plan?

 

 

Update (20070402): Andy Oliver mentioned that it might be useful to refer to a previous related post. On that scale, ORCL would sit between the fourth and fifth categories (i.e. between "anti-strategist" and "head-less chickens")
The partnership with Exadel that we have announced today is very important not only because for the first time, developers will have access to a very rich Eclipse-based toolset that is entirely available in open source, but also because it is part of a "Grand Unification" goal we have for 2007.

 

 

The Partnership

Exadel will open source its commercial products - "Exadel Studio Pro" and RichFaces - at JBoss.org as "Red Hat Developer Studio" and "JBoss RichFaces", respectively. Exadel is also moving its popular Ajax4jsf project, currently hosted on java.net, to JBoss.org, where it will become "JBoss Ajax4jsf".

 

 

While JBoss RichFaces and JBoss Ajax4jsf have already been opensourced at and can be downloaded from JBoss.org, Red Hat Developer Studio will only be available in open source by summer 2007: given the important size of its codebase, we will need more time to finalize that work. In the meantime, you can download "Exadel Studio Pro" for free. Once fully opensourced, binaries for all of the individual plugins will be made available for free while the "Red Hat Developer Studio" will only be made available as part of a Developer Subscription.

 

 

From a licensing standpoint, JBoss Ajax4jsf and JBoss RichFaces have been opensourced under the LGPL while Red Hat Developer Studio will be opensourced under a GPL-based license (except for JBoss IDE plugins which will keep their current license).

 

 

Red Hat and Exadel will jointly develop the three projects going forward, including integration with existing JBoss platform technologies such as JBoss Seam. That work will be done under JBoss's leadership. It is worth mentioning that given the size and the expertise of the Exadel team, the JBoss community can expect an acceleration in the number of IDE features that will be made available for JEMS projects, so that's very good news.

The Grand Unification

This partnership with Exadel enables one of the three axes of the "Grand Unification" strategy we will focus on in 2007. Here are these three axes:
  • Management: the need to manage JEMS components from a unified management environment is not new as this work started 2 years ago with the development of JBoss ON. This work is led by Greg Hinkle and Richard Friedman. Rich is now responsible for the future combined JBoss ON/Red Hat Network roadmaps.
  • Programming Model: providing a unified programming model accros JEMS and beyond is the role of Seam, effort started and led by Gavin King. This layer provides seamless integration of EE/JEMS environments. Some of this work is being standardized under the Web Beans JSR. I am very excited by the possibilities offered by Seam and we are putting lots of attention (and resources!) into it.
  • Tooling: providing an extensive and integrated tooling suite accros JEMS is the last axis of the grand unification strategy. This axis just got kick-started by our partnership with Exadel.

Gavin's Leadership

The very good news here is that Gavin King is taking a leadership role in that "Grand Unification" and will lead the vision of two of these three axes: tooling and programming model. Given Gavin's credibility in giving back productivity to the developers, you should expect great innovations. I am personally thrilled to see Gavin take on that strategic role, Congratulations Gavin!

 

 

Last but not least, I'd like to thank Ram Venkataraman and Bryan Che for having initiated and led that partnership, congratulations guys.
slaboure

Salut, l'Ami!

Posted by slaboure Feb 10, 2007
That's now official: Marc has left Red Hat.

 

 

That's strange, I have mixed feeling.

 

 

First of all, I am sad. Marc wasn't only the founder or JBoss, he is first of all a friend, someone with whom I've spent a lot of time and went through many things: both great and painful times. I first met with him in 2001 and what follows is a great story. He gave me trust, respect and a unique opportunity. So, obviously, I cannot be fine to see him leave the company. In that sense it is a sad day.

 

 

But then, when I read what's above, I sound like if Marc was dead! Damned, Marc is kicking and alive! I spoke with him yesterday and I can tell you he is full of energy, he is going to give his first math lesson today (trigonometry!), he has fun and he is happy! After 7 years of daily fights and stress, he can now enjoy some well deserved quality time. That cannot make me sad :)

 

 

As for JBoss, that's a different story. JBoss is no more a "one man, one woman and a dog"-company and wasn't anymore for quite some time. We are a great team with great talents who are driving innovation at an impressive pace. We are at a unique time in the history of JBoss: the perfect storm conditions for FOSS are lining up! Beware, we're coming!

 

 

Love and Respect, marcf.

 

 

Onward!

 

 

slaboure

BMW to drive JBoss.org

Posted by slaboure Feb 7, 2007
At the very beginning, things were easy: we just had a single web site, jboss.org, which was both our community and business facade. It was easy in the sense that we didn't have to discuss much about "what content would go to which Web site": everything would end up landing on JBoss.org. This had the the side effects of frustrating developers with flashy training banners left and right and upsetting architects unable to sell the greenish JBoss.org web site to their CIO.

 

 

 

Some time after, we have been "offered" to buy the JBoss.com domain to some "parking service" company. It took us some time to accept the offer. Essentially, we did it only once we could really afford it (it was a high-quality "parking service", that's expensive). That's when we started spending a good amount of time thinking how to split content. But this really was a new birth for JBoss.org: it meant we were able to fully leverage this domain for community content. It is also when we started to move away form Sourceforge.net to get better CVS performance/reliability and build our own "JBoss Forge" to unify projects looks, navigation, tools (fisheye, SVN, etc.) This work was started by Damon Sicore who recently left us for an (almost) unknown startup.

 

 

 

Enough history, here is the good news : Bob McWhirter joined Red Hat and is the new JBoss.org lead. As you might know, Bob was the founder of Codehaus, a "high-energy" community/forge that focused on high-quality projects rather than on a high-number of projects (Codehaus is to project forges, what Blancpain is to watches). I've first met with Bob about one year ago when Drools joined JBoss: you might not be aware of it, but Bob was also the founder of Drools (aka JBoss Drools) - now led by Mark Proctor.

 

Bob and his team will work on several aspects of JBoss.org:

  • JBoss.org Forge: Bob and his team will further build JBoss.org infrastructure so that our community can enjoy increased productivity. That not only means better tools but also more and better automation (downloads, QA, automated build, statistics, etc.).
  • JBoss.org Content: technical writers will produce useful material for the JBoss community and peer with project leads to make project pages useful and attractive. Mark Newton, based out of London, and previously a top-gun JBoss consultant, will bootstrap that team.
  • JBoss.org UI: work on JBoss.org UI, navigability, ease-of-use, etc. This area is led by James Cobb, based out of Atlanta; we've started to offer this expertise to individual projects (JBoss Portal for example).

 

 

 

Bob will also be the public face of JBoss.org and will advertise and promote our projects, make sure people understand how we work as a community and make sure new contributors feel welcome in our ranks. Remember that we only hire developers from the community (mostly JBoss's community), so if you are interested to work for JBoss (or want to see how it could be), feel free to join our FOSS development teams (you can join even if you are NOT looking for a new job ;) ).

 

Welcome Bob :)

slaboure

FOSS Java, Finally!

Posted by slaboure Nov 13, 2006

 

It took 11 years, but we finally got there: SUN Java’s implementation will be open sourced!

 

Bottom line: that is excellent news for the Java ecosystem and for the Free Software.movement

 

First of all, it means that Java can now be made available on more platforms while making sure we get consistent behavior. Also, it means that OS and hardware vendors will be able to customize and fine-tune Java for their environments. This openness will further increase Java platforms competitiveness and increase Java’s pervasiveness. All of that is a net positive for the Java ecosystem at large.

 

Last but not least, I bet this will also lead to some very interesting innovations either in the JDK, JVMor the compiler that could, in turn, be standardized through the JCP. JVM-level AOP integration, scripting languages and optimizations are great examples of what could be achieved. This will lead to a fast turnaround of innovations in Java (much like what happened with Hibernate/EJB3 or SEAM/Web Beans).

 

As suggested for a long time by JCP members, SUN will use the strong value of “Java” trademark/brand to protect the ecosystem from incompatible implementations (only those that have fully passed the TCK will be allowed to use the “Java” branding/trademark - the FOSS project is named “Open JDK”). That is a simple, clean and efficient solution. This also means it wouldn’t be possible to release a broken “Unbreakable Java” JVM, not that anybody would want to do something that smart though… ;)

What and How?

 

In order not to disrupt the release cycle of Java 6, SUN will start by releasing Java 7 code (mostly a fork of 6 at this point and some minor changes), and will later open source Java 6 code.

 

From a licensing standpoint, here is a summary of what was announced:

  • Java SE will be dual licensed: GPLv2+E (i.e. “GPLv2 + exceptions”) and commercial license.
  • Java ME will be dual licensed: GPLv2 (no exceptions) and commercial license.
  • Java EE will be trial-licensed: GPLv2+E, CDDL (already the case) and commercial license.

 

The GPLv2+E is a modified GPL version that drops the GPL “virality” clause for any code using that library (which is very similar to what the LGPL does). Bottom line: code/applications running on top of the GPLv2+E JVM will not need to be (re-)licensed under the GPL, they can use any license they like, open source or proprietary.

 

Consequently, the real announcement here is pretty much for Java SE “only”:

  • Java EE had already been open sourced under the CDDL (SUN is just adding another license to the mix), and
  • Given that Java ME will not benefit from the GPL+Exception treatment (it will be released under a straight GPLv2), phone vendors will still have to license a commercial implementation of Java (or otherwise would have to GPL all of their software running on this JVM)

 

Given that SUN is making most of its JVM revenues in ME-land, licensing the JVM under the GPL certainly fits with SUN’s commercial reality. In case phone vendors are not satisfied by the license, they could either decide to open source their phone software under the GPL (low probability) or fork SUN’s SE implementation and adapt it for ME environments (which could be accelerated by some donation given that vendors have already implemented SE JVMs). Both solutions will take some time to implement though, enough time to let SUN grow other JVM-related revenue streams. However, I do hope that SUN finds a solution to this in the mid-term so that the ME ecosystem can also fully benefit from this announcement.

 

So, shouldn’t have SUN opted for an Apache/BSD-like license? No, I really do think they made a good choice here. SUN is going to release a tremendous amount of IP under an Open Source license. I do think it is fair to ask that any changes and extensions to this IP be released in the Open Source as well. As for users of that technology, this will have no impact on them: they can freely choose the license for their software, and that is really all they care about. Only would-be proprietary forkers will not be happy with that choice and that’s fine.

When?

 

We will have to wait until mid-2007 to get a full-fledge JVM available in FOSS. The Hotspot JVM and the compiler will be open sourced in 2006 but we will have to wait Q2 2007 for a fully buildable JDK. That will leave companies time to work on the JVM customization/optimization.

Conclusion

 

The Java saga that SUN has led is a unique success story. 11 years ago, SUN (a hardware company!) successfully put in place the conditions that led to this multi-billion multi-vendor open ecosystem. More than a decade after, Java is not only alive but is leading the middleware space. Such an open and successful ecosystem is unique in IT. Sun’s constant inability to monetize that ecosystem might be one of the reasons why it has been successful: you don’t want the referee to mark goals and, even less, to win the match.

 

As this ecosystem matured, a move was required to rejuvenate it. That’s what SUN just did with this announcement.

 

Congratulations to those of you at SUN who have been listening to the market and pushing for that courageous move. I know this wasn’t an easy one. A few months back, you made the commitment to Open Source all of your software. We were all hoping you would start with Java, but that is not quite how it happened and that is where you finally ended. But here we go and that is probably one of the smartest moves you could do to further extend the ecosystem.

 

Tighten your seat belts, the Java ecosystem is about to move full throttle ahead!

slaboure

Afterthoughts...

Posted by slaboure Apr 30, 2006

 

In the last few days, I crawled through the huge amount of articles, posts and internal e-mails that followed the RHAT/JBoss signing. Damned! This is pretty impressive, the feedback is extremely positive and for most this move is simply so natural, so obvious. In retrospect it is to me too.

Inside…

 

Inside the company, I have been highly impressed by the reaction of my JBossian R&D colleagues: at first, obviously, they have been surprised by the news (they had been used to rumors and there were none here), wondered what it meant for them, for their projects, etc.  It seems for many of them this is a natural move as well. I was expecting lots of distraction, many questions, etc. but in fact things calmed down very fast: people got it and went back to work, some relieved and most even more motivated than ever to build the next generation middleware! Onward! Congratulations guys, you’ve impressed me, really.

…outside

 

From a PR standpoint, as a said before, the feedback was overwhelming and extremely positive. Obviously, some articles have raised some issues or challenges they could foresee, fair enough. Let me dig into some of those…  

Theoretical challenges

 

I’ve classified most of the issues in the “theoretical challenges” category. They typically address high-level strategic integration issues, market-forces, synergies, e.g “does this change the software landscape as we know it” as some articles claimed. I am certainly not classifying them as “theoretical” in order to make them look futile. All of these points are very interesting and most of them are valid questions. No, I do classify them as “theoretical challenges“ because I think there is no need to spend time factually arguing for or against them: nobody is right or wrong at this stage, only our combined ability to execute will tell, down the road, if we have been successful or not. Facts will speak for themselves, no need to spend endless cycles arguing whether the sky will be clear in 2 days, 2 weeks, 2 months or 2 years. Let us prove ourselves: we are extremely motivated to build a billion dollar company, something great. Wait and see, we are working on it. Still, I know we will succeed ;)

Interoperability/Partnerships

 

A second category that interested me concerned our continuing work with existing JBoss partners. While I understand that this concern was raised by some of our partners, let me reassure many of you.  Things are pretty clear cut on our side: maintaining a multi-vendor JEMS stack is key to our strategy. WE will support all our partners that adopt JEMS as they infrastructure. It wouldn’t make sense for JEMS to strictly target the RHAT Linux platform as much as it would not make sense for RHAT to strictly target JEMS as its middleware. JBoss runs on Windows and Websphere runs on Linux RHEL.  In the “real world” enterprise IT Operating systems and middleware, are heterogeneous environments. Customers demand freedom of choice, that is not something we can be for or against. It just is, by popular demand.  

FUD

 

A third category, the FUD one, was to be expected. I’ve surprised by the lack of creativity though:

  • JBoss is being licensed under the GPL, hence, obviously!, not suitable to your environment, you should really use <whatever shameless product plug here> instead
    • JBoss AS is LGPL licensed and is totally fine for your deployments, either as an end-customer, an OEM or an ISV.
  • JBoss is “weak” in Europe
    • False: most of our leads come from Europe. JBoss adoption in EU is as widespread as in the US, this is a global phenomena.
    • While it is true that in terms of company development, JBoss Europe is about one-year behind JBoss US, today, most of our R&D work is done in Europe.
    • We have developers present in 10 European countries: Belgium, Croatia, Czeck Republic, France, Germany, Greece, Norway, Poland, Switzerland, UK;
    • We have physical offices in 4 European countries: Switzerland, UK, Germany and Belgium; Furthermore, once we hook up with Redhat, we will instantly scale our coverage of Europe.
    • I don’t necessarily like comparing Europe vs. the USA vs. Mars. In that regard, having a tri-national French/Spanish/American CEO is pretty useful.
  • JBoss will no more be available as open source software, you should expect a free version for the children and a for-pay version for the adults
    • That is the funniest FUD we have heard from our competitors.  Think about it a minute, consider the rumors and consider where we have chosen to end up.  RHAT is a pure play open source, that is why we went there. If we really wanted to go proprietary don’t you think we would have gone somewhere else? No really! We certainly do not expect to change the current model: why changing something that works great and the customers love?
    • Open Source business uses various models (support/maintenance, dual licensing, packaging, certification, proprietary plugins, etc.), so do we.
    • People have spread FUD for all our history on us going proprietary and we will continue to prove this simply wrong. That is not what we want and that is not what our users want.
  • JBoss will only be available on RHAT Linux
    • See above, also the LGPL license prevents anyone from restricting our distribution. Finally remember that JBoss is written in Java and that Java runs anywhere.

What’s next?

 

Good question! A small combined team is currently working on the RHAT/JBoss integration plans that we will roll-out once the deal closes: We will be ready to disclose more information at JBoss World Las Vegas (don’t forget to register in time, that’s pretty soon!). But more importantly, the team is working hard to work on future releases of our JEMS. The technology innovation rate is going to increase: JBoss Web (Native IO and .Net/Java/PHP integration), JBoss AS 5.0 (EE5/EJB3 – next generation enterprise development), JBoss ESB 1.0, SEAM (smooth EJB3/JSF/BPM integration), JBoss MicroContainer (JEMS’s new Middleware Operating System), JBoss Messaging 1.x (next generation messaging infrastructure) and much more! so stay tuned and enjoy!

 

 

 

Onward!

 

 

 

                                      Sacha

 

I've decided to regularly provide "quick info" on the various JBoss projects (new features, numbers, etc.). As this information is usually scattered across various projects, URL or blogs, I hope this unified entry will make it easier for you to find what you were not looking for.

New product releases...

 

JBoss Messaging. On the new product releases first, Ovidiu and Tim have been working at 50% in the last few months, i.e. ~12 hours a day, in order to release JBoss Messaging 1.0. I am very proud of the team and of the result of their work. This implementation is fully JMS 1.1 compatible and already shows great performance improvements. Clustering features are next on the roadmap.

From a deployment standpoint, JBoss Messaging
  • can be deployed in JBoss 4.x in order to replace JBossMQ (it is backward compatible with JBossMQ configuration files),
  • will become the default JMS implementation as of JBoss 5.x, and
  • is a key component of JBoss ESB (first release due later this year).
Speaking about JBoss ESB and new product releases, the last days have seen a flurry of new releases with JBoss jBPM 3.1, JBoss Rules/Drools 3.0 and JBoss Transaction 4.2 (acquired from Arjuna Technologies and HP in December 2005). I will speak more about those in another telegram...

New tools...

 

Some interesting tools have also been implemented recently. First, Adrian has been working on JBossRetro, a retro-weaver that we use to retrofit JDK5 classes in order to execute them under JDK1.4 environments. While it is not the only tool that provides such features, Adrian has been investing significant resources in testing it to make sure it is rock-solid (like anything Adrian does). As an example, JBoss 4.0.4CR2, which was just released a few days ago, incorporates the new JBoss WS implementation which will also be our EE5 implementation. Given that JBoss 4.x is our EE 1.4 branch, it had to work with JDK1.4 and hence had to be retroweaved for that release. That's what JBossRetro did.

 

Also, some interesting developments from Clebert Suconic: JBoss Serialization and JBoss Profiler.

 

JBoss Serialization, which aims at improving the performance of the Java default serialization implementation, is currently being rolled out in many JEMS projects (starting with the AS). If you need to perform deep object copy or object serialization in your project, you should consider this tool as it can provide up to a 10 times performance increase over the default "byte array" Java serialization.

 

JBoss Profiler is a log based profiler that can remotely analyse JVM events and provides access to key information through a Web browser. While JBoss Profiler doesn't exhibit the sexiest interface out there, it does provide some unique features. For example, Clebert has been recently implementing a new feature that will help you find memory leaks much more easily and much faster (across re-deployments of applications in JBoss AS for example).

Zoom on...

 

Last but not least, I recommend to regularly check the status of a fast growing project: JBoss Mail Server. Andy Oliver's baby is gaining great traction. As an example of its adoption, one of the European largest phone operators is using it for all of its European mobile-to-e-mail traffic. Tempted? Click here and you will have it configured and running in less than 10 minutes :) (thanks to Java Web Start)

 

I will be back soon with a new JBoss telegram...

 

Cheers,

 

Sacha

 

JBoss has not sued anybody for trademark infringement, and maintains partnerships with several German service providers. A single service provider in Germany acted in a manner that violated certain of our rights and mis-used our Partner Programs. In order to protect our rights and the agreements with our service provider partners, we asked this company to stop such violations. Although they did not reply at that time, we were glad to see that they did stop infringing on our rights.

 

It should come as no surprise that JBoss, Inc., like most companies, will stand up to defend its rights and the interests of its partners. This of course does not impact our commitment to Open Source. We are 100% committed to Open Source and to our community. JBoss grew out of the Open Source community. We remain committed to our roots as we move forward in extending the reach of Open Source development and making Open Source the safe choice for the enterprise.

 

Sacha Labourey
General Manager JBoss EMEA

slaboure

Open Source Positioning

Posted by slaboure Jul 18, 2005

 

As I was thinking about the way companies (mostly software vendors) position towards Open Source, I realized I could try to categorize them.

 

Here is what I came up with:

  1. The truly committed
  2. The mixed-codebase
  3. The pragmatics
  4. The anti-strategist
  5. The headless chickens
  6. The in-denial
  7. The anti-OSS

 

The first category, the "truly committed", bundle companies that make of Open Source their principal strategy. This category has gained increased attention from CxO and has already won support from a massive number of developers. The clear advantage of such a positioning is that it is very easy read. Examples of such companies include Red Hat, MySQL and obviously JBoss, but also a growing number of smaller companies trying to find their way through similar business models. We could certainly split that specific category in sub-categories, depending on the way software and services are being developed, distributed and monetized, but that is a different topic.

 

The second category, the "mixed-codebase", gathers companies with an increasing commitment to an Open Source strategy but that also have some existing critical revenue streams to protect, and hence cannot simply switch to a full OSS strategy overnight. "Mixed-codebase" companies not only deploy on/use Open Source software (as an ISV), but also actively contribute to (or even lead) OSS projects and have some clear OSS alliances reinforcing this strategy. Examples of such companies include Novell and Computer Associates. I mostly see the "mixed-codebase" category has a transition step: companies will eventually move to category 1 (successful transition) or 3 (retrenchment), depending on how well they execute their transition, how well they can convert their existing revenue streams, how frequently they change their CEO, etc. I do not know of any company that would have successfully switched from a traditional company to a category 1 company yet. My bet is that such a thing will take place in the next 2 years.

 

The third category, the "Pragmatics", communicate a lot about their love of Open Source even though they usually only contribute marginally to OSS projects (if at all). These companies mostly develop proprietary software (ISV) and deploy it on (and make use of) Open Source software as a way to maximize their target market. This is a very comfortable situation to be in as it is a cheap way to advertise you have an OSS strategy, surf on the OSS wave and not take too much risk. This strategy is specifically interesting if you don't really feel threatened by an Open Source competitor on your own market segment. A well-known example is Oracle and their commitment to Linux as a deployment platform.

 

The fourth category, the "anti-strategist", are frequently confused with the second category (the "mixed-codebase" companies) as they share lots of common attributes (contribution to OSS projects, etc.) but are fundamentally different. While the "mixed-codebase" see OSS as something that will actively drive the strategy of the company (go-to-market, product development, monetization, etc.), the "anti-strategists" mostly use OSS as a way to fight competition ("anti-pattern"). "Anti-strategists" consider OSS as one of the tools at their disposal to fight the market, but not as an inherent attribute/value of the company. "Anti-strategists" are usually smart enough to benefit from the side effects of their actions and properly monetize it, but this is not what originally led them. Anti-strategies are dangerous as they can backfire. IBM (and its Linux vs. Microsoft story) is a famous member of that category.

 

The fifth category, the "head-less chickens" (*1), are usually ex-"in-denial" companies (see category 6 below) under pressure of Open Source and paying the price of their denial. A specific attribute of such companies is that they can come come-up in a very short timeframe with any of the 4 first positioning described above, in random order, as a way to satisfy their Board/investors/customers. Typical scenarios include Open Sourcing uninteresting part of their codebase that nobody will want to pay money for anyway, providing their software as an Open Source version  for the children and a for-pay version for the adults (no credibility), joining/creating random OSS projects just to fill in the strategy gap, etc. Their real underlying strategy is to undermine as less revenues as possible while waiving hands as much as possible. Unlike chickens, companies can recover if well managed (sewing a different head can be a good start of the recovery process).

 

The sixth category, the "in-denial", prefer not to see Open Source and will make sure to mention its existence as less as possible. When you speak about OSS to such a company representative, (s)he will usually stare at a virtual spot on the ceiling and start whistling a well-known song. Like for the second category ("mixed-codebase"), I also see this category as a transition stage. Abuse of that stage usually leads to stage five ("head-less chicken").

 

The seventh and last category, the "anti-OSS", like the first category ("the truly committed"), benefits from an extremely clear positioning: they hate Open Source. Given the popularity of Open Source on the market, very few companies risk that positioning as it might backfire. Microsoft is a well known member of that category. I have to admit I admire their commitment to this unpopular strategy. To succeed in it, it is essential to keep a clear and active communication on the evil Open Source. In that regard, I have been disappointed recently when Microsoft mentioned they "provide lots of Open Source code" referring to MSDN code snippets (Ashim Pal, Gartner Panel, Barcelona, 2005) as well as when they backed WiX. By not being clear-cut and vocal, "anti-OSS" companies take the risk to become passive "in-denial" companies with the song of the hatchet not far around.

 

I think only strategies 1, 2, 3 and 7 can be stable positions (with strategy 2 offering a good runway), while the others are unstable.

 

What is the strategy of your main software vendors?

 

 

 

1) Have you ever seen what happens when you cut the head of a chicken? The headless body start running left and right until it collapses.

Filter Blog

By date: