Recently in Web Services Category

Box.net announced today that it has integrated its cloud-based document storage and sharing solution with Salesforce.com. Current Box.net customers that want to integrate with Salesforce CRM can contact Box.net directly to activate the service. Salesforce.com customers may now download Box.net from the Salesforce.com AppExchange.

Box.net services will now be available in the Lead, Account, Contact, and Opportunity tabs of Salesforce CRM. In addition, the Box.net native interface and full range of services will be accessible via a dedicted tab on the Salesforce CRM interface. Users can upload new files to Box.net, edit existing files, digitally sign electronic documents, and e-mail or e-fax files. Large enterprise users will be given unlimited Box.net storage. The Box.net video embedded below briefly demonstrates the new Salesforce CRM integration.

While Box.net started as a consumer focused business, today's announcement marks the first tangible manifestation of its emerging enterprise strategy. Box.net intends to be a cloud-based  document repository that can be accessed through a broad range of enterprise applications.

The content-as-a-service model envisioned by Box.net will gain traction in the coming months. I believe that a centralized content repository, located on-premise or in the cloud, is a key piece of any enterprise's infrastructure. Moreover, content services -- functionality that enables users to create, store, edit, and share content -- should be accessible from any enterprise application, including composite applications such as portals or mashups created for specific roles (e.g. sales and/or marketing employees, channel partners, customers). Users should not be required to interact with content only through dedicated tools such as office productivity suites and Content Management Systems (CMS).

Other content authoring and CMS software vendors are beginning to consider, understand, and (in some cases) embrace this deployment model. Box.net is one of the first proprietary software vendors to instantiate it. Adoption statistics of their new Salesforce CRM integration should eventually provide a good reading as to whether or not enterprise customers are also ready to embrace the content-as-a-service model.

Today is the long-awaited day when 100,000 lucky individuals receive access to an early, but working, version of Google Wave. I hope I am in those ranks! Like many people, I have been reading about Wave, but have not been able to experience it hands-on

Wave has been a hot topic since it was first shown outside of Google last May. Yet it continues to be quite misunderstood, most likely because it is such an early stage effort and most interested people have not been able to lay hands on the technology. For that very reason, Gilbane Group is presenting a panel entitled Google Wave: Collaboration Revolution or Confusion? at the Gilbane Boston conference, on December 3rd.

The confusion surrounding Wave was highlighted for me yesterday in a Twitter exchange on the topic. It all started innocently enough, when Andy McAfee asked:

To which I replied:

That statement elicited the following comment from Jevon MacDonald of the Dachis Group:

I am not a technologist. I seek to understand technology well enough that I can explain it in layman's terms to business people, so they understand how technology can help them achieve their business goals. So I generally avoid getting into deep technical discussions. This time, however, I was pretty sure that I was on solid ground, so the conversation between me and Jevon continued:

Now, here we are, at the promised blog post. But, how can Jevon and I both be correct? Simple. Google Wave encompasses not one, but several protocols for communication between system components, as illustrated in the figure below.

