In this interview, JBoss CEO Marc Fleury takes a look at how the open source software business model has evolved and what to expect in terms of service-oriented architecture development in 2006. He explains why he doesn't like the Service Component Architecture specification, why the Java Community Process is necessary, outlines JBoss' roadmap and describes how paranoia keeps him going.

From the interview:

What's the biggest challenge facing the open source model in 2006?
Fleury: I don't mean to sound non-paranoid -- I am actually very paranoid -- even with my paranoia 2006 is very bright. All of the businesses I know in open source, we're leaving 2005 with booming businesses. 2006 is going to be a transition year now that all the big players are falling over themselves to embrace open source, some more elegantly than others, some more willingly than others. For example, Sun's open sourcing wasn't a big financial hit because it represented such a small part of their revenue; specifically, the software was 1% of Sun's revenue. So they could afford to go the full Monty on open source.

For other players like BEA or IBM, it's a different ballgame, where they have to protect their revenue streams. I think the challenge in 2006 is you're seeing an explosion of business models around open source and how exactly those dynamics play out is what concerns me. Are the big players going to roll up? Are you going to see mushrooming business models and an ecosystem that's thriving? I'm hoping for both. I'm wondering how this is going to play out, not in a negative way. Professional open source is the way of the future. That's for sure. How it's going to play out, nobody knows.

Read:
 JBoss' Marc Fleury on open source in 2006, part 1
JBoss' Marc Fleury on SOA standards, Java and paranoia

Fleury seems to oppose SCA on competitive and process grounds, not its inherent flaws. I'm opposed to the SCA spec because it emphasizes SDO and is built by the same folks who have foisted on us a lot of other bad software. Take Axis 1.x for instance. It unnecessarily tightly binds servlets, a limited data binding scheme, etc. It is too big and complex and its too hard to pick off the parts you need. (Axis 2.0 is a huge improvement - stolen from xfire and activesoap I think.) SOAP itself is relatively simple, but they gunked it up. SDO is a standard looking for a problem to solve.

I don't object so much that someone wants to build SCA and offer to those who want it. My fear is that I will be forced to deal with it by PHBs and/or because of its coronation as a "standard".

SCA does not require SDO.

SCA does not require SDO.

No, it does not "require" it, but as the IBM site says:

"SCA also promotes the use of Service Data Objects to represent the business data that forms the parameters and return values of services, providing uniform access to business data to complement the uniform access to business services offered by SCA itself." http://www-128.ibm.com/developerworks/library/specification/ws-sca/

My point is that my experience has taught me to be suspicious of these efforts. They tend to replace complexity with different complexity while reducing flexibility. It doesn't have to be that way and eventually, as with Axis 2.0, they sometimes make things right.

Remember these guys also supplied us with tools to generate "services" and WSDLs from Java objects. Thats not creating services, its creating distributed objects. Services start with the interface/contract (e.g. WSDL), not with code.

You can use it if you want, and maybe one day I will too, but not any time soon.

SCA does not require SDO.

No, it does not "require" it, but as the IBM site says:"SCA also promotes the use of Service Data Objects to represent the business data that forms the parameters and return values of services, providing uniform access to business data to complement the uniform access to business services offered by SCA itself."

My point is that you can choose not to use SDOs, whether or not IBM promotes this approach. Its largely orthogonal to SCA. In any case, if you do use them, you can treat them as a simplified way to work with XML (as compared with DOM), which is hardly the end of the world.

PS. Happy Rich?

SCA does not require SDO.

No, it does not "require" it, but as the IBM site says:"SCA also promotes the use of Service Data Objects to represent the business data that forms the parameters and return values of services, providing uniform access to business data to complement the uniform access to business services offered by SCA itself."

My point is that you can choose not to use SDOs, whether or not IBM promotes this approach. Its largely orthogonal to SCA. In any case, if you do use them, you can treat them as a simplified way to work with XML (as compared with DOM), which is hardly the end of the world.

The identical text about promoting the use of SDO can be found at the other partner sites. Look at http://www.iona.com/devcenter/sca/. You see, its not just IBM, its the cabel pushing their agenda that includes SDO.

Part of my point and my paranoia is that I don't trust this effort to keep things as a set of independent building blocks or tools you can pick and choose from. As with Axis 1.x and IBM's and others web services development aides, they tend to create frameworks that unnecessarily tightly couple things. If you try to use document/literal SOAP with Axis 1.x and your own data binding (like JAXB or something) and perhaps you want to do your SOAP processing in a proxy POJO called by an MDB, not a servlet and you don't want the framework deciding what your method names are, etc. , Axis 1.x gets in the way. Its easier not to use it at all, which is unfortunate and unnecessary. They only make it easy to do things one way and they make it more difficult to do it any other.

