declaration of determination, part 3
(written on 1/1/4)
Unless there is an argument to the premise that market control rests with the J2EE developer, we are ready to form the governance of this market. As Jefferson, Mao, and Havel have shown, it is not in the content as much as in the context. Vendors and customers alike must either present a cause for parity, or begin to implement the organizing structure of the Java Economy:
1. All Java API's will be open sourced on java.net.
2. All WS-I approved specifications will be open sourced on wsi.org.
3. All vendor specific enhancements to Java and WS-I specifications will be published in at least two on-line databases - - freely accessible over the Internet.
4. Developer certification programs will be managed by non-vendor organizations.
5. Application portability testing will be open sourced and made available at no charge.
6. WS-I will maintain a database of available directories, with an overview of the services offered in each directory.
7. The open source community will hold elections on-line once every year to elect a representative from the developer community to the WS-I Board.
8. WS-I Board and working group committees will be recorded and the minutes will be posted within thirty days of completion.
9. Developers will be included in working group meetings and will have communication outlets to suggest topics and issues.
10. All XML end-points will be freely accessible, with WS-I certification of compatibility, and a guarantee of royalty-free, to prevent vendor taxes on XML exchanges.
declaration of determination, part 2
(orignially written on 12/12/03)
In order to fulfill the new economic order, one must have fulfilled the channels by which it can come from, by placing the impetus of the end-user in alignment with the requirements of a distributed economy, primed for the delivery of the services marketplace. Microsoft, IBM, Sun, HP, BEA, Oracle, SAP have all placed their bet on an infrastructure platform, not to mention Siebel, Peoplesoft, Novell, Hitachi, Fujitsu, and all other enterprise vendors. The only space with the upside for all of these vendors is in its delivery of a distributed environment for the use in an inter-operable ecosystem.
By representing the primacy of the J2EE developer in the role this new economy seeks to endeavor, we open the light to innovation of multiple facets. Not only do the competitive functions of the infrastructure battle bring about interoperability within the enterprise environment, but the need for services that operate in this new environment also take hold. Now that we have built an economy, it is time to build a marketplace, and one that can only be delivered by the adherents to the J2EE developer constituency.
I give JBoss all the credit - - they took the chance on community and all the forces were aligned to show how correct they are, and now they can create new paradigm terms like "Professional Open Source" and "Aspect-Oriented Programming" though the latter is common terminology, there is swagger behind its implementation. In the course of events, Marc still has a lot to prove - mainly scalability. It takes an army of Professional Service implementers to cover software spreads, and giving up on innovation for economic benefit is a little recession focused. Again, I can see the benefits of understanding your cash flows, but what is going to happen when the container is not the most cutting edge desgin enviornment?
What may be next is the development of an ecosystem of services that can demonstrate the scalability of the JBoss message. It is nice to be out in front of technological advancement, and it is a necessary element of the economic change to remove the proprietary app server vendors from contention on designing technological advancements, but its going to take another form of the platform to spread beyond the limits of what the professional open source crew can build. The power is in the distribution, and the economics are in volume. By providing the services that can run on top of the JBoss distribution, the ecosystem will enable applications to take form.
What is missing from the emerging Open Source J2EE environment is the services to enable the functionality necessary to carry the message forward. Only the core developers and the few IT personnel that hire them are made aware of the steps that are taken to make J2EE ubiquitous. Its going to require a broader set of tools that demonstrate the business fucntionality usage scenarios with web services integration capabilities. Only when Java can interoperate with .Net and demonstrate that is a superior transport technology will the enterprise investment be real. At present, certain firms are making targeted investments at infrastructure solutions, though not handling business issues. The web of vendors will not take the step needed toward platform integration, and so this will be required of some app market - - in the name of portable components that are the conduit to services.
declaration of determination, part 1
(written on 12/11/03)
Economic Means to fulfill Humanistic Goals of Self-Determination:
"When great powers fall, let all know that it was because the changing tide of the freedom and determination movement that made it possible was able to adjoin itself with one another, supporting the common cause, and make the fast break to a new beginning. With a new point of view, the never inevitable became possible - - make no mistake, there was battles to be won, and agreement to settle in to roles, once aschewed, for the sake of each other, and to begin anew. For only in economic terms can achievement be measured, and so it became the raison d'etre for all those involved.
To take over an industry is the first goal - for it represents a beachhead in to the other industries. When observing the economic lay-out of the worldwide market, there is one industry with a direct impact on the livelihood of all other industries: software. Utility grids, military communication, financial trading, and suply chains all rely on the orderly flow that is possible by software systems. There have been several attempts, mainly targeted at both corporate and consumer coup d'etats, but never one that targeted the heart of the community: the developers themselves. The only validated achievement has been Microsoft, and it is only in recognition that strength lies in the heart, that the heart was finally attacked. It began with the introduction of the Java 2 Platform, Enterprise Edition, the emergence of compatibility certification with the release of the iPlanet Application Server 6.0 in June 2000. What followed was the largest explosiion the software industry had ever experienced, with BEA WebLogic, IBM WebSphere, and over 25 J2EE compatible certifications for small, large, and even some rather non-software vendors. Certification was the only necessary credential required, and portability was the typically unspoken marketing strategy for each vendor, in its quest for Microsoft's jewels. The J2EE developer happily obliged the concept of vendor leadership on implementation with the enterprise customers but never agreed to relent control of the basic constructs of their power - - which was self-determination in the form of market value for services rendered.
This came in many forms, from the overall dynamics of a "J2EE economy" within the customers, service providers, systems integrators, vendors, and the developers to the support that became the foundation of the entire Java community, due to the majority penetration over all other enterprise technologies combined. Let it be clear that J2EE is considered to represent 50% of customers that are implementing distributed, Internet systems for application development and deployment, which leaves Microsoft with a maximum penetration of 50% - - far less than their historical norms of 80-95%, approaching 99%, which constitutes their overall business startegy, of monopoly control. To understand this paradigm, from a shift in power toward Java is to understand the enormous influence the J2EE developer commands. There is no singular IT constituency in business today more instrumental than the undefined but omni-present J2EE developer.
What will happen next? The best predicter of the future is the most recent history that has upended IT, and the livelihood of most of the application server vendors. For even though the distinction between J2EE winner and loser is more defined according to current customer adoption, there remains the glaring hole in the middle of the market that was once maintained by BEA, and now, increasingly, belongs to a brash start-up with a revolutionary business model called JBoss. This hole is the sentiments of the J2EE developer, and though IBM has achieved a great deal of damage control with Eclipse, and as Sun and Oracle market more sustainable app server platforms, none of the enteprise vendors garner the necessary grass-roots level support that keeps the developer aligned. Only JBoss intrigues, only JBoss provides a model for development to be turned in to developer funding - - for as we said, it is only in economics that the achievement can be measured, and it is the prospect of a pure developer economy, and one that has the customers looking to developers, not vendors, for answers...
diamelle
In a former glimpse of myself, and in my former job, I advocated within Sun for a small software company based in Cortland Manor, New York, about an hour north of the City if I recall. The only time I spent much time there was during a terrible snowstorm in 2001 or '02. But I was in close contact with the Architect of the company's software, SS for the better part of three and a half years. It is amazing that it was that much time, but we accomplished quite a bit for running a guerrila campaign within Sun and throughout the J2EE community. One might conclude that we should be reaping the rewards of this effort, but that has not come to be, and that is the topic of this post. Where did the Diamelle-iPlanet/Sun ONE alliance build value within the developer community, and what more can be done? These are difficult questions, but important ones, especially considering that it will not be done with the support of Sun for the foreseeable future, if ever. As I have wrote about in previous posts, it could be done with support from JBoss, but I am going to assume for the time being that it will be a future in which Diamelle will have to survive and thrive on its own, that its best days of partnering are behind it, and yet its better days of execution are ahead of it. Let me begin...
The dream or the vision came to me via Dan Graves, the product manager on NetDynamics, who in the fall of 1998, drew the constructs of an app server on a whiteboard. I was in my final year of graduate school, and had been closely tracking Java (at least as close as possible from VA), and was looking to build contacts to get an interview with Sun upon graduation (it worked!). In addition to the app server, DG demonstrated the goal of portability in the form of components, and in this case, it was EJBs, the new standard building within the Java community. I, seeking a component model to distribute via Castanet, immediately caught the bug, and began to develop a plan for an independent software company, focused on portable components. What I would only realize in December of 1999, after signing on @ Sun 9/9/99 (Sun employee ID 96969), was that my role would be to build the app server, while partnering with vendors to create a component marketplace. Diamelle was the first, and would be the one to stay with me the longest, through it all (someday, we'll be able to tell that story).
But to describe what it takes to start an apps company, it should be noted that Diamelle has a development center in India with talent that could not be bought in the U.S. without VC funding. Now that is the "World is Flat" side of things, but Diamelle is still working on their go-to-market strategy. I think their new approach with identity management is solid, and could be the entry point in to the marketplace for SOA-enabled component services. I'll have to evaluate after taking a product tour sometime, hopefully sometime soon. I admire what they are doing from a technology standpoint, and look forward to them being an apps contributor to the Java Enterprise community, a need that is certainly there, from a business standpoint, as well. It will take some time, but as MF has pointed out, the acceleration of the pace of adoption is making the market form more rapidly than previously imagined. Within a year, there will be posers and composers, and I would bet Diamelle is going to be right there with JBoss in the latter category...
JBoss
Competing with JBoss - - I would not want to be in this position, and would not have many answers for the established companies that are trying to keep marketshare in the face of an onslaught of open source. It is a testament to the viability of the JBoss model that almost all vendors have fired their reprisal and none seem to hit the mark, at least not for the foreseeable future. What I would say to start-ups is to partner with JBoss and not try and take them on head-on, at least not unless you have a significant business plan to gain developer adoption. This is where apps companies have some advantage. They can create new market segments and gain adoption from both developers and customers that are already using JBoss. IMO, it is the best means for a start-up today. All these companies trying to provide add-on features to the app server are likely to be gobbled up by JBoss in due time, but those app companies that work on top of the platform are likely to see some headroom for some time to come, as JBoss and other platform vendors continue to focus their efforts on the infrastructure to run the apps.
JBoss is an unique company, and I would bet that the only viable alternative will be JoNAS, with its support from Red Hat and other governmental backers. Glassfish will be a good reference implementation, though I am not convinced it will ever have Clustra capability. JBoss has engulfed the app server market and brought value in to it, at a time when everyone was predicting its slow death and fade in to irrelevance, and is leaving maintenance to be reconfigured into implementations. This is huge. From Ellison to BEA to IBM, the main revenue source has been from ongoing engagements, and from maintenance contracts that assume a competency in the support organizations, but does not account for a move toward new solutions. This is what JBoss is all about. They are challenging the notion that innovation won't happen for some time, and demonstrating that there is plenty of room for growth in the Java Enterprise phase of development. Why is this? Mainly because of the Java web services (JAX) spec's, and also because of the impending release of EJB 3, and JEE 5:
http://douglasdooley.blogspot.com/2005/11/jee-5.htmlThere is a good deal of innovation that can be done around the specification, as JBoss is demonstrating, with annotations, persistence, and cache'ing. I would think that the coming year will be a demonstration of the integration capabilities that are inherent in Java Enterprise 5, plus, of course, JBI. I am very excited to see the EJB 3 implementations, as well. Java One should actually be a marketing event, as opposed to the last two years. I would think that there would be some development of apps to this standard in the short-term, as JBoss is already playing up some customer examples of implementing the unfinished spec. They walk a tight line here, as they do not want to overinvest in any procedure that would not be in the finished spec, but the basics should be there. I wonder how else JB will be demonstrating their EJB 3 prowess. I would like to see some web services examples come from them, something that business people could take a look at, though this might be beyond current scope, and
not tailored for the developer community.
JBoss is off and running, they have no impediments for '06, and they should be the story of the year...
Frameworks v. Components
There is a new found enthusiasm surrounding the proliferation of Java frameworks, and there is growing support for these frameworks, including some of the larger Java companies, such as BEA. But this is an old discussion, and one that was presumably solved some time ago, especially with the introduction of Java web services and SOA. But when backed in to a corner, or when you have not figured out EJBs, you may play with the non-componentized frameworks. I am travelling in territory where I am not an expert, and could be corrected by someone like SS or Raible. However, it would seem that through the splintering of frameworks, a splintering of Java is being attempted. This cause is being led by the man who previously worked to spread the image of Java portability - - BR (get a haircut), but who is now pointing out the benefits of non-Java solutions. It makes one wonder if someone in his position can make the switch so seamlessly, or was there some disingenuity to his previous employer. Makes one wonder...
What I need to know from the esteemed Java community is what benefit are the frameworks bringing to customers, because it sure does not seem like it is bringing relief from proprietary extensions, thus lock-in, thus no portability, and thus increased costs. Is it shorter time to market? O.k., welll that is a pretty good argument, but it is also the one espoused by .Net. So what are the Java people doing in the land of frameworks? They are running for cover from the impending implosion of license revenue via proprietary extensions that will come with component services. I will coin the term. It is not web services, that is for Google. It is not SOA, that is for the infrastructure players, of which Sun and JBoss rule JBI, while IBM and BEA work on SCA (ou est, ORCL?). Rather, it is component services that will be the major part of the developer toolkit, that will transform the apps we use from intranet to extranet functionality. Its been 10 years since Netscape started the marketing for extranets, and it is only a decade later that the goal will be fulfilled by the Java Enterprise developer community.
Why are frameworks not going to work? Well, they're not really Java. They're a combination of Java and hooks, and other things you don't want to see if you're a business manager, but you must see if you're are a developer. So when the Java development community must come in to clean up the mess, the original implementer of the framework could be long-gone. Why not just build standard components? It's the best implementation of JEE, and it has longevity because of backwards compatibility and portability, two of the hallmarks of standard Java. I listen to BEA make their claims of development demand toward frameworks, and it reminds me of their claims of the Java web services extension that was built with WebLogic Workshop, which would "soon" become standard, though never did.
What we need is a community process toward componentization, so that companies such as Siebel do not steal the luster that they have been trying to undermine for a decade, due to their definition of proprietary Java. This includes SAP and now Oracle too. The only companies staying true to compatibility are Glassfish and JBoss, with the possible exception of other open source app servers. The rest of the software industry is running for cover from the nuclear bomb that is standard component services. Once it hits, it wipes out all license revenue in its path. That is not to say that these companies will go under, not at all. But they will be playing by the rules set by the Java development community, and it won't be the part of the community following frameworks.
Back to the silence, no more dropping science, e'rybody rhyming about diamonds and violence...
Component apps
It is another day in the build-out of the JWS infrastructure, and as I have mentioned here before, of all the companies in the world to be first to market, it is Siebel that, at least in name, appears to be leading the charge toward componentization:
http://www.infoworld.com/article/05/12/19/51NNbeasiebel_1.htmlI will also note the efforts made by SAP, though I seriously doubt their claim of thousands of separate services. If these are cross-platform (beyone NetWeaver) and can be used inter-operably among each other, than I will issue a correction here, but I am not holding my breath.
The one company that could change the nature of the components market is my friends at Diamelle:
http://www.diamelle.com/They have traditionally been out front on the components message, and it looks like they have built a nice new capability with identity management. I will be attentive to see what this does for the rest of their web services message. But in the very least it demonstrates their ongoing viability to survive and prosper - - reminds of me of a company from ATL...
I would be remiss to not suggest that their other component apps are also viable, for building marketplaces and conducting customer relationship management, but in the short-term, I look forward to their work with identity management. More to come on this and other apps topics...
JSR 109
I finally figured out why the need for JBI...because JSR 109 has found its way in to JEE 5:
http://java.sun.com/javaee/5/javatech.htmlhttp://jcp.org/en/jsr/detail?id=109MB would not want to have 109 run the SOA structure for Java developers...
Platforms and Apps
In earlier posts, I have discussed the nature of the JWS platform - - from app server to ESB and Portals. I have even given a glimpse in to the JWS apps world. All of these contribute to the larger ecosystem that has enabled software companies to be built of all types of sizes. In a world of standards, it should have been predicted by these ISVs that living on Java implementations would not be sustainable, though it is clear that JBoss is walking down this path. For as long as there has been J2EE, there have been pronouncements of capabilities to do more than just the Java layer(s). I see JBoss' attempt at providing an ESB as legit, but not necessarily the Portal. Why is that? Well, there is two types of companies: platforms and apps. Oracle is trying to do both, but there is no sign that they are attracting customers to their platform (Fusion) outside of those that have to for maintenance. BEA was an apps company, before they tried to become a platform company (read my analysis of Theory Center as their driver), and have basically failed, only to return to an apps company through Aqua Logic. I know some of you punters will cry that WebLogic has been the dominant app server for the previous five years, but they did not win. So as a platform company, JBoss has achieved something that no one other than Microsoft has been able to do, and that is to generate a standard by which all developers follow. I know, some of you punters will claim that maybe even Sun could be regarded as the organization that is most associated with Java. But Java is a programming language, it is not a platform, contrary to positioning from JavaSoft. The platform is the implementation, and that belongs to JBoss. As I have said, JBoss will continue to accelerate the rate at which the market coalesces around them. What is not as clear is their standing as an apps company. And here is where their Portal plans seem disingenious, or downright dangerous. Let's face it, there is not a standard by which to follow for building a Portal. If Plumtree could be the best without even running on an app server for some time, than what role does the Java community have in portals, and what is JBoss going to do that makes the IT community take a chance on running apps within that environment. Without a standard, JBoss is firing in to the wind, looking to increase their pull with customers, while potentially extending themselves at the expense of their platform dominance.
I see two outcomes from this strategy: one is to increase market share of Java apps, but two is to lose out on the larger JWS initiative. Why is this? The nature of their platform is that the community trusts them to build the most compelling implementation of the standard. Even considering Gartner's claim of SOA flowing through portals, I see the JBoss Portal as an enigmatic attempt to leverage rather than extend. In other words, they are billing rather than building. Just as BEA never had the appropriate organization to do apps at the same time as platform, JBoss is not organized to be an apps company, without coming at the expense of the platform. MSFT has had to expend tremendous resources to cover the gamet of platform and apps, and frankly, the verdict is somewhat out on their apps - - on the server end. Biz Talk is a nice attempt, but has not VB.Net been somewhat of a letdown, or at least .Net. Sure it will be there, but if a customer were to choose MSFT as their platform, it is not decided that they would choose them exclusively for their SOA/Apps initiative - - they gave this up with Hailstorm. I think JBoss has some bumps in the road, if they are sincere about making the app server an "middleware system". To me, a middleware system has plenty to do with the platform and innovating around the standards, and not much to do with apps, at least for JBoss.
So what company will do the apps for the JBoss platform? It's going to take a well tuned start-up to create the environment for apps to thrive. I think BEA will make money, but they won't be regarded as an apps company for another two years, and by that time JBoss will have eaten all WebLogic and Tuxedo's market share, so they will probably be on life support as an independent company. Rather than be simply an extension of the platform, the apps themselves will have to act like Hibernate, and consolidate the standard and implementations around it. What standards will those be? Well, I personally did not see JBI coming so it is possible that there will be new standards for the services themselves, but I think that is just as likely that the standards are in place for an apps company to get started. These include EJB and JAX. I can almost hear the punters screaming about too much complexity for services to be viable, but I am assured by the expert team that 3.0 has something to prove. I also believe that there is so much to be gained from a Java component infrastructure for any company. But I don't necessarily think that is where the apps will come from.
As I gave to MB back in '03, the telecommunications companies will be the platform provider for the apps, and the winner in the apps company competition will have established relationships with the telecoms industry. This is not necessarily aligned with the mobile initiatives, but instead will be a new business layer for the telecoms to offer business customers. I still believe in the concept of the cloud, but it will be run as an exchange with services coming off the unparalleled infrastructure that has been built by the telecoms. It will take bandwidth like no other bandwidth requirement, and it will take IT expertise that the telecoms feature. I would like to say this is going to happen next year, but it will take some time for the integration to be more settled, such as with the release of JBI-compliant ESBs, so that will likely push the apps struggle out to 2007. However, as Marc indicated, the pace is quickening as the realities of natural advantages settle with JBoss, and customers can see that an ESB offering from them is potentially a logical extension of the standard, we'll see. If not, maybe Glassfish will be the winner in the JBI world. My bet would be on Cape Clear if they were not mucking up the political waters. But the apps will be different from all of these battles.
It could be a winner take all, because there will be a standard and the best implementation of that standard will assure customers of no lock-in, and the apps will be optimized by the community. I know JBoss is dreaming of a world where they own this community, as well, but I see it as being too much to do while consolidating the platform market. That is lucrative enough for the next 5-10 years, I would think, and then they don't have to make ill-fated plays, such as with Portals. I have generally been correct about the Enterprise Java market, though mis-predicted components and services by about three years, so my analysis could be off. I generally think Marc and JBoss know what they're talking about, and this rapid consolidation theory holds some sway, at least I think it is partially objective. This makes me think that the apps company is already brewing somewhere, and sometime soon we will see the next evolution of the Java Economy marketplace...
Good bye, Sun
It has been two years this month since I left the company, and it is only in these forums that I have found freedom from the mark I left. There is no denying history. I joined the Sun-Netscape Alliance in September of 1999 after graduate school, later to be termed iPlanet, and was involved in the very tail-end of the launch of Netscape Application Server 4.0, the last product to be launched from the venerable, definitive start-up in Mountain View. Long before there would be Web 2.0, NSCP was the bomb that went off in the Valley, that imploded old-line software franchises, and created the Web, by which we all sustain today. In December of 1999, I met Suneet Shah, who Marc should be paying attention to, and created a virtual business partnership that spanned two coasts, and overturned the discernible BEA advantage in the app server market - - pre-built functionality. What will become of this relationship, that had the luxury of friendship in conjunction with mutual business objectives, which is also a defining characteristic of successful start-ups, is yet to be determined. Maybe we'll figure it out soon enough to help JBoss. Maybe they'll figure out how much of an advantage JWS would bring to them, beyond just JBI functionality, in the form of components.
I met CC in '99, as well, and along with RO and JH, we launched J2EE with certification for iPlanet Application Server 6.0, the first to be J2EE-certified. BEA complained that it was only due to iPlanet's relationship with Sun, but the reality is seen today, that they only had to lose from J2EE compliance in the long-run. Without proprietary foundations, the infrastructure gets open and better, as Marc says much more voraciously than I:
http://jboss.org/jbossBlog/blog/mfleury/2005/12/13/War_of_the_Worlds
_act_4_The_Elephant_and_The_Tiger.txtIn September of 2000, we launched the first pre-built, cross-platform components for the app server market, demonstrating once again that BEA was more concerned with lock-in than with customer capabilities. I went in to a fight for my life mode sometime in 2001 when it became obvious that Sun would not continue as is, and waited for my turn to demonstrate that what we started with NAS 4.0 would be fulfilled. This was made clear on October 28, 2002 with the launch of Sun ONE Application Server 7. Over that year, I learned more about everything than at any time in my life. It taught me survival, and it taught me about business. By the time, I left California in August of '03, the following had been established:
- Sun's volume app server business
- Sun's high-availability app server business
- pre-built functionality in the app server market
Could I have done more? Perhaps. Did I need to do anything more? Not really. Sun was viable. Even considering the negative press, including MF who should know better, Sun had a poison pill in the form of an app server franchise, or in our terms a Java web services franchise. Over the course of 4 years, I kick-started J2EE, established Sun's app server, and set the direction of the JWS market. Enough said, enough done.
What I have tried to do over the past several months is provide insight in to the Sun decision making process around the core JWS platform. While this is not exhaustive, if you were to follow my posts, you will see that SUNW is a company in need of a future purpose. They have not invested in a JWS infrastructure, and bet on Solaris, in the mis-guided hope that locking-in to OS will do more than optioning the Java OS.
I can agree with Marc that the app server market is all open source, all the time. And so it may be time to begin a review of the entire Java space, including JBoss. I think it is time to begin building the Java Economy one step at a time. The infrastructure is there. The product direction is there. What is needed is a new company that will take it to the next level. Maybe that will come in '06...
MF
In the future, there would be a software shift that would resemble the shift from non-Internet to Internet applications. The Economist wrote one of the definitive articles on this issue:
http://economist.com/surveys/displayStory.cfm?story_id=568249In the analysis of the "cloud", there was an assumption that much of the infrastructure was in place, due primarily to Andreessen's company taking press for his cache. The Economist did reference the open source movement, but it predated the public release of the company that would define it. I was asked at Sun to do an internal analysis of the low-end app server market, to define the market segmentation between Sun's app server, Platform and Stadard Editions. My take on it was simple: partner with JBoss. In the larger Markets Requirement Document (MRD - - in Sun product development parlance) discussion which my guy, PC and I led, I re-iterated my basic thesis: the app server market was robust, it would continue to generate revenues that sustained an economic value proposition around the ecoystem, and that JBoss would increase the rate at which this market coalesced around them. In other words, Sun would only succeed if they embraced the JBoss model, if not JBoss themselves.
In a side not to this post, the response by Sun was to re-trench in to subscription pricing, an unproven model, and to push me out the door. I understand what happened, and why, but JS is only playing under the terms that I proposed in the Spring of 2003.
JBoss was a developer preference, but it would not add clustering, persistence, management, transactions, and J2EE-certification until after I made the argument that the new power in town was known, and that Sun's business would be directly impacted if not a reflection of JBoss' growth (is not the Tx hardware tailor-made for JBoss customers that do not want switch to IBM, but do want to get off WebLogic licenses). I am leery to make such strategic moves public, as it discounts the Glassfish initiative, which is a legitimate contender to JBoss business, but based on JS' continued dragging of the feet on Clustra positioning, I don't know how to help them anymore. Contrary to Marc's claims of SeeBeyond significance, the only thing that matters out of Sun is this: Glassfish community building Standard Edition and JBI, Sun app server engineers working on Clustra with N1 and Blade servers, and Sun hardware engineers working on reference architectures for Tx and Blade implementations with AS, EE.
The rest of the market is all about JBoss taking share from WebLogic, while IBM fights for their base via Geronimo. Not even Google is in a more strategic position in their respective market to take control, than what JBoss is going to do in 2006. As Marc points out, this is causing great upheavel in the app server ranks, and extending to the integration market (which is going to JAX via JBI):
http://jboss.org/jbossBlog/blog/mfleury/2005/12/08/War_of_the_Worlds_act_3_IBM_and_BEA_strike_back.txtSo what I am saying is that the market that the Economist predicted in the spring of '01, will be here via JBoss and JBI this summer, and via MB (just hold on) @ J1. Whatever counter moves planned by BEA and IBM, and ORCL for that matter, the start-up is about to win where even Netscape failed. I look forward to some strategic posts from MF to declare victory where victories have been earned...
my point precisely
http://www.theserverside.com/news/thread.tss?thread_id=37984Doing a Java benchmark on WebLogic is worse than doing one on Linux...
Java hardware
In a battle to win implementations of the Java web services market, JS has bungled another opportunity with a presumed nod toward installed base that is looking for reasons not to select his middleware, and so (as Gavin pointed out:
http://www.theregister.com/2005/12/02/badger_two_point_nought/) he delivered. With a pre-installation and performance test of WebLogic on Sun Fire Tx Servers, he has again withdrawn efforts for SJAS, while propping up the dying infrastructure that is BEA:
http://www.sun.com/smi/Press/sunflash/2005-12/sunflash.20051206.2.htmlI wonder where his Wall St. boys are now, as they have proclaimed the emergence of his software strategy as the future of Sun. These pundits are worse than .com, or is that Web 2.0, pundits. They think that subscriptions are worthy of a strategy. They think that enterprises are willing to forego their investment in the name of his behind-the-curtain schemes. Sun shareholders, of which there are approximately 8 total, have become accustomed to the regular mid-handlings of the software infrastructure that should be Sun's competitive advantage vis-a-vis their competitors (that is enterprise system vendors not software vendors). He is playing in a league of which he has no concept that sticks, and doing so at the expense of the true competitive advantage. All eyes should be on the performance tests of Glassfish on Tx, but that will not come as long as he is more concerned with his good friends down the road.
Java hardware has a nice ring to it. It combines the two strengths that are outside of his control, and represent the true future of Sun. Gone are the heady days of Liberty, Net Beans, and Creator - - flat out, no one cares. The only real work being accomplished is outside of his domain, and is typically being implemented in ATL. I would love to see what Marc really has to say about the "ballsy" move that brought WebLogic back from the point of irrelevance this week, during their Beijing conference, at the stroke of their favorite boy wonder. It is too bad that the people who know about this are not allowed to blog about it, nor are they in a position to say much more than we support him because of his allegiances. He joined a third-rate start-up, was a second-rate manager, and got a first-rate position for only reasons that the Sun shareholders can explain. They should hope they have other investments.
I like this multi-threading business - - it is the biggest step since the pixy dust days of Ultra Sparc II and III. It shows that Sun is alive and kicking, albeit without true leadership. There will come a day when they will have to show something more than just press releases to be taken seriously, but until there is a Clustra implementation of Glassfish, that day is a long ways off. Multi-threading gives the hard-core Sun reps something to talk about, and the engineers something to optimize, while the rest of Sun languishes under the weight of a single individual. It is time for the Java community to speak out against Sun support for BEA at the expense of others, and it is time for the Sun community to speak out against it as it continues to come at the expense of the market-busting SJAS, screw it, from now on it's just the Java OS. It is no longer in the same category as other app servers as it retains the enviable position as the next OS of the creator and owner of Java. And as long as it is not supported by executive management, it is a start-up within the systems company. Some day, those who are working on it will have their day, but as they struggle along, I send my regards. As mentioned before, this Blog is dedicated to the Sun app server product managers who continue to get no respect (from their main boss included), while keeping the dream of a Java economy alive and well...
Gavin @ El Reg
JS has embarked on a multi-year plan that will do nothing for SUNW in the meantime, but I think you need to talk with some people within the company and stop looking to the leadership for answers. If you can run in to MB, you would understand the AS9/JBI integration plan that will throw open the next wave of innovation in the middleware market. Like you implied, app server is a business, as long as database is a business. We made sure of that. I am slipping in to the weekend in GRR, and just listening to Poets of Rhythm from Quannum. I guess I am making my way to Joyo's recording in time, but wish I was in SFO tonight for LB at Moscone (feel the rush, some date T.B.A.).
I give Gavin credit, he called JS and JL to the table over how to run a business, though you got to admire how much they are trying to stop the bleeding from OSS. If only the people knew that it was BEAS' war they are fighting, and do nothing for the non-instutional investors who are languishing at sub-$4. Marc must be getting some sweaty palms right now over the presumed attack from the two biggest (to say nothing of ORCL). First, Geronimo, now JES, it makes you think that they are on their way to $1B in services contracts - - are you? I like that JS is putting up a fight though he is far away from making a dent in the problem. He is running from the standard set internally and not able to use that to his advantage now that SeeBeyond is attributed to his ploy. Thats the irony of this, is that he could have adopted Glassfish, but instead he went with legacy, and that means he truly does not have the control over what is going on within his own company. That much I know.
On this Friday, we are reminded of John Doerr's proclamation to Stanford in the '90's that all technology is political, hell, all business is political, what's the big story anymore. I just like that we now have a fight, even if it is a multi-year fight between AS9/JBI and WebLogic/AquaLogic/SeeBeyond. The gauntlet has been thrown down, either you support JBI or you don't. SeeBeyond will not. Aqua Logic will not. Apache won't. And Oracle will adopt it in passing. That leaves Glassfish and JBoss. Cape Clear, am I detecting a pulse?
