Sometimes standards evolution can read a bit like a religious work! For example: in the beginning there was the word and the word was "events". Some of the Web Services architects looked at the word and came up with WS-Events. The rest of the Web Services world looked on that specification and found it wanting so begat WS-Notification. But this wasn't enough for some and they begat WS-Eventing. As with so many of the standardization efforts in those prehistoric days (WS-CAF vs WS-TX, WS-Reliability vs WS-Reliable Messaging etc.), this lead to confusion for the people, especially as none of these approaches were standards initially.
Fortunately WS-Notification eventually went to OASIS and became a standard, but it lacked the support of all major vendors. A modified version of WS-Eventing became a W3C Note around the same time but this is significantly less than a standards stamp of approval, though it did have some of the author companies from the other specifications involved. Yet more confusion abounded! Event notification ranks up there with security, transactions and messaging as core to most distributed system technologies over the past 4 decades. So it was no surprise that it would eventually come to pass that events would find their way into Web Services. Unfortunately because there is no single standards body for all Web Services work, that tends to lead to competing specifications (and standards). It's getting a lot better these days than it was back in the early 2000's, but it's still not perfect.
In an effort to solve the confusion around events all of the main protagonists (ourselves included) got together last year to form the Web Services Resource Access (WS-RA) technical committee within W3C. Part of that effort will standardize WS-Eventing. The timescale is fairly aggressive, with final standards due in June 2010 (which will include interoperability efforts).
But what do you do in the meantime? Events are important. Some vendors have implementations of one or more of these specifications/standards. What does that mean now that WS-RA is changing things? Well it definitely means that if you're already using a product based on one of the existing documents you will have to change something: backward compatibility is not a key aspect of the WS-RA effort. Of course change for change's sake won't happen, but some changes are inevitable (e.g., because the specs were broken or experience has shown a better approach). I'm sure some vendors will try to provide means to allow their existing products to continue to work with the next generation, but it is likely that changes will be driven right up to the developer. So be warned.
In terms of our own WS-Eventing offering, it's based on the older documents and is a community-only release. We're going to be working on providing a version based on the evolving standard and may have early access releases before the standard comes out (being on the committee helps!) So feel free to use what we've got for now in the community and watch the forums as we begin to work on the next generation.
Back when I was a kid one of my weekly high-points was watching the original Twilight Zone (yes, in black and white). Many of those episodes started off with Rod Serling stood slightly off camera to the opening scenes, smoking and uttering the immortal words: "Submitted for your approval ..." as he whisked the viewer off on to some strange parallel reality where weird and wonderful (and sometimes scarey) things happened. With that in mind ...
"There is a fifth dimension beyond that which is known to man. It is a dimension as vast as space and as timeless as infinity. It is the middle ground between light and shadow, between science and imagination, and it lies between the pit of man's fears and the summit of his knowledge. This is the dimension of imagination. It is an area which we call the Twilight Zone"
If you've ever had to buy a car (or even a house), you probably know how things go in our world. You first decide what type of car you want (make, colour, cash range), then you look for a dealership. Next you visit the dealerships and, depending upon how good the sales guys are, may even reconsider everything you did in stage 1, coming away eventually with something you didn't evision when you first started (but hopefully something you still want!) Relatively painless. If there are any problems with the car within warranty, you go back to the dealer and they fix them for you. In all likelihood, if you get good service you'll probably keep going back to the dealership even when the warranty expires. Plus, if you choose the right type of car, the dealership is the manufacturer, with the obvious benefits that affords.
Now let's pay a visit to a strange alternate reality where things aren't quite so simple. In this world you go to the dealership and they tell you that the car you want isn't available as a single item to buy. Unfortunately in this world you have to choose all of the individual components yourself (wheels, engine, colour, brakes, airbag, ...) But not only that, you have to deal directly with the individual manufacturers in the way the dealership did in our reality. The dealership may give you recommendations, but they only provide support for the chasis (for example). Plus, that's all they will provide cover for: if you have problems with the engine, you've got to deal directly with its manufacturer because the dealership doesn't have the expertise. Bummer. (It's left as an exercise for the interested reader to map this to buying a house.)
Now fairly obviously this parallel universe is not a very nice or efficient place to live. As a consumer the last thing you want to have to worry about it keeping track of which versions of the engine work in which versions of the chasis and with which versions of the electronics, etc. Plus, you don't want to have to try to keep track of any issues the individual manufacturers may report. If there were only a few components, then maybe it's something you could do, particularly if it were cheap enough. But it really doesn't scale. What you want is the ideal of the first universe: you get everything you need from a single place and let them worry about the individual components on your behalf. Even better if that single place actually developed all of the components themselves, because then they don't have the hassle of talking to other manufacturers. It really would be one throat to choke.
The same is the case in the computer industry. Back in the late 1980's and early 1990's it was a very regular occurrence to see people buying components and building their own (cheaper) PCs than the ones they could get from IBM or Apple. Yes they had the hassle of checking which components worked together, but the results were significantly cheaper than the commercial finished products. Some people even build their own components from scratch and sold them on much cheaper (very early open source?) But as the markets matured, we saw the arrival of companies such as Viglen (UK), Gateway and Dell who really pushed the price of entry level machines down so low that it became ridiculous to even consider building your own. (It's arguable that this effect also caused the premature death of Sun's Java Station - it was just far too expensive for what you got!) These days very few people build their own and are more content to go to a single manufacturer for the product, even if the individual components are sourced elsewhere.
In the software market, we saw a similar effect. Particularly around middleware stacks. Which are always evolving. Before the advent of open source, you had to buy your complete stack from a single vendor. There were a few exceptions to this, but on the whole you were left with little choice. It simply wasn't worth the price of trading one commercial component in a complete solution for a different commercial component (even if it was supported). Open source threw us into the alternative reality for a while because it really was cheaper (100's or 1000's of times) to do it yourself; and most of the time it just worked (tm). But as the amount of open source offerings increased along with the number of them that people found useful, the support problems grew for the end user (remember the car?) This made Professional Open Source a fairly obvious solution: go to one vendor for all of your open source requirements and let them handle the support, which they can do because they wrote the stuff in the first place! Now there are not many companies that can offer the entire stack in this way. Sure there are some dealerships that can offer you "support" (notice the quotes) for the stack, but when you look deeper you'll find that most of the components you need come from elsewhere. If you like the headache and worries that can cause, then maybe it's worth exploring. However, are they really so much cheaper (and better) than going to a one-stop-shop? It's hard to be objective, for sure. But at the moment the market is clearly showing that Red Hat/JBoss are the best place to go for the middleware stack: people who tried living in that parallel universe soon found out that the cost was detrimental.
We now return you to your regularly scheduled program.
A cross post from the JBossESB team blog.
A reprint from the JBossESB blog:
In May 2006, Swedish Railroads (SJ) was looking to upgrade its internal software delivery system in order to provide a shared platform for all IT systems. The integration of the IT systems is essential for SJ as it uses a diverse range of applications ranging from HR to sales, which need to be accessed across a range of interfaces, from PCs to PDAs. Within SJ, a new department was established with the task of building an integration platform and delivering new services for the business to operate on the platform. Swedish Railways is the national railway operator in Sweden. The company has around 350 stations, carrying 70,000 passengers per day. The company employs approximately 3200 staff and has a turnover of approximately $1 billion.
SJ put the contract out to tender, receiving proposals from many of the large SOA/ESB vendors, including JBoss. After extensive trial period SJ selected JBoss middleware solutions for its integration platform, due to its satisfaction with the product, its use of open standards and the impressive performance when compared to the other solutions.
Working with Redpill, the JBoss-based Integration Platform was launched in January 2007. The first major project, in May 2007, was the creation of a ticket auction system to sell unsold tickets on Tradera.com, the Swedish auction website owned by Ebay Inc. Using the ESB, any tickets which have not been sold by SJ with 2 days of departure are automatically transferred to the Tradera system, where they are available for auction until 6 hours before departure. On the 4th of October 2007 SJ went live with JBossESB! SJ's CEO did a live demo at a press conference to announce the release. The news was reported by every major paper and news channels, so this is a great success for SR, Redpill and JBossESB.
As the first test of the new SJ Integration Platform, the Tradera.com integration project based on JBossESB was a resounding success, and completed within only 4 months. SJ is now able to sell thousands more tickets per week, which previously went unsold. The entire process is automated, with the details of the unsold tickets being passed directly to the Tradera system.
Now that the Integration Platform is up and running, SJ plans to deliver a new project every 2 months. The upcoming projects come from both internal and external demand, for projects which could either be consolidating existing systems or creating new products.
A couple of weeks ago Thomas Erl, one of the main authors on all things SOA, donated his Service Modeler invention to Red Hat. As Thomas says:
"Service modeling is an increasingly important area for SOA. By providing a simple, platform-agnostic tool that can be used by a range of IT professionals to conceptualize, define and manage inventories of services and service compositions, this technology has the potential to drive more widespread adoption and improve the end results of SOA initiative"
The modeler should play a very important role in the development and lifecycle of services; something which, until now, has been missing or developers have been forced to use inadequate or ad hoc techniques and tools. As Thomas mentions and others agree(ourselves included), Web Services do not infer SOA (apart from the fact that one is an implementation technique whilst the other is an architectural style). So although some of what the modeler provides is available in pure-play Web Services environments, that doesn't help those users who don't want to, or can't, use Web Services. Plus, even in a Web Services environment, we're confident the modeler provides good value add.
This is a good thing for Red Hat, but also for the open source community. The invention and any patents around it will be covered by the standard Red Hat Patent Promise. But it's gratifying that Thomas chose Red Hat as the home for the modeler. As he said:
"Red Hat is an ideal place for SOA-related open source innovation today. I have great confidence in Red Hat's ability to oversee the open source project being based around this service modeler and transform it into a mass-market solution."
At the moment there is no implementation of the modeler invention, but we'll be trying to rectify that soon. The aim is to fold this technology into the Red Hat SOA Platform and our ESB as soon as we can with the help of the community. Innovation continues to grow!
I was at the Accenture Technology Architecture Workshop last week in London, as an invited member of the panel on "Platform Strategy" along with IBM, Microsoft, BEA, Oracle, Sun and SAP. It was a packed audience of senior management and architects and for once I decided that T-shirt and jeans were not appropriate.
For the panel, we were asked to give a brief 5 minute presentation on where we thought THE platform was going. I think we all agreed that there was not such thing as a single platform (another example where one-size does not fit all). There were a few minor differences of opinion on the importance of interoperability and portability. Each of us was asked to say something on SOA and the message was that it's important. At times it felt a bit like a sales pitch from one vendor or another to the audience; "things are great if only you'd use our products and services". I obviously kept Red Hat's offerings in the running, but pointed out that SOA isn't just about software: it's as much about the way in which you think about your systems and architect them. I pointed out that tooling (from all vendors) is still seriously lacking in this regard: it still encourages a closely coupled, distributed object approach for building applications. Not good.
Then we were each asked to respond to the same set of questions:- "With the complexity of standards around SOA, and with your company being a primary participant in driving standards, how are you going to make the approach to SOA easier for customers to consume?" Better tooling and education of sales forces/consultants in order to better educate the customer, were pretty much the agreed answers.
- "How do you view in the market the coexistence of 2 trends, one being Open Source and the other the traditional platform development? How do you take advantage of one or the other? Where is the trend going? What are you doing on Open Source and how (if) do you see this evolving?" Well there were the usual cries of how open source is good for certain things, but closed source was just as viable. It was pretty clear from the audience that they trust open source a lot more these days than they did several years ago. The fact that each of the vendors, even Microsoft, now does some activity in open source, spoke volumes.
I got some good vibrations from the panel discussion for our platform strategy as a whole and specifically for the SOA Platform. After the meeting these feelings were confirmed when I spoke with quite a few people from the audience. Everyone seemed to get the whole platform=stability equation. Some even said that it raised the chances of them using Red Hat middleware more now than in the past. I did wonder if I'd get pulled for us not having JBossAS 5.0 GA out yet, but instead concentrating on JBossAS 4.2 and the Enterprise Platform. That question came up twice, but both times it was as a "thank you" related directly to the stability aspect. One person even likened it to XP/2000 versus Vista: "We know we need to get there eventually, but at the moment the 4.x series gives us 95% of what we need now. All we were missing was stability and a solid base on which to deploy for the next 5 years."
Over all it was a great conference to attend!
The software industry goes through cycles, in just the same way as other industries. Back in the early 1980's we were working on defining distributed systems, with work on RPC, stub generators, naming services, transactions, security etc. A lot of work was done by vendors and academia, and interoperability or portability were not considered important.
Then in the 1990's we started to look at interoperability through CORBA (portability was still mostly a nice-to-have until the end of the century). When Java and J2EE came on the scene portability took centre stage and interoperability (between heterogeneous implementations) dropped away, unless you wanted to embed a CORBA ORB in your application server. Now we're into the Web Services age and interoperability is king and portability is nothing to do with Web Services specifications or standards bodies: that's the domain of implementation and other organizations such as JCP. It can often be a strange and inefficient approach: at least with CORBA you (eventually) got interoperability between different implementations and languages along with portability in the same package. With Web Services, you get interoperability out-of-the-box as soon as you implement (assuming you conform to the specifications and understand what they say, or don't say); but portability may not come for months or years!
JBoss/Red Hat is heavily into portability and interoperability, as well as standards compliance. Over the past years we've been looking out for any opportunities to help out customers in these areas, including joining the Interoperability Vendor Alliance, participating in a range of Web Services events, and working on standards committees such as WS-BPEL, WS-TX, WS-Addressing and WS-Policy. Standards compliance is critically important for us and our customers: we want to avoid a return to the bad days of vendor lock-in. We take interoperability as a must when developing our products, rather than as a second thought, by which time it's often difficult to retro-fit for existing customers. Portability is a given because of our strong support for JEE.
In that light, we've recently been taking part in a number of important interoperability related events. The Burton Group are hosting the OASIS XACML interoperability workshop and we will be there to participate along with IBM, BEA, Oracle, CA, Securent, Jericho Systems and SymLabs. I'm sure this will be a good event and very successful. Then the W3C has been holding a workshop on transparent eGovernment. Our presentation on eGovernment Portals, is very relevant to our overall goal of interoperability and portability for our customers. Expect more from us around security, federation and transactions over the coming months, as well as interoperability across the board.
There was a lot of hype around JBI 1.0 at JavaOne 2005. It was going to unify the ESB world and push JEE technology to the EAI masses. However, both IBM and BEA had exited stage left before the party even begans, citing the lack of need for such a technology, leaving only Sonic and TIBCO as the main supporters. Since then we've seen only a couple of commercial implementations and two open source implementations. Given its original hype, JBI has been slightly disappointing. Then along comes SCA with what some perceive as overlap in the JBI+JEE space and many people are already nailing the coffin shut on JBI. However, as far as we are concerned, JBI isn't dead. It's just been pining for the fjords. What it really needed was an injection of EJB3-magic and who better to help do that than us? Plus, we don't see this as a JBI versus SCA debate. Both have their proponents and that's why we're involved with them. We see JBI as a great platform on which to deploy SCA, if that's the way you want to go with your SOA solutions. But just as you don't need JBI to support SCA, neither do you have to be driven to SCA if all you want is JBI.
With that in mind it may explain why we've been discussing a successor to JBI with Sun for over a year, cunningly named JBI 2.0. As you can see, there are a lot of companies associated with the effort. The things we're going to look at include:
- Alignment with SCA.
- Performance optimisations (e.g., it doesn't always make sense to normalize your messages).
- Be clearer about where transactions, security etc. play in a JBI environment.
- Explicitly address distributed JBI.
- Leveraging OSGi where it makes sense.
As part of JavaOne 2007, Sun had a JBI 2.0 evening of BOFs, covering developer and user feedback on JBI 1.0 as well as a one targeted specifically at what users expect from JBI 2.0. That one was driven by Red Hat and was very well attended. The audience was very receptive to the initial discussion, which was meant to fuel the debate. Everyone seemed to agree that JBI 2.0 should become the standards-based deployment platform for ESB/SOA. There were few people interested in deploying to SCA, but it was "on the radar" as something they may need in conjunction with JBI. Plus, versioning of services is critical. This is interesting, because we've been saying the same thing since JBossESB started. It's good to see everyone else agreeing with us. The general conclusion from the entire JBI evening was that JBI 2.0 is needed and will be an important addition to the JEE platform. Both user and developer communities want to see more adoption. With any luck, 2008 will be the year of JBI (at long last!)
We're pleased to announce the general availability of JBossESB 4.0. As you can see, there have been some significant updates to this release since the first Beta Release late last year. Some of these updates haven't been to the feature set of the ESB, but to improving the out-of-the-box experience. which is very important too.
- We now have a lot of quick start examples, each one aimed at illustrating a particular way of using or developing on the ESB.
- There are some on-line tutorials, covering various aspects of the transformation engine and associated console.
- Amongst (S)FTP, email, SQL, file and other transports, we support JMS in various flavours, including JBossMQ and MQSeries. We'll be adding support for JBoss Messaging as soon as that is released later this month.
- The documentation suite has been updated based on feedback from the community.
We've in increased the size of the development community over the past few months and we're hoping that the user community will follow. This has been a community effort, but it's only the first steps towards our final goal. Don't forget, if you have any questions on using JBossESB then post them to the User Forum. Likewise, we're always happy to receive design questions or suggestions from the community. If you want to join our developer list, then email me.
We're currently taking part in the OASIS WS-TX interoperability event around the WS-BusinessActivity specification. This is the last part of the WS-TX specification to be tested for interoperability and we can finally see the light at the end of the tunnel. It's been a long road to get here, including OASIS BTP and OASIS WS-CAF and almost 7 years of effort.
JBoss Transactions has been involved with all of the specifications/standards over the years and used to demonstrate interoperability of them all. If you want to see how we're doing compared to the likes of IBM and Microsoft then check out the interoperability status page. Unfortunately as last time the names have been anonymised to protect the innocent. However, once again thanks to Kevin Conner our implementation is doing extremely well.
Once completed, the 1.1 version of the specifications will become a standard that will eventually be supported by all of the major Web Services vendors. At the moment and like the other participants, JBossTS supports the 1.0 specification. Expect 1.1 support from us in 2007, but note that we'll have to support both 1.0 and 1.1 for sometime to come.
JBoss has just spent the past few weeks working closely with IBM, Microsoft and other members of the OASIS WS-TX technical committee to validate the interoperability goals of the WS-AtomicTransaction specification. I'm pleased to say that, as with the first interoperability workshop, the committee has achieved its goals and demonstrated interoperability between a number of heterogeneous implementations. Next steps will be to make the specification a standard and to move on the interoperability of WS-BusinessActivity.
As far as JBoss is concerned, we used the JBossTransactions product as the basis of our interoperability effort. Because the technical committee is working on the next version of the WS-TX standards, this is not the same version of JBossTS we're shipping that currently has Web Services transactions support, simply because that release is only compliant with the previous specifications. Expect to see a release of JBossTS that supports both versions of the specifications in 2007, once the technical committee has finished its work. We'll also try to find a way to make sure our endpoint remains available in case anyone wants to use it.
If you want to see how we (and others) got on with interoperability, you can check the interoperability matrix. Unfortunately the table treats the participants anonymously and randomly: P1 now may be a different participant to P1 in a minutes time.
I blogged a while back about our acquisition of the Rosetta ESB. As mentioned by others, we've made significant progress on our SOA story over the past few months. With the release of JBossESB 4.0 Beta1, we're making another important statement to our customers and community: Redhat+JBoss is a powerful combination in the SOA space.
Looking specifically at JBossESB, we spent a lot of time and effort working with customers on our architecture and the Rosetta code donation has helped us to start to deliver on the goals. The fact that it has been in production use for 3 solid years is a critical component in the solution for our customers. It has a pedigree associated with it that is impossible to come by any other way: for any software system/application to be solid and reliable, it needs to be deployed, run and tested. This beta release may not be precisely where we want to be, but then what beta release is? It is fair to say that for this release we have concentrated on getting the core right, setting the foundation on which to build the product release. So don't expect lots of bells and whistles, but do expect a good offering.
The list of things to look out for in this beta release include:
- Support for ageneral notification framework. Transports supported include JMS (JBossMQ, JBoss Messaging and MQSeries), email, database or file system.
- A great trailblazer example. Check this out before doing anything else, as it's a good way to set the scene for the rest of the documentation.
- Support for data transformations.
- The concept of a listeners and action model to support loose-coupling of interaction steps. Again, check the trailblazer for how simple this is to use.
- A durable object repository.
- High performance and reliability.
- Built on JBossAS 4.0.4 and EJB3.
One thing I definitely don't want to let slip by un-noticed is that this ESB is truly a release build by the community and for the community. We've got a great team, composed of full-time employees as well as community members. The forum has always been active and this has helped us develop the ESB. Many of the forum contributors have subsequently joined the team in one way or another. I have been very impressed with the way in which the team has pulled together in this effort and I think it bodes well for the future!
After some delay (JavaOne and JBossWorld being primarily responsible, along with pesky customers!), we've released a new version of JBoss Transactions: 4.2.1. This release includes the first productized version of the Web Services Transactions component. It's still only compliant with the 1.0 versions of the specifications (we're working within the OASIS WS-TX technical committee on updated versions of the specification, which will include new interoperability scenarios) but that's the case for all of the major vendor implementations at this stage. In the past we've demonstrated interoperability with the likes of IBM and Microsoft and are currently going through a re-qualification process.
It's worth pointing out that we do not yet support the new JBossWS stack. That's on our roadmap, but is realistically a Q4 2006 or Q1 2007 goal.
We used JBoss Transactions at a successful BOF during JavaOne 2006 to demonstrate the requirements for long running transactions. There was a lot of positive feedback and a lot of people were impressed with how simple JBossTS facilitates the development of what can be a complex set of tasks. A similar presentation was given at HP World 2004 and the responses were good then, so it's nice to know we're on the right track and appear to be pleasing most of the people most of the time.
If you're interested in seeing what is possible with transactional Web Services, then I'd recommend checking out JBossTS 4.2.1 and looking at the WS-T trailmap. It's based on the well know "travel agency" example and shows how to use both traditional ACID transactions and newer compensation based transactions in the same application. As usual with JBossTS, there are a lot of details in the manuals, so check them out too.
After several months of discussions around the right architecture for a SOA infrastructure for the 21st Century and much community involvement, an alpha version of JBossESB was released in March which outlined many of the architectural principles. We've had great feedback from community developers, partners and prospective customers, all of them endorsing the approach we're taking: that JBossESB is a SOA infrastructure supporting best-of-breed deployments based on JEMS and partner technologies. However, the one thing that we were having difficulty on was keeping up with interest and demand: everyone wants JBossESB yesterday. In the week following the closure of the Redhat deal, the JBoss division has made a strategic move to address that deficiency with the acquisition of the Rosetta ESB.
Rosetta is an ESB that's been in production deployments for over 3 years, handle tens of thousands of real-time and batch processing events from legacy and J2EE applications, insurance underwriting and real-time quote requests. Although Rosetta doesn't match the architecture the ESB team have been working on, it is close enough that with concerted effort we'll soon be in a position to provide a production-ready version of JBossESB that will become the premier development and deployment platform for SOA in the industry. What we have done up to this point is lay the foundations for that platform. With this acquisition, we are building on those strong foundations and pushing the community effort into a new and important phase.
It's worth spending a few moments just to consider exactly what it is that Rosetta brings to JBossESB: support for a variety of messaging services, including JBossMQ and MQSeries; a transformation engine to bridge data formats; a service registry; a persisted event repository to support governance of the ESB environment; a base transport mechanism; pluggable architecture; and a notification service to allow the ESB to register events and signal subscribers. All of this in a product that has been running continuously for 3 years: a pedigree and level of trust that is difficult to find elsewhere in this new and emerging market.
Another part of this Rosetta acquisition is that I'm happy to announce that Esteban Schifman, Chief Architect at Heuristica and part of the team that developed Rosetta, will be joining the JBossESB team. As well as his Rosetta knowledge, Esteban brings a great deal of experience in this space which will be critical for Redhat's success with JBossESB. I'd like to welcome Esteban to a great community of like-minded developers and users: I'm sure he'll find it as stimulating as the rest of us.
Finally, just to recap and briefly indicate where we are going next. JBoss has been making good progress in the SOA space with JEMS and early work on JBossESB; we've seen significant take-up of our technologies and ideas by customers and partners alike. Now that we've acquired Rosetta, we'll be able to accelerate our plans for delivering on the architectural goals we have developed and hopefully benefit the community at large with the preeminent SOA platform we all agree is needed. Redhat is uniquely poised at this stage to deliver on that requirement with JBossESB. We'll have a beta version available in the next few months and a GA ready by the end of the year.
If you're at JBoss World Vegas then come and hear my talk on the subject.
One last thing: if you're interested in participating, please get in touch! This is a thriving community, but there's always room for more involvement.