Frankly all my problems are at the lower levels, not linking components. Even then I have solutions now for most of the cases where a reusable solution is possible. Nothing you can do about legacy databases using AFU modeling. Beyond that I would just like the vendors to complete and bring up to date the tools and solutions that are out there now. Finish Axis 2.0. Give me better WSDL tools that support multiple protocols and transports. Lets nail down more of the WS-I profile. Finish WS-Addressing, et al and get me good implementations. Even more importantly, finish a really good, robust implementation of JAXB. I want one that can successfully bind to some of the gawdawful schemas out there like Global Justice XML. I also want every one to support some complete version of XMI so I can use the tools I want for modeling and development.

Why are we worrying about SCA and SDO when so many of the basics are undone?

I don't use DOM for XML anyway. I use dom4j.

SCA does not require SDO.

No, it does not "require" it, but as the IBM site says:"SCA also promotes the use of Service Data Objects to represent the business data that forms the parameters and return values of services, providing uniform access to business data to complement the uniform access to business services offered by SCA itself."

My point is that you can choose not to use SDOs, whether or not IBM promotes this approach. Its largely orthogonal to SCA. In any case, if you do use them, you can treat them as a simplified way to work with XML (as compared with DOM), which is hardly the end of the world.

The identical text about promoting the use of SDO can be found at the other partner sites. Look at http://www.iona.com/devcenter/sca/. You see, its not just IBM, its the cabel pushing their agenda that includes SDO.Part of my point and my paranoia is that I don't trust this effort to keep things as a set of independent building blocks or tools you can pick and choose from. As with Axis 1.x and IBM's and others web services development aides, they tend to create frameworks that unnecessarily tightly couple things. If you try to use document/literal SOAP with Axis 1.x and your own data binding (like JAXB or something) and perhaps you want to do your SOAP processing in a proxy POJO called by an MDB, not a servlet and you don't want the framework deciding what your method names are, etc. , Axis 1.x gets in the way. Its easier not to use it at all, which is unfortunate and unnecessary. They only make it easy to do things one way and they make it more difficult to do it any other. Frankly all my problems are at the lower levels, not linking components. Even then I have solutions now for most of the cases where a reusable solution is possible. Nothing you can do about legacy databases using AFU modeling. Beyond that I would just like the vendors to complete and bring up to date the tools and solutions that are out there now. Finish Axis 2.0. Give me better WSDL tools that support multiple protocols and transports. Lets nail down more of the WS-I profile. Finish WS-Addressing, et al and get me good implementations. Even more importantly, finish a really good, robust implementation of JAXB. I want one that can successfully bind to some of the gawdawful schemas out there like Global Justice XML. I also want every one to support some complete version of XMI so I can use the tools I want for modeling and development. Why are we worrying about SCA and SDO when so many of the basics are undone?I don't use DOM for XML anyway. I use dom4j.

I doubt IONA is part of a cabal in league with IBM. Someone from IONA can correct me if I'm wrong, but I also doubt they care at all about SDO. I think you're probably taking the marketing fluff a little too literally.

From my perspective, the motivation for something like SCA is to provide a simple way to use all the building block pieces you mention (WS-I profiles, WS-Addressing, better tools for abstract WSDL with multiple bindings, etc.) without forcing the developer to sweat the underlying details too much. If IBM produces a heavyweight, monolithic product, then use someone else's product, say, one that doesn't require SDO. I'm sure there will be useable alternatives.

I doubt IONA is part of a cabal in league with IBM. Someone from IONA can correct me if I'm wrong, but I also doubt they care at all about SDO. I think you're probably taking the marketing fluff a little too literally.From my perspective, the motivation for something like SCA is to provide a simple way to use all the building block pieces you mention (WS-I profiles, WS-Addressing, better tools for abstract WSDL with multiple bindings, etc.) without forcing the developer to sweat the underlying details too much. If IBM produces a heavyweight, monolithic product, then use someone else's product, say, one that doesn't require SDO. I'm sure there will be useable alternatives.

Did you even visit IONA's website or the joint announcement (IBM, BEA, IONA, Oracle, SAP AG, Siebel and Sybase)? That is the group behind this.

