Here is the announcement. The new version features OpenID support, drag-and-drop menu administration, several enhancements and tools for theme developers, and much more.
I already mentioned Hibernate Search and Shards. Here are the rest of the highlights from my perspective…
JBoss World Notes
- 750 – 1000 people at the conference, 30% from outside of the U.S.
- This was the biggest JBoss World ever.
- There were many sessions on Seam and SOA. The Hibernate sessions were overflowing. The BOF sessions, which ran from 8:00pm to 10:00pm, were also packed.
- JBoss’ middleware is on track to grow to be twice their server business.
- JBoss recently reached their 20 millionth download.
- There were about two dozen vendors in the exhibit hall, offering a mixture of tools/add-on solutions, and service providers.
JBoss Portlet Container 2.0
- More here
- Implements the Portlet 2.0 standard (JSR-286)
- Going forward, JBoss Portal will be based on this.
- This is the first portal from JBoss that does not require JBoss Application Server which is an advantage Liferay currently has over JBoss Portal.
In one of the keynotes they did a demo of a seam app. Then they jumped over to JBoss Portal and the seam app was running there as well within a portlet. I didn’t get the details on how much additional config is required to make the seam app work within a portlet.
JBoss SOA Platform
The JBoss SOA Platform is the commercially-supported bundle of JBoss ESB, JBoss jBPM, JBoss Rules, JBoss Messaging, JBoss Application Server. The SOA Platform is a single distribution/install but you can configure out what you don’t need.
- Routes messages (messages in the generic sense, not in the JMS sense, although JMS is one of the optional transports available).
- Declarative, clusterable, supports hot deployment. It’s ability to be clustered is one potential advantage over other open source ESB implementations.
- Listeners for many different types of transports are available such as Web Services, JMS, File, FTP, Email, Socket, etc. SFTP and HTTPS will be supported in future versions.
- Demo showed an order being placed in SalesForce. ESB picked up the payload and parsed/transformed it using Smooks. If the order was below $5000 it was approved which made a call back in to SalesForce to update the order. Otherwise, it triggers an approval process.
- Many ESB’s in production today were custom developed. A lot of times this means a limited number of transports are supported (e.g., only Web Services)
European Railroad Case Study
- 100,000 passengers, $1b in revenue
- Used JBoss SOA Platform to move unsold tickets to EBay auctions (and back)
North State Communications
- Configure and track comm equipment down to the neighborhood level
- Integrated apps and workflow using JBoss ESB and jBPM
Big Lots Case Study
Inventory Management application
- Deploying to each of their thousand or so stores. JBoss app server and MySQL run in each location.
- Developed (and open sourced) a data replication solution called Symmetric DS that moves data between each store (running MySQL) and the central office (running Oracle RAC)
- Multi-channel app: Web client, PC-based cash register, Handheld devices (IE running on Symbol)
- 10 developers, 5-6 months
They had several constraints that shaped their decisions:
- Limited bandwidth to home office (56k frame relay)
- User proficiency with web
- Need offline support in case the link goes down between store and central office
Big Lots did some interesting work with ajax. Not all of their data resides locally in each store’s MySQL database. On pages with a mix of local data and remote data, the page renders immediately with the data it can get locally, then invokes asynchronous calls to retrieve the remote data. If it gets the data, the fields are updated. If not, the page still functions.
Seam is a Java web application development framework that significantly speeds up development by removing a good chunk of the XML configuration typically required. You can think of Seam as being JSF plus EJB3 with a lot less XML configuration and no JSF backing beans. Most of the configuration is handled through annotations in the Java code.
The framework includes many add-ons (such as AJAX and rich controls) that can result in very compelling user experiences and interesting applications, but it seems pretty easy to use only what you need.
Check out SeamFramework.org. It’s a wiki built w/Seam with documentation and downloads. Also, Joseph F. Nusairat did a pretty good Seam intro talk where he built an app from the ground, up. He’s going to post the demo (and what it took to build it) in a screen cast on his web site. I’ll update this when he’s posted the demo.
Seam 2.0.1 is now GA. Seam 2.1.0.A1 adds support for Portal and Wicket.
There are many cool examples of Rich Internet Applications (RIAs) out there but the eBay Desktop application is one I hadn’t seen before and is quite impressive. Aside from the sexy graphics it really gets interesting when you run it on Adobe Air. Air gives your Flex-based web application the ability to run like a desktop application. Because it has its own database, you don’t even have to be connected to the net. In the eBay example, when you close the app, it continues to run in the background and pops up little alerts when certain events happen (such as getting outbid or winning an auction).
Some goals of RIAs
- Richer, desktop-like user experience
- Remove view logic from the server
- Do more on the client (such as sorting, cacheing, etc.)
Flex is made up of two parts
- MXML (Declarative markup that wraps around the ActionScript
Flex’s two-stage compiler converts the MXML into ActionScript then compiles the ActionScript into bytecode which is saved as a SWF and then played by either the Flash player or AIR.Developing a Flex application essentially involves creating a mock dataset, coding up the ActionScript and MXML, compiling, testing, and iterating, and then implementing the thin layer that sits between the ActionScript and your back-end data sources.
More on Flex here
JBoss Single Sign-On (SSO) Framework
The JBoss SSO Framework allows users to sign in to a webapp once and automatically be authenticated in others even if the webapps are running in different domains. If the webapps are already using JAAS, this requires no change to the participating webapps. Unlike other SSO implementations, there is no central authentication server. If a user is unauthenticated, the webapp authenticates the user. When the user visits the next participating webapp, their credentials are trusted and the user doesn’t have to log in.
Four components of the JBoss SSO Framework:
- Token management
- Identity connector
- Webapp coordinator
- Federation server
Currently, only Java web applications are supported. Because the payload is based on XML (SAML 1.0) it should be possible to make the framework suitable for other types of webapps. If someone were willing to port the identity coordinator and webapp coordinator to another language such as PHP or Python, you could have a mix of Java and non-Java web apps in your federation. Of course JBoss would be happy to take the donation.
More on the framework here.
I attended two very interesting Hibernate sessions at JBoss World yesterday. One was on Hibernate Search, the other was Hibernate Shards.
What do you do when your customers add “Google-like search” to the list of requirements for the web application you are delivering? With a straight relational back-end, implementing that requirement might be tougher than you’d think. Just a few challenges are:
- “Keyword” search means you’re probably going to want to use wildcards which perform poorly.
- Your data is scattered across multiple columns. Writing a SQL query to search them all is ugly.
- SQL doesn’t really know how to deal with typical search constructs like proximity, synonyms, or relevance.
Hibernate Search is the answer. It combines the power of the proven Apache Lucene search engine with the ease of configuration of Hibernate. Hooking Hibernate Search into your app is a matter of dropping in a couple of JAR files and adding annotations to your classes to describe what should and shouldn’t be indexed.
What do you do when you can’t (or don’t want to) put all of your data in the same relational database? Google’s word for horizontal partitioning–taking horizontal slices of your database and storing each slice in a separate physical database–is called “sharding”. Give a few Google engineers passionate about the subject a few months and Hibernate Shards is the result (Google donated the project to JBoss).
Shards lets you come up with your own scheme for how rows will be partitioned. Each partition is called a shard. Once you’ve settled on a scheme it’s a matter of configuration through familiar Hibernate configuration constructs. If you don’t use any of the out-of-the-box implementations for how to decide which shard to create and find objects on or for how to generate ID’s, you’ll have to implement those interfaces as well. Once you’ve got everything in place, persisting and querying objects works the same way as straight Hibernate.
It may be surprising to those not actively engaged in the open source revolution, but when I talk to clients about their business problems I don’t have to spend much time, if any, selling the benefits of open source. Most of the businesses we talk to already get it. But every once-in-a-while someone will ask me, â€œWhy open source?â€. So I thought I’d talk about some of the reasons why Optaros clients choose open source.
There are many reasons why our clients choose open source. Some clients are initially attracted to open source by the idea that they may be able to lower their total cost of ownership by shifting a portion of their license dollars to services and saving the rest. While that is a consideration, it’s not the whole story. In addition to lower cost, there are at least three other major factors that make assembling solutions from open source components an attractive option for our clients:
- Open source solutions are often a better fit.
- Open source solutions are often standards-based.
- Open source solutions are more transparent.
Let’s look at each of these.
1. Open source solutions are often a better fit.
It has been fairly well documented that companies have over-spent on things like application servers and content management solutions. As a whole the number is easily in the billions of dollars every year. Clients buy into the vendor pitch that a particular package can address all current and most future needs. They spend six figures on up front licenses, three to five times that on services to implement and customize the solution, and then 25% to 40% of the license fee every year on support and maintenance.
In the end they have a very complex, heavily-customized solution that takes a disproportionately large staff to run-and-maintain. They might use a fraction of the functionality the product provides out-of-the-box.
That would be bad enough if the functionality used was a fit with what the business needed. But the real kick in the shins is that after the product is installed the client may still need to go through major efforts to customize, extend, or tweak the system to make it fit their business.
Open source projects tend to offer the lower common denominator of functionality. Without spending anything on up-front licenses, you get what’s common across most installations. You can take what you would have spent on those licenses and spend them on services to fill in the gaps resulting in a closer fit to the business needs at a lower total cost.
As a quick aside regarding lower total cost, let me not paint too rosy of a picture here. Most clients pay someone to support their open source solutions. (As opposed to proprietary vendors, clients actually have a choice of support providers). Commercial support for open source software certainly isn’t free and often suffers from the same issues as closed source software support (slow response, foggy escalation procedures, shallow technical depth).
The point is that you don’t have to buy giant, sprawling platforms to get something that merely approximates your requirementsâ€”instead you can assemble solutions from open source components that get you closer to exactly what you need without up-front licenses.
2. Open source solutions are often standards-based.
Open source solutions are often based on established standards (or even built on top of other open source projects). This happens naturally–it is a lot easier, from a collaboration stand point and for sheer level of effort, for an open source community to build upon an established industry standard or other open source projects than it is to come up with a proprietary solution from scratch. Conversely, closed-source vendors invest time and money in proprietary standards to use as a competitive advantage.
Why are open standards important? For a couple of reasons. First, the pool of people in the market place who can quickly get up to speed on your system is far greater than for proprietary systems. As an exercise in the content management space, try searching Monster for people who know Documentum’s WDK. Then, try searching for people who know Spring, Hibernate, or JavaServer Faces (JSF), some of the core technologies behind Alfresco, an open source Documentum competitor.
The other reason why open standards are important is because it means greater flexibility. This flexibility might manifest itself as the ability to swap components in and out to fit the technology preferences at the client or to take advantage of specialized functionality. And it can mean lower switching costs. For example, maybe the repository solution needs to be switched out and because it is standards-based, content migration is easier. Or maybe switching out the portal isn’t as painful because the repository is JSR-170 compliant which makes it easier for other systems, like portals, to get content into and out of the repository.
Proprietary vendors often claim to be “open” and “standards-based”. Usually they are putting lipstick on a pig. The fact that your proprietary repository can store XML does not make it “open” or “standards-based”.
Of course, just because a system is open source does not guarantee 100% interoperability but, in general, open source solutions are much more open and standards-based than their closed source counterparts.
3. Open source solutions are more transparent.
The obvious example of transparency is that clients get the source code. Access to the source is invaluable when troubleshooting or customizing. Clients with proprietary solutions are often forced to decompile vendor code–a clear violation of most license agreements–just to figure out how to properly extend a component.
Beyond troubleshooting or customizing, the source offers an opportunity to help the community improve the product with bug fixes or enhancements. And clients can influence product growth and direction much more easily in the open source world because they can download and build nightly software releases as development is happening. Contrast that with the partner-only “early beta” software release approach of closed source companies.
The way open projects are run is also transparent. When a client invests in a critical piece of infrastructure, they need to know what the issues are with the system and they need access to people who have a deep understanding of the system. Closed-source vendors work to hide bug information for fear of hurting sales. And they tightly control access to the hardcore engineers, usually reserving access to them for “Enterprise” customers paying top dollar for the privilege.
Open source projects, on the other hand, usually provide full access to bug tracking. Clients can vote for and monitor issues they care about. Beyond that, they often make product road maps available in wikis, and low-level product planning and technical discussions available in forums. (Alfresco is one good example of this behavior but is by no means unique).
Open source developers aren’t secluded–they are usually active participants in the community around the project. These communities, made up of product development engineers (often working for commercial open source companies), integrators, consultants, corporate developers, and end-users serve as a valuable support resource for clients that is usually much more useful than the closed pay-for-support system offered by proprietary vendors.
I could add that many clients see solutions assembled from open source as having better stability, faster performance, improved security, and a shorter implementation time but these advantages all tend to accrue as a result of the benefits I’ve outlined above.
I’ll leave you with an anecdote I think is fairly telling. Six or seven years ago, clients would tell me they’d only consider open source as a last resort (if they even knew what it was). Last year, I was talking to a large client with a household name who said, â€œOur CIO has issued an edict which is essentially ‘open source first’. If we’re going to propose a solution using closed source software, we’d better have a very good reason.â€ For that client, I’d say open source had reached a tipping point. How far can we be from the rest of the world’s CIOs taking the same stand?
I’ve finally been able to carve out some time to play with some of the new stuff in 2.9 Community. One of the most hyped features in 2.9 is Facebook integration. I covered that by creating a screencast last month. Today I take a brief look at Dynamic Content Models, XForms in the non-WCM interface (“ECM Forms”), blog integration, project spaces, and category-based navigation. I’ll dig into Google Gadgets, MS Office integration (including tagging), and other 2.9 features in a future post.
Dynamic content model/web client configuration
One of the painful things about making changes to the model, from an “Enterprise” perspective” has been that it requires a restart. For a production repository serving hundreds or thousands of users this could be a real problem. In 2.9 Community, you can store content model XML, message bundles, and web-client-config-custom.xml in the repository and then dynamically reload them without leaving the web client. This also includes the ability to deploy workflow content models.
You don’t have to do anything special to your existing extension files to get this to work. Just drop them in the appropriate Models, Messages, or Web Client Extension folder in the Data Dictionary and use the new Repo Admin Console or Web Client Config Console to reload.
On a related note, you can now deploy process definitions from within the repository as well by placing them in the “Workflow Definitions” folder in the Data Dictionary and then using the Workflow Console to deploy.
For more information, see the Dynamic Content Models page on the wiki.
XForms in the non-WCM interface (aka “ECM Forms”)
When web forms first made their appearance as part of the WCM release, people asked, “Can I use web forms outside of the context of a web project?”. Now you can. There is a new folder in the Data Dictionary called “Forms”. Navigate to the folder, click Create Form, upload your XSD, and you’re all set. To create content with the form, select the form from a list of available forms when creating content. Just like WCM web forms, the embedded XForms implementation, Chiba, inspects the XSD, provides a form to capture the content, and saves the data as XML.
In my build, the creation worked fine but editing the saved data did not. I’ll do some more digging on this and file a bug report if it is a problem. (UPDATE: Someone already entered a Jira issue on this).
It is curious why Alfresco chose to split out “Web Forms” from “ECM Forms” when they are conceptually and technically the same thing. In fact, the inability to associate a presentation template (XSLT, or Freemarker) with an ECM Form is frustrating. I suspect, but haven’t confirmed, that web form data transformation is embedded in the web client layer instead of in the service layer making it hard to reuse in other parts of the app. Unless this is addressed, you’ll have to rig up your own transformations using rule actions or some other alternative to transform form data from XML into some other format.
I tested the ECM Form functionality with an existing WCM web form and it worked fine (except for the update issue I mentioned). Note, however, that the File Picker is not supported in ECM Forms. (Again, in my mind the two ought to be functionality equivalent so hopefully Alfresco will close this gap shortly).
For more information, see the Forms Developer Guide on the wiki.
The blog integration module adds the ability to post HTML and text content from the Alfresco repository to a Typepad or WordPress blog. Because this is implemented using aspects, you can add this capability to any space in your repository. Or, you can use it from the “My Blog Posts” space in a Project Space (more on that shortly).
Installing the blog integration module adds the Java code that implements the actions for adding, deleting, and updating blog posts as well as a content model with two aspects: Blog Details and Blog Post. The Blog Details aspect gets added to any space from which you want to post content. It tracks information such as the type of blog, URL for the blog, blog user name, and blog password (stored and displayed in the clear!). The Blog Post aspect gets added to individual pieces of content. Alfresco updates this metadata with information about the post such as the blog post id, the URL to the post, and post/modified dates.
For more information, see the Blog Publishing User Guide on the wiki.
You’ll notice a new node under Company Home called “Projects”. A Project is a space (folder) with a set of collaborative tools including Blog Posts, Calendar, Document Library, Email Archive, Forums, and an Image Gallery.
When you open a space a project dashboard, of sorts, is displayed as well as an online presence dashlet. The project dashboard gives each of the collaboration tools a chance to report status such as the number of new documents added in the last X days or the calendar events for the week, etc.
The presence dashlet shows the online status (Skype or Yahoo) of the people that have been invited into the space (either individually or as a group). Incidentally, the messaging ID of a particular Alfresco user is just one of several new pieces of user metadata added with 2.9.
Let’s take a quick look at the collaborative tools that are included by default in a project space.
The Blog Posts tool uses the blog integration module already described to push content to a blog. The Blog Posts space adds a custom view that shows articles that have yet to be published and articles that have been updated since they were originally published.
The Calendar tool gives you a monthly, weekly, or daily view of events. The events are created and stored (as calendarEvent objects) in the repository. You can also subscribe to other project calendars within the repository which enables you to see events from more than one calendar at once. (This functionality was contributed by a partner, which is cool, but there’s more work to do integrating the UI into the existing web client style).
Document Library is just a normal space with a custom view for seeing recent changes.
Email Archive takes advantage of the new functionality that makes it possible to assign an email alias to any object in the repository. There really isn’t a difference between the Document Library and the Email Archive–you could email content to either space. The Email Archive just gives you a convenient container for all inbound emails related to a project.
The Forums tool is the same forum space that has been around a while. It gives you the ability to have multiple forums for threaded discussions related to your project.
The Image Gallery, not surprisingly, is a space for images. The interesting feature is the folder’s custom view. It’s a photo album with turnable pages. Any images added to the Image Gallery space automatically appear in the photo album. More form than function, the widget is an example of how you can use Alfresco’s new Flex SDK to add rich interfaces to the data in your repository.
A Project Space is really just a Space Template so removing or adding tools to the Project Space is just a matter of copying and modifying the New Project space template in the Data Dictionary.
For more information see the Project Spaces page on the wiki.
Unfortunately, a problem with the category picker prevented me from fully testing this but if you click on the “Navigator” link in the sidebar you’ll see a new entry called “Categories”. If you click it, you’ll get a tree view of the categories currently configured in the repository. Clicking on each category should show content categorized to that category, essentially giving you the capability to treat the category hierarchy like a set of folders.
Try it on your own
I’d definitely encourage you to download and try out the Community Edition for yourself. I don’t recommend you run production solutions on Community, but it is a good way to try functionality that may make its way into the Enterprise release.