Rob Brooks-Bilson

Matt Riley, one of our Sr. Engineers at Amkor has just released his first open source project, dubbed the Deployment Server. It's a ColdFusion application (Mach-II 1.5, ColdSpring, EXT 2.0, Java SE 6, Ant 1.7.0, SVN, SQL Server) that's designed to make deploying applications to various server environments simple, auditable, and secure.

We have a very rigorous SDLC at Amkor, and an even more rigorous internal and external audit. As part of that, it's important that we have a clear segregation of duties between developers, QA, approvers, and those that can promote code. In order to make our lives easier, Matt's created an application that provides a security layer around SVN and ANT that allows our operations group (or anyone else defined in the security policies) to specify which builds/tags are to be deployed, and to which server(s).

The application is highly configurable, but because of that, it's not just something you can download and run out of the box - it has to be customized/configured to meet the needs of your particular environment and process. For more information, or to download, check it out on the RIAForge website.

Any and all feedback is welcome.

Live blogging from SAPPHIRE 2008 in Orlando. Andre Salazar from Adobe is giving a session on creating engaging experiences for SAP using Adobe technology.

Main themes are Adobe has an entire group for managing the SAP partnership. Technologies highlighted include Flash, Flex, Air, PDF, and LiveCycle.

Partnership started in 2002 to replace SAP SmartForms with PDF Forms. Today, the partnership includes other technologies including Enterprise Learning (Acrobat Connect) and user experiences (Flash/Flex dashboards for SAP Analytics, RIA's within SAP).

SAP has licensed Flex for Visual Composer as well as several new areas, launching later this year.

Right now Andre is concentrating on Air. SAP is interested in Air for desktop/off-line capabilities. I'm not completely sure the way he's explaining it is connecting with the SAP audience. He's bouncing back and forth between Flex and Air, and I think that's further confusing people. They do seem to be respoding positively to the UI's that are being shown.

He's showing an example now of a company that put a Flex front end on top of SAP CRM. It's a (very) simple dashboard with charts and graphs. SAP is shipping an app later this year called Spend Analytics that's built in Flex and exposes cost and spend analysis. It's available in both Flex and Air.

Flex Islands inside of WebDynPro, also available later this year lets you embed Flex components inside the WebDynPro environment.

Excelsius (Business Objects) makes heavy use of Flex to generate rich dashboards from Excel data.

At Adobe, they use Flex and SAP for MDM Management internally.

He's now showing some more demos. The first one is the Adobe Customer Response Tool, built in Air. It's lined with SAP CRM for customer trouble ticket resolution. I see Christine Lawson's name on the demo screen ;-)

Next demo is the Adobe Directory, also built in Air. It's a little search widget that ties in with their LDAP as well as SAP's HCM system and MS Exchange. If someone in the search is available, you can pull up a map of the office and see where they sit. The latest version has voice chat too. Pretty slick.

Adobe has interactive forms internally for Travel Authorization. When you download the form, it's already pre-filled for lots of the information. It links to the travel policy via javascript (from intranet). Form has cost calculations and can be routed to managers for approval. The form is also available both online and offline.

He's now showing Acrobat Connect. It's amazing how much better Acrobat Connect is than WebEx and LiveMeeting.

Well, that's about it. Time to move on to my next session.

This post started out as an email response to a question Steve Rittler asked me about integrating ColdFusion with an Enterprise Service Bus (ESB). Since it's a fairly interesting topic, I figured it might benefit the community so I asked him if he minded if I posted my response as a series of blog entries. Before I speak to the specifics of connecting ColdFusion to an ESB, I think it might be useful to talk about what an ESB is, how it came about, and what sorts of problems it helps solve.

To give you some background, I've been working for the past two years now as the architect for a project to transform the way our company does integration. We're going from point-to-point integration using mainly shared databases, flat files, journals, and FTP to a service oriented architecture that uses XML messaging and an Enterprise Service Bus as the foundation. To understand how we arrived where we are today, it's useful to understand the evolution of integration patterns. As I said, my company had been doing the majority of its integration point-to-point. Each system was integrated with every other system directly – through database calls, sending flat files over FTP, etc. A typical point-to-point architecture looks something like this:

As you can see, it looks kind of messy – and it is for a large enterprise like mine. If you are a small company, though, chances are this is how your integration looks as well, and that might be fine given your situation. Just like the procedural vs. OOP debate or the framework debate, the integration architecture debate is discussed in similar fashion. That said, the main drawback to the point-to-point architecture is that it's an n² problem. That means for each new system you add to your architecture that needs to be integrated, you end up with a total of n² integration points. If you only have a handful of systems, you may be able to support this, but it can become unmanageable fast. It just doesn't scale well in most cases. Point-to-point integration is popular because it's so easy to do and can usually be implemented fairly quickly. "I'll just write data to this staging file" or "I'll just grab data from this table over here" probably sounds familiar.

This brings us to the next evolution in integration architectures – hub and spoke integration. Hub and spoke integration attempted to address the scalability and management problems of point-to-point architectures by introducing the idea of a central hub or broker. You'll often hear this referred to as EAI or Enterprise Application Integration as well. The idea is that all systems in an organization would connect to and send their data through a central hub. This way, connectivity went from n² connections to n:

Integration is usually performed via adapters for each specific application. These adapters can be as generic as file drops and database queries or API based adapters for connecting to packaged software such as SAP.

In order to integrate a new system in this architecture, all you needed to do is connect it to the central hub and it is then capable of sending data to or receiving data from any other system on the hub. Hub and spoke architectures make for more loosely coupled systems.

While the hub and spoke architecture was great at reducing dependencies as well as the number of connectivity points, it introduced several new problems as well. First, hub and spoke architectures tend to be proprietary in nature. They also introduce a single point of failure that can be difficult to mitigate. Additionally, they have historically have had scalability problems because of an inability to support large transaction volumes.

Because nothing in IT is ever the be-all and end-all solution, integration architecture continued to evolve. Seeking to take the best parts of EAI (centralized management, loose coupling, n lines of connectivity), a new integration pattern known as the Enterprise Service Bus or ESB emerged. Initially, the ESB was only an integration pattern – there were no commercial applications you could buy and implement. Of course, that has all changed. Today, you can find ESB product offerings from pretty much every major integration software vendor out there as well as a growing list of open source alternatives.

There are a number of features and characteristics that make an ESB different from traditional EAI/hub and spoke integration. It's difficult to get everyone to agree 100% on a universal definition of an ESB, but for my purposes, I've used this high level definition from David Chappell's book Enterprise Service Bus: Theory in Practice (O'Reilly):

• A distributed services architecture, which includes a lightweight container model for hosting integration components as remote services
• An enterprise messaging backbone that provides reliable delivery of messages between applications and services
• XML Data transformation
• Service orchestration and intelligent routing of messages based on their content
• A flexible security framework
• A management infrastructure that lets you configure, deploy, monitor, and manage your remote services

The implementation of the ESB looks something like this:

One of the most important aspects here and one that people often don't fully get at first is the distributed nature of the ESB. In hub and spoke EAI, all data has to be brought to the central hub in order to be processed. In an ESB, you actually deploy ESB end-points where your applications are located. If your data center is all in one building, it's as simple as pushing the processing out to other servers located in the same room. In a distributed enterprise, the remote processing means you can physically locate processing components where the systems you need to integrate reside. This makes the ESB much, much more scalable than hub and spoke architectures.

Another thing to note is that the distributed services architecture is implemented using lightweight containers. This means that you don't need to have an application server installed everywhere you want to deploy the ESB containers. That can easily lower your overall integration costs, especially if you use commercial application servers in your environment. All that's required to deploy the remote ESB containers is (usually) a JVM.

A third difference between hub and spoke and the ESB is that the ESB is built on a SOA foundation. Not only does the ESB act as the underlying backbone for SOA, but it is itself SOA based – all of its parts are loosely coupled and can generally be deployed separately as necessary. One benefit of this is that you can deploy only what functionality you need where and when you need it. If you have an intensive transformation process that occurs in one of the applications you are integrating with the bus, you can deploy the necessary horsepower there to deal with the transformation, without having to have the same configuration everywhere.

Applications can connect to ESB endpoints using a variety of mechanisms including but not limited to Web Services, JMS, JCA, HTTP, email, FTP, JDBC, adapters, and many more. How you connect will depend on what you are trying to connect, your overall architecture, and other factors. The bottom line is that there's no one way to do ESB connectivity, although your choice can impact ease of implementation, performance, scalability, etc.

I hope you've enjoyed this general overview of integration architectures. If you have questions or comments, I'd love to hear them. Stay tuned for the next post in this series in which I answer the question "how to get ColdFusion on the Bus".

Loading up Google Reader tonight, I noticed a new link that read "Read Offline". What was this I wondered, so of course I clicked the link. It turns out that Google's been working on a new open source project called Google Gears that allows web applications to run offline. Very cool. I can see myself using this when I travel to read my RSS feeds on the plane, or in airports that don't have free wi-fi (why pay $10 just to read my feeds for an hour).

Gears is a browser extension that Google describes as adding "... just enough to AJAX to make current web applications work offline."

It's certainly an interesting approach. I doubt, though, that the approach will be as flexible as Adobe's Apollo platform, but it does offer another approach for allowing offline access. For Google Reader, it's a natural fit.

Google is also working with Adobe, Mozilla, and Opera (and other companies) on the project to ensure that the project has broad industry support.

You can read more about Google Gears on the Google Gears site.

Back in August, Tim Buntel posted a short presentation titled 5 Reasons to use ColdFusion for your next internet application project. The presentation was designed to give ColdFusion developers and evangelists something they could present to their management and/or clients to make the case for ColdFusion.

In the presentation, the top five reasons given are:

1. Increased Productivity
2. Standard J2EE Environment
3. Innovative Features
4. Integration with other Adobe products
5. Part of a world-class software company

What I'd like to know is how other developers/managers out there sell/position/defend ColdFusion within their organizations? Are you using these same reasons? How are you expanding on them, and what else are you including?

Beyond that, I'd like to know how many other corporate developers out there are using ColdFusion in a mixed environment with other languages such as Java, .Net, etc. If you are in a mixed environment, what % of your development is in ColdFusion vs. the other language(s).

If you have the Enterprise edition of either XMLSpy 2006 or MapForce 2006, you'll be excited to know that the latest release (R3) now supports integration with Eclipse.

I've always liked XMLSpy, yet I've hated having to launch a separate editor outside of Eclipse. With R3, this is no longer a problem (same goes for mapping in MapForce 2006).

You can download the integration installers from the Altova website

I really wish all tools vendors would build on teh Eclipse platform. It would make life a whole lot easier.

I saw this one over on the Playfool blog. Apparently, Yahoo has a new Design Pattern Library over on their Developer Network website. JavaScript Source code and examples are available for several common UI design patterns including the following:

Autocomplete
Breadcrumbs
Drag and Drop Modules
Module Tabs
Navigation Tabs
Object Pagination
Search Pagination
Rating an Object
Writing a Review

Some of these are really cool. I especially like the drag and drop module as this is something I've been looking to do in a portal application we have. It will be interesting to see how the library develops as more people start contributing.

This isn't necessarily ColdFusion related, but what I want to discuss in this post does have the potential to impact how we as ColdFusion developers think about our applications. I'm going to ramble a bit here as I've got a lot of thoughts floating around in my head, and I want to get this out without all of the structure I usually put around my writing.