Figure 1: Google Wave Protocols (Source: J. Aaron Farr, http://www.cubiclemuses.com/cm/articles/2009/08/09/waves-web-of-protocols/)

The most discussed of these is the Google Wave Federation protocol, which is an extension of the Extensible Messaging and Presence Protocol (XMPP). However, Wave also requires protocols for client-server and robot server- (Web service) Wave server communication. It is also possible, but probably not desirable, for Wave to utilize a client-client protocol.

Jevon was absolutely correct about the XMPP protocol enabling server-server communication in the Google Wave Federation Protocol. The Draft Protocol Specification for the Google Wave Federation Protocol lays out the technical details, which I will not explore here. XMPP provides a reliable mechanism for server-server communication and is a logical choice for that function in Google Wave, because XMPP was originally designed to transmit instant message and presence data.

It turns out that the Google Wave team has not defined a specific protocol to be used in client-server communication. A Google whitepaper entitled Google Wave Data Model and Client-Server Protocol does not mention a specific protocol. The absence of a required or recommended protocol is also confirmed by this blog post. While the Google implementation of Wave does employ HTTP as the client-server protocol, as Jevon stated, it is possible to use XMPP as the basis for client-server communication, as I maintained. ProcessOne demonstrates this use of XMPP in this blog post and demo.

Finally, there is no technical reason that XMPP could not be used to route communications directly from one client to another. However, it would not be desirable to communicate between more than two clients via XMPP. Without a server somewhere in the implementation, Wave would be unable to coordinate message state between multiple clients. In plain English, the Wave clients most likely would not be synchronized, so each would display a different point in the conversation encapsulated in the Wave.

To summarize, Google Wave employs the following protocols:

• XMPP for server-server communication
• HTTP for client-server communication in the current Google implementation; XMPP is possible, as demonstrated by ProcessOne
• HTTP (JSON RPC) for robot server-Wave server communication in the current Google implementation
• Client-client protocol is not defined, as this mode of communication is most likely not usable in a Wave

I hope this post clarifies the protocols used in the current architecture of Google Wave for you. More importantly, I hope that it highlights just how much additional architectural definition needs to take place before Wave is ready for use by the masses. If I had a second chance to address Andy McAfee's question, I would unequivocally state that Google Wave is a "concept car" at this point in time.

Postscript: The heretofore mentioned possibilities around XMPP as a client-client protocol are truly revolutionary. The use of XMPP as the primary communication protocol for the Internet, instead of the currently used HTTP protocol, would create a next generation Internet in which centralized servers would no longer serve as intermediaries between users. Web application architectures, even business models, would be changed. See this post for a more detailed explanation of this vision, which requires each user to run a personal server on their computing device.

Business managers serving on WCM product-selection teams or attending technology conferences sometimes ask for definitions of "Web services" and "service-oriented architecture (SOA)." They say they are confused by their IT teams' usage of the terms as though they were synonymous, and that when the managers themselves use the terms interchangeably, they get corrected. Why does this happen?

Web services, a technology standard, and SOA, an architectural design methodology, are highly complementary. Yet they are distinct. "Web services" refers to technologies that allow enterprise applications of all kinds (WCM, CRM ERP, BI, etc.) to communicate with each other. Common forms of Web services include application programming interfaces (APIs), which are connectors written by software vendors that allow for a standard way of communicating with their applications. Vendors often publish or sell these APIs as a straightforward means of connecting. Another common - and more generic - example of a Web service is any message, often in XML format, exchanged between a client (a Web browser, for example) and a server (your bank's database) using the SOAP protocol. There are variations on these two themes, but the important concept to remember about Web services is that, simply put, they allow for a standard means of communication between software applications which may or may not rely upon transmission over the Web. Web services very frequently communicate only over corporate networks.

SOA, on the other hand, is not a technology. Rather, it is a way of designing connections between objects (application code components), applications, and other technology infrastructure. Like the frame of a building with respect to its windows and floors, SOA only defines the relationships between technology components, not their composition. SOA's goals are to achieve self-sufficiency for each component - i.e. that each component will perform one complete task or "service" - and for each component to offer its "service" to all of the others. It stands to reason then, that Web services and SOA often fit together well because SOA provides a framework within which discrete components can interact with each other, and Web services provide a standard way of building the components.

"Web 2.0" is a term that gets bandied about far too often with far too little associated meaning. Essentially, Web 2.0 refers to multi-directional interactivity between one or more humans and one or more Web applications (with their associated back-ends) -- period. The term often pops up in descriptions of any of the following: social computing, blogs, wikis, folksonomies, Web services, RSS feeds, online applications, collaboration, mash-ups and the Web as a platform. Don't let the diversity of topics given as examples of Web 2.0 distract you from the fact that the key operative term is multi-directional communication. What does this mean for WCM?

For the end user, it means that Web applications such as online banking, which now rely heavily on technologies like Flash and AJAX, provide better customer service by building-in higher levels of interactivity between the user and the data within a browser session and by encouraging more efficient communication between the browser and the host. Whereas before, every user request meant a round-trip to the server, now far more data is sent at once to the browser, often in the form of an object with which the browser can interact. The user then manipulates the data multiple times - transferring funds between accounts, paying a bill, and updating an address, for example - and upon logging out, transactions are sent to the server all at once for processing. Because technologies like Flash and AJAX provide for easier inclusion of rich media in the user interface, the combined effect of these Web 2.0 technologies is reduced development time for programmers, a more satisfying user experience for consumers, server processing efficiency for the host, and bandwidth savings for everyone. Another significant advantage of Web 2.0 technologies for WCM is the tendency to be so highly based on well-defined standards that functional components of Web applications are often interchangeable. When built on Web 2.0 technologies, the "address update" function in the Web banking example above would likely be usable by the bank's credit card Web application as well. This component swapability is the underlying principle behind enterprise mash-ups, a developer-oriented topic for an upcoming blog entry.

As consumer behavioral patterns across verticals (including retail, media and entertainment, and financial services) increasingly shift toward online channels, Web content must become increasingly monetizable. Factors which improve the monetizability of content relate primarily to rich user experiences, which require Web applications to combine behavioral analytics with the cross-platform, targeted delivery of digital media of all types (audio, video, streaming content, Flash, myriad image types), all available customer data, and content from Web services-based sources (maps, shipping information, weather reports, stock quotes, news). Not only must successful Web applications seamlessly wrap these components together behind the scenes, they must supply an interactive presentation layer that is aesthetically pleasing and easy-to-use. The primacy of the trend toward monetizable content will fuel other trends in the WCM space, among them, the heightened importance of:

* Design agencies as WCM solution providers. Vendors to watch: Blast Radius, Avenue A | Razorfish, Molecular.

* Analytics functionality within the WCM application to support multi-channel marketing campaigns. Vendors to watch: Interwoven, CrownPeak.

* The ability to incorporate rich media at the content creation stage. Vendors to watch: Adobe, ClearStory Systems, EMC/Documentum.

* Support for integrated search and advertising/merchandising. Vendors to watch: Endeca, FAST, Google.

* The emergence of WCM applications as primary brand managers. This is a channel strategy decision and is not vendor-oriented in nature.