Thanks to those who attended yesterday's webinar, Demystifying ESBs for HR System Stakeholders, and many thanks to the presenter Larry Fulton.

Larry has made available a copy of the slide deck from his blog. Full replay of the session is available in the two video embeds that appear below.

Another resource that you may find valuable is the January 2009 report on ESBs that Larry wrote while at Forrester. Software AG has made the report available from its website (.pdf).

If Larry and/or I can answer any follow-up questions or be of any assistance, please don't hesitate to contact us. I'd be happy to forward your inquiries to Larry.

Part 1

Demystifying ESBs for HR System Stakeholders - PART 1, Larry Fulton, Senior IT Architect.

Part 2

Last week, I attended the IEEE Learning Standards Technology Committee (LSTC) meeting in Alexandria, VA. There are at least a couple topics discussed at the meeting I'd like to cover. I'm starting in reverse order in this post since I'm covering a topic discussed on the last day of the three-day meeting.

On that third day, Chris Guin of BBN joined us to review the "SCORM RTE Web Services Interface." This was developed as part of an "Integrated Prototype Architecture" funded by Joint ADL Co-Lab beginning in 2006. A paper describing this work was submitted in 2008 in response to LETSI's call for papers on requirements for a successor to the current-day SCORM standards. As the paper describes, the web services interface follows "as closely as possible" the SCORM ECMAScript Interface for Content to Runtime Services Communication (IEEE 1484.11.2-2003).

A key difference between the two versions of the same interface is that while the ECMAScript API facilitates communications to an LMS from a Sharable Content Object (SCO) delivered within web client, the SOAP-based Web Services interface allows any application to act as an SCO. Thus, the web services version opens up the opportunity to use SCORM for integrations where content is delivered within a specialized simulation or game application rather than just a browser.

Everyday there is more written and presented about what makes a good API.

In recent years, much discussion related to APIs has focused on architectural approach (e.g., SOAP-based web services vs. RESTful ones) or even how a specific approach (like REST) is best applied. Beyond all the blog-blather about APIs (this post included among the blather), there also is an increasing number of market metrics as to the type of APIs, as well as the particular APIs, that are gaining the most adoption.

Some of the metrics come from the API publishers themselves. For example, a key data point frequently cited with regard to Amazon web services (offered in both SOAP and RESTful configurations) is that 20 percent of the usage is SOAP, while 80 percent is REST. There also are a few independent sources of information about API usage. SOA analyst and born-again cloud-computing evangelist David Lithicum highlighted in one of his recent podcasts the website Programmableweb.com, which provides a directory of, and community feedback on, more than 1,000 APIs.

What Makes a Good API?

I won't try to recreate the aforementioned blog blather about what makes a good API, but if you want to be spoon-fed a good, high-level introduction on this topic there really are few better sources than the webcast embedded below (also available here) by Joshua Bloch, a senior software engineer and architect at Google. This is a high-level review of technical design principles. I have a follow-up regarding one of Bloch's early statements in the webcast about API's as "business assets," which I'll get to below the embed.

The non-profit National Bureau of Economic Research officially announced on Monday what everyone has known for a long time - that the U.S. economy is in a recession. As the economy and stock market spiraled downward over the past year, at least one thing on the rise was "Cloud Computing" as a technology meme. (Of course, the phrase "technology meme" is favored since it sounds so much better than "hype" ;-> ) As is the case with these technology memes, the definition of the particulars is seldom precise. However, the reason for the increased number of conversations around cloud computing is easy to understand -- Under current economic conditions, flexible, Internet-accessible technology and services are going to be in many cases much more attractive alternatives to building, buying, or managing infrastructure or business capabilities directly.

As the phrase is broadly used, "cloud computing" encompasses concepts such as "software as a service" (last year's meme?). However, you also see the concept used in a narrower sense to refer to a style of computing in which IT-related capabilities are accessed as services through publicly available APIs. These services can fulfill basic infrastructure needs such as storage or virtual servers (Amazon's S3 and EC2 being the best-known examples) or they can provide conceivably any other type of business functionality ranging from something tiny and specific (an address validation service) to something like the Force.com Platform that enables a wide-range of complex business functionality/capability to be built on top of the main Salesforce application.

But of course, none to which I refer is new. The architectural approaches are not new and neither are the services that I mention as examples. What is new is wrapping these up within the cloud computing meme.

Beyond the Hype, A New Focus on APIs

If you've worked in standards development for any time, you've likely seen skirmishes as well as major battles. Some prove to be worthy fights, while some have proven to be an absolute waste of everyone's time. Few produce absolute, bright-line resolution, but many do influence the directions of all parties - often for the better. Some are civil, while some involve behavior that we probably wouldn't want our children to emulate. However, this post isn't a rant about manners.

I'd be curious about what others who have worked in the area of business language and messaging standards would consider the most unruly standards battle of the past decade? "WS-*" web services versus ebXML? OAGIS vs. UBL? UN/CEFACT CCTS vs. ASC X12 CICA? While "REST" isn't so much a standard or specification, some of the "WS-*" web services vs REST debates have approached the same decibal levels. Even the "un-standards body," Microformats community, has had a bitter debate or two within its ranks.

While avoiding acrimony is desirable, the level of rancor within a discussion isn't by itself an indicator of progress or a lack of it. You can certainly find examples of individuals and organizations who were opposite sides of some of the aforementioned battles who have found enough common ground to be working actively and constructively on standards projects today. Really, this is the very essences of standards making -- going from the divergent to the common -- so those who have managed to reconcile differences to work with former competitors truly are the unsung heroes within their standards-making communities.

I've written in the past about HR-XML 3.0's potential as a common information model. But what if you aren't really so interested in a "component library," as much as you are interested in just few key interfaces with trading partner -- for example, an HR-XML-based interface for accepting assessment or screening orders. Don't worry - we'll make it easy for you to do this by publishing "packages" of assets drawn from the broader library just for these types of integration requirements.

"Packages," as I'm using the term, combine several schemas into a single flattened schema. Packages were prepared in contemplation of common or typical services implementers need to support. Each package contains an example Web Services Description Language (WSDL) file that may be used as a starting point for deploying related services.

From this page, you can browse and download individual DRAFT packages or download the distribution file that includes all of them. Links to related documentation are provided. If you are not yet familiar with OAGIS Business Object Documents (BODs), spending some time reviewing the documentation on OAGIS data management would be wise. Note that a feedback form is available at the bottom of each page of documentation, so don't hesitate to let us know what works, what doesn't, and what is missing.