I just finished a three day proof of technology lab with IBM where we explored their soon to be released WPS (WebSphere Process Server 6.0). It was three days of serious acronym overload coupled with lots of hands on work with their WebSphere Business Modeler and WID (WebSphere Integration Developer) tools, both of which are built on the Eclipse platform.

I'm sure you've all head of Service Oriented Architecture (SOA) by now. It's a term that's been around for a few years, the idea being that you can assemble entire systems from components. Actually, SOA isn't really that new at all. It has roots in CORBA, DCOM, RMI, and other distributed computing technologies. These days, SOA tends to be associated with Web Services. It's important to note, though, that SOA does not equal Web Services. Web Services are but one way you can create a SOA.

Most organizations get their start with SOA by isolating discreet functionality within monolithic applications, decoupling it, and exposing it as a service (most often as a Web Service). The end result is a bunch of services scattered around the enterprise. The next step in the evolution of SOA tends to be an attempt to cobble together two or more services to construct crude processes. The problems with this approach become evident almost immediately. As the number of services grows, it becomes increasingly difficult to find them within an organization. For the discovery problem, we have UDDI (Universal Description, Discovery and Integration protocol), which allows us to catalog Web Services for search and discovery. Depending on whom you talk to, or which vendor's implementation of UDDI you have, your mileage may vary.

An even larger problem is that there's no easy way to choreograph services into a coherent process, let alone ensure reliability or continuity. This is where the WebSphere Process Server comes in. Simply put, it's a server based technology that provides a single programming model for SOA. It allows you to automate business processes by visually describing workflow that includes both automated services and human tasks. It adds support for transactions, exception handling, escalations, etc. to your services based workflow. The server uses WS-BPEL (Web Services-Business Process Execution Language), an XML based language, to model and describe business processes.

What was really cool for me was to see how (relatively) simple IBM has made it to model a business process using WebSphere Process Modeler, export that model as UML, BPEL, or several other formats, then import that process into the WebSphere Integration Developer tool where the model can be further developed into a composite J2EE application, tested, and even deployed to a WebSphere Process Server. Model Driven Architecture (MDA) is gaining traction these days, and with tools like this, I can understand why. With training, a business analyst could be taught to model a business process using the WebSphere tool. That model then serves as the foundation for the integration developer, cutting down on the amount of time the developer needs to spend trying to flesh out the actual business process. The WebSphere tool goes one better than using a tool like Visio because it allows you to easily export your model for use in other tools.

"Development" within WID can be done entirely without code via sophisticated design and mapping tools. The beauty here is that the majority of the real coding happens at the service level. That is, those creating the services you are going to consume are the ones doing the heavy duty coding the integration developer is more an expert with the tool. Having knowledge of Java is helpful and certainly allows you to do more with the tool, but it's by no means necessary.

I can't stress enough how tools like this enable enterprises to become more productive by focusing on tool based solutions rather than custom coded applications. The tooling surrounding BPEL in the WebSphere tools is amazing. This doesn't replace the need for skilled developers, but it does solve one of the major problems facing organizations trying to implement SOA – how to cobble together services into solid business processes.

One other interesting note from the lab is IBM's entry into the Enterprise Service Bus (ESB) product space with their WebSphere ESB Server. In simple terms, ESB is middleware that integrates applications, data, and services using a variety of protocols. Until now, IBM has strictly maintained that ESB was an implementation of a pattern and not a product, and has positioned several products around the ESB concept. This, however, didn't stop several other vendors from creating unified products around the notion of ESB. I believe IBM felt the pressure from both the industry and their clients to consolidate their products and fully productize ESB, which lead to the creation of their WebSphere ESB product.

O'Reilly just released a new site called CodeZoo. The goal of CodeZoo is hosting high quality, freely available software components. Sounds a lot like CFLib.org, albeit on a much larger scale.

For now, the site is only hosting Java components, but hopes to expend to a much wider audience. Let's hope that O'Reilly includes ColdFusion, Flash, Flex, Dreamweaver, and maybe even Central in that lot.