As to your next point about using another product if I don't like it, re-read my original post I said that I was suspicious of the quality of the implementation based on past experience. Where Fleury's objections seem based on business concerns, I am more concerned with its implementation quality and the fact that many of us in IT are forced to either consider (justify why we aren't using something) or use things that are bad just because they have been designated a standard or because some big company is behind it. Did you get that? Sometimes we have no choice!

Your other point about making it easier to use the building blocks (Addressing, WS-I, JAXB, etc.) also demonstrates you didn't read the posts. These building blocks aren't finished!!! If they were I'd be fine. I don't need some vendor to help me link components. That is the easy part. But if someone wants that help, we still need to complete the building blocks or SCA will either be unstable or based on proprietary standards. Put the cart behind the horse.

I doubt IONA is part of a cabal in league with IBM. Someone from IONA can correct me if I'm wrong, but I also doubt they care at all about SDO. I think you're probably taking the marketing fluff a little too literally.From my perspective, the motivation for something like SCA is to provide a simple way to use all the building block pieces you mention (WS-I profiles, WS-Addressing, better tools for abstract WSDL with multiple bindings, etc.) without forcing the developer to sweat the underlying details too much. If IBM produces a heavyweight, monolithic product, then use someone else's product, say, one that doesn't require SDO. I'm sure there will be useable alternatives.

Did you even visit IONA's website or the joint announcement (IBM, BEA, IONA, Oracle, SAP AG, Siebel and Sybase)? That is the group behind this.

Firstly I'm not pro- or anti- SCA, but I do think some level of objectivity needs to be injected into this discussion.

Just because IONA, Oracle etc. get together to work on something and produce a joint press release doesn't mean they agree on all of the contents (of the work or the press release). Although SCA isn't a standard, the collaborative effort will have been similar to working in a standards organisation: you give a little to get a little and the end result is often a compromise. So I certainly wouldn't tar every vendor with the same brush just because they appear on the same PR.

Firstly I'm not pro- or anti- SCA, but I do think some level of objectivity needs to be injected into this discussion.Just because IONA, Oracle etc. get together to work on something and produce a joint press release doesn't mean they agree on all of the contents (of the work or the press release). Although SCA isn't a standard, the collaborative effort will have been similar to working in a standards organisation: you give a little to get a little and the end result is often a compromise. So I certainly wouldn't tar every vendor with the same brush just because they appear on the same PR.

O.K., we know Fleury's stated concerns about SCA - not its technical merits but its effect on his business. We know my concerns. Do you have a position on SCA at all? What merits do you see in it? What do you expect its real impact will be? Is it more than another load of vendor junk being pushed on us because they want control (Fleury) or because they can't seem to finish anything and like to keep us distracted while the sell (me)? Are you going to just sit back and wait for others to speak so you can take pot shots? Take a stand man! The topic is SCA and its open for discussion.

I don't believe components on the serverside ever really made sense. I wrote a blog entry about this at: http://surfrat.blogspot.com/2005/12/server-side-components.html

There's a big war with Sun, with IBM, with everybody. We cannot afford to not be deeply paranoid as an organization.

War with Sun, You have to be kidding. Fluery seems to be at war with Springframework and Apache too. I don't get a sense of community from this guy. He is acquiring not evangilizing. He's got an EJB contianer and can't control the web contianer (Tomcat) and the swarm seems to be shifting to the web container. Tell me SOA is not a web container play with products like Mule and ServiceMix.

How many time it took to Fleury to produce this content.. no big message, no clever path.. It should have been a better idea to ask Fleury about the weather in SF bay !!!

Talking about Open source with Marc Fleury is king of a non sense today ! He is (more than JBoss teams!!) on war against Apache, Spring team, Open source community spirit...JBoss story is all about aggresive approach !!!!

Good news, last few lines say : "Humility is a key point!"
Bad news : Fleury is still in charge !

May be JBoss needs a new leader.. with charisma and respect!

Bad news : Fleury is still in charge !May be JBoss needs a new leader.. with charisma and respect!

Actually, as far as I know Fleury is not in charge any longer. JBoss Inc. has an external board that pretty much runs the show, and Fleury is just presenting it as a "public figure". You know, doing the Joker thing and whatnot.

Whether this is worse than him actually running the show I don't know. I guess the Microsoft thing is indicative of their amibition though.

Bad news : Fleury is still in charge !May be JBoss needs a new leader.. with charisma and respect!

Actually, as far as I know Fleury is not in charge any longer. JBoss Inc. has an external board that pretty much runs the show, and Fleury is just presenting it as a "public figure".

Like everything else you've ever written about JBoss Inc, this is utter nonsense.

Rickard, please, please take a break from your obsession. It's sad and undignified.

What's the biggest challenge facing the open source model in 2006?

The biggest challenge of the open source model is that people can't tell a good open source project from a bad one.

Guglielmo

Check out the Fastest-Known Total-Ordering Protocol