Connections

July 2009

Sun Mon Tue Wed Thu Fri Sat
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

July 13, 2009

Gnip Continues To Push For A Real-Time (Data) Web

Another company to watch:

New Gnip Push API Service

The Gnip product offerings are growing today as we officially announce a new Push API Service that will help companies more quickly and effectively deliver data to their customers, partners and affiliates.  (See the TechCrunch article: Gnip Launches Push API To Create Real-Time Stream Of Business Data )

This new offering leverages the Gnip SaaS Integration Platform but is provided as a complete white-label and embeddable solution adding real-time push to an existing infrastructure.  The main capabilities include the following:

  • Push Endpoint Management: Easily register service endpoints and APIs to create alternative Push endpoints that are powered by the Gnip platform.
  • Real-time Data Delivery: Complete white-label approach allows for company defined URLs to be enhanced for real-time data delivery. Reduce your data latency and infrastructure costs while maintaining control of data access and offloading the delivery to Gnip
  • Reporting Dashboard: Access important metrics and usage information for service endpoints through a statistics API or a web-based dashboard

Gnip - Delivering the Web's Data » real-time

Gnip Now Offers Smarter Activity Feeds With PostRank

Full feeds of data are exciting, but sometimes you need a little something special.

Gnip, the Boulder, Colorado startup aiming to act as a clearinghouse for user activity updates from around the web, announced a partnership today with Canadian firm PostRank, to offer additional versions of Gnip-delivered data feeds, filtered by popularity. Gnip could already deliver anyone a big bucket of user data like photos from Flickr, submissions from Digg or slide shows from SlideShare - but now this partnership will allow customers the option of receiving only those items that were most commented on, linked-to, tweeted about, etc. It's wonky, but it's a whole lot of fun.

Popularity isn't a perfect substitute for quality, but it's not a bad place to start looking. Especially when inbound feeds are being displayed on a 3rd party's website automatically, the ability to crank up or down popularity criteria for inclusion in a feed can be really useful.

Gnip Now Offers Smarter Activity Feeds With PostRank

Gnip Launches Push API To Create Real-Time Stream Of Business Data

The Web is speeding up and Gnip wants to help push it along. Today, the API aggregation platform is releasing its own Push API which lets any site patch together its own version of Friendfeed or Twitter-like data stream. Gnip will be speaking at TechCrunch’s Real-Time Stream CrunchUp tomorrow on the Real-Time Business panel.

Gnip lets data-consuming services like Plaxo that take data from other services (like Twitter, Facebook Friendfeed, Digg, Delicious, etc.) collect data from requested users pushed to them. Data consumers using Gnip’s platform can get public data streams for over 30 social media networks and sites, including Twitter, Digg, Delicious, YouTube, WordPress, Flickr, Six Apart and others without ever visiting those sites or accessing their individual APIs.

The new push service lets companies filter and white-label the stream so the technology is fully integrated into the business’ infrastructure. Companies list out the most common data requests that are made on their APIs and websites and Gnip will collect the relevant data and deliver it in real-time to any approved third-party. For example, a travel website like Expedia or Kayak may use Gnip’s service to track and deliver real-time information on how customers are interacting with airline deals to the vendors that are listing flights on their site, like American Airlines or Delta. The real-time capabilities would let a travel site analyze real-time data and syndicate changes in fare sales immediately.

Gnip Launches Push API To Create Real-Time Stream Of Business Data

Opening Up And Speeding Up Feeds

Google announced an open-source effort to improve the real-time notification capabilities of feed syndication:

Real-Time Product Launch Recap - Digital Life Blog - InformationWeek

Pubsubhubbub - This one comes from Google (NSDQ: GOOG) and is very technical but the basic idea is any RSS feed using FeedBurner will now be updated nearly instantly whereas previously there was a delay in feed updating. It's built on the "pubsub" protocol and a variety of open-source clients have been created to allow applications that need feed data to receive it in a near real-time capacity. Google has created a wiki to discuss the Pubsubhubbub release.

Real-Time Product Launch Recap - Digital Life Blog - InformationWeek

Here’s the video from PubSubHub’s demo at the Real-Time event:

Speeding Up RSS

pubsubhubbub - Google Code

A simple, open, server-to-server web-hook-based pubsub (publish/subscribe) protocol as an extension to Atom.

Parties (servers) speaking the PubSubHubbub protocol can get near-instant notifications (via webhook callbacks) when a topic (Atom URL) they're interested in is updated.

The protocol in a nutshell is as follows:

  • An Atom URL (a "topic") declares its Hub server(s) in its Atom XML file, via <link rel="hub" ...>. The hub(s) can be run by the publisher of the Atom, or can be a community hub that anybody can use. (RssFeeds are also supported!)
  • A subscriber (a server that's interested in a topic), initially fetches the Atom URL as normal. If the Atom file declares its hubs, the subscriber can then avoid lame, repeated polling of the URL and can instead register with the feed's hub(s) and subscribe to updates.
  • The subscriber subscribes to the Topic URL from the Topic URL's declared Hub(s).
  • When the Publisher next updates the Topic URL, the publisher software pings the Hub(s) saying that there's an update.

The protocol is decentralized and free. No company is at the center of this controlling it. Anybody can run a hub, or anybody can ping (publish) or subscribe using open hubs.

To bootstrap this, we've provided an open source reference implementation of the hub (the hard part of the protocol) that runs on Google App Engine, and is open for anybody to use.

pubsubhubbub - Google Code

January 15, 2009

Enterprise RSS - RRW Readers Speak Out

A lot of great comments over at the main article: R.I.P Enterprise RSS. I thought a few deserved additional feedback:

#8. The consumption of Enterprise RSS feeds and the creation of the content in the feeds are both at fault here. There isn't enough 'good' information coming out of 'enterprise' RSS feeds and many people don't understand RSS (still).

When it comes to RSS readers, we've got to look at the enterprise itself and ask the following questions:

Does IT want users installing yet another software product?

Probably not. Microsoft Outlook is fairly standard in most large organizations. When people have to subscribe to internal / Enterprise RSS, IT staff will normally chose an existing application (Outlook) to read RSS.

Do users see the value in the RSS feed?

Many people still don't understand RSS. I've yet to run across an organization that puts really valuable information on an RSS Feed. If there is no valuable information on the feed, why subsribe? Hence...the reason Enterprise RSS is dying/dead.

Posted by: Eric Brown | January 12, 2009 4:47 PM

I strongly agree that those thinking about application design, information architecture, search, collaboration, portals, and so on need to think about feed syndication as another communication channel and user experience around feeds as the build and deploy systems. You cannot assume that people will interact with content only on the web site or within the application container. Good point.

Microsoft's implementation of RSS within Outlook is horrible. I tried it - tried to get rid of it - and suffered with it until I got a new machine with a new build of Office. The Outlook team should be embarrassed by the user experience and the quality of the feature. I like the light-weight feed reader within IE though - it is not designed for power users but it does what I expect it to do and no more. Also note: IE installs the Windows RSS Platform to help manage feeds. I thought the idea of a common subsytem for feeds was great but Microsoft missed an opportunity by not positioning the Windows RSS Platform as a universal tool for all desktop feed readers. And on the Outlook side, unfortunately, the Outlook team decided to build their own parallel subsystem so you end up with having to sync both clients - but, since there is no unified storage - all the feeds in IE and Outlook are stored twice (isn't that just wonderful)...

#10. I wonder whether you're conflating two issues here: enterprise use of RSS as a technology and enterprise workers use of third-party RSS readers.

To take the second point first, most enterprise workers aren't allowed to just go and install any old software on their PCs. This would account for the lack of presence of these readers. Also, reading RSS is likely viewed as not work related, and so its frowned upon within the enterprise (remember, those enterprise folks have "real" work to do, they don't get paid to read BoingBoing all day long).

I think the more pertinent point is, where is the use of RSS as a technology within the enterprise.

Obviously, outbound marketers are starting to use it to syndicate messaging via blogs and corp web sites. However, I suspect inbound use is beginning to pick up. My evidence for this is purely anecdotal, as I haven't worked in the enterprise for quite a while, however, for the past couple of years I've had tangential connections to Microsoft SharePoint projects. These are only just starting to roll out in the enterprise - It takes big companies forever to change how they do things (the proverbial business processes), but once an idea takes hold, change can happen quite quickly.

I think Microsoft SharePoint could be the killer app for RSS in the enterprise. SharePoint has RSS built in and uses it to syndicate changes that happen within the SharePoint ecosphere and notify enterprise workers that something significant has happened. Of course, SharePoint RSS could work with third-party RSS readers, but it's really designed to be used with Microsoft's Office Suite, where enterprise workers can interface with SharePoint, through RSS and other means, directly.

So, I wouldn't write off RSS in the enterprise just yet. But, you're more likely to see adoption if it's wrapped in guise of cool applications (like SharePoint) rather than cool technologies.

Posted by: Nigel Hall | January 12, 2009 4:50 PM

I do agree that Enterprise RSS is not a great label. RSS is a technology/protocol. And it confuses the architectural discussion when you want to talk about Atom, the protocol people should actually be focused on within the enterprise (along with Atom Pub). That said - SharePoint is just another application that has feeds. It is not a feed syndication platform. The SharePoint team made a really bad architectural choice in going with RSS and hopefully we will see Atom/Atom Pub  implemented in the next version. SharePoint does not manage feeds from other sources - it just makes its own information available via feeds just like ERP, CRM, ECM and other application systems. So SharePoint is one of many "killer apps" that could be exposing business insight via feeds. NewsGator is doing quite well with its SharePoint integration leaving Microsoft to focus on other more pressing things for SharePoint (perhaps improving its blog and wiki capabilities for a start...)

R.I.P. Enterprise RSS - ReadWriteWeb#comments

#35. I strongly second Rick's and Scott's view that people are talking too much about technology and products and not enough about real-world use cases. Simply stating how great RSS is and that it could be very useful won't get you much buy-in, not from management nor most importantly end-users. We need to make the technology relevant to the people, not the other way around. Understand users and use cases, then decide on technology!

In two of our projects with large law firms we included an RSS feedreader in the social software mix (among wiki, blogs, social bookmarking).
We introduced it primarily to Knowledge Management Lawyers (KML) that needed to gather a lot of content from various sources. They also use it to subscribe to updates from the wiki and blogs. They appreciate the fact that it is much easier to plow through a stream of updates rather than going from email to email and deleting every one of them. Some of the lawyers picked up that concept, too and started using an feedreader. Others wanted to consume their feeds on their BB or in their Inbox, which was catered for as well.
Have a look at two case studies: Dewey & LeBoeuf and Allen & Overy

In another project with a large law firm we took a very close look at the production (and consumption) of current awareness material. Current awareness included for example information on current developments within legal practices, latest court decisions etc. The firm made extensive use of newsletters to disseminate that kind of information. There was a multitude of newsletters available, some of them covering similar grounds. Maintaining email lists was very time-consuming and frustrating. Consumers did not know which newsletter were available. Also, newsletters were not personalised nor very timely, as they had a specific publishing date. We therefore recommended using RSS as delivery format, which would make the process of producing and consuming content more efficient and in the end more cost-effective as shown in a business case. This has been piloted but not been fully rolled out yet.

At E20 in Boston last year Attensa showcased another very interesting use case of RSS .

It's true RSS has not taken off yet, partially because people don't understand the different concept, but also because we have not fully explored its full potential yet.
Nevertheless, RSS does play a vital role in the 'Social Stack'enabling a free flow of information. Once CRM, DMS, Intranet and other proprietary system vendors thoroughly implement RSS functionality, it will get a big push. And with more and more information floating around via RSS we will need the likes of Newsgator, Attensa or GoogleReader.

Posted by: Christoph Schmaltz | January 13, 2009 12:17 AM

Another good point on the label re: Enterprise RSS. I would like to see something more easily understood by the average worker vs. a technologist.  But this comment makes a great point regarding applications. It is all about business applications. I don't see use of RSS to improve general productivity as the reason for large organizations to invest in this type of middleware. When I talk to financial services firms (perhaps the most aggressive adopter), they describe applications that support real business processes. Ditto for pharma firms I talk to on the subject. The callout in the comment of the Wallem application is great - I consider it one of the most compelling applications that have been publicly described.

Right now the smaller enterprise feed syndication platform vendors in this space are: Newsgator, Attensa and RSSbus. I am not a proponent of using consumer tools to access enterprise (intranet) feeds due to possible security and confidentiality reasons (e.g., Google Reader).

R.I.P. Enterprise RSS - ReadWriteWeb#comments

#68. I think this is mistaking (to use Gartners Hype Cycle) the "trough of disappointment" for the death of RSS.

Enterprise RSS vendors may of jumped to early in offering a product, however the fundamentals are starting to shape up:

* Major vendors in Microsoft and IBM are increasingly offering products that not only produce RSS feeds, but in the case of Lotus Connections, can only produce some information flows via RSS subscription (no e-mail production). No-one doubts the take of of Lotus Connections or Sharepoint, these products being adopted by Enterprises today will drive a need for Enterprise RSS tomorrow.

* Analysts often get over-excited about a technology and massively under-estimate the time to adoption for large Enterprises as mentioned by others in the comments. We are only now (I work in a large global professional services firm with over 160,000 staff) starting to see knowledge managers get their heads around what RSS has to offer and the first projects looking to run pilots are just kicking off.

* Enterprise Vendors (and Newsgator, KnowNow and Attensa aren't) are only starting to think about offerings in this space. IBM has internal product offerings they are looking to release, Microsoft has long been speculated to acquire NewsGator, I'm sure others are similar. When the Enterprise Vendors finish playing catch-up, the Enterprises will follow.

All we have now is that period where tidal waves suck all the water out to see before it comes crashing down over us.

Posted by: Tim Bull | January 14, 2009 4:09 PM

The idea that large vendors are solving this problem is fundamentally incorrect. IBM Lotus Connections is just another application with feeds, nothing more. There was talk at the Enterprise 2.0 conference that IBM would build its own version of NewsGator but they seem to be backing off  the claim they made publicly when debating Microsoft during a workshop I moderated).

Connections is not a feed syndication platform. Neither is SharePoint. Feed Syndication Platforms are a classic example of middleware - they aggregate feeds from many other sources, provide centralized management, enable control of network bandwidth, provide centralized policy control, help with de-duping feed items, help with synchronizing read/un-read marks across multiple feed readers a person might be using (mobile, browser, email etc).

It is true though that vendors jumped in early - smaller vendors typically react more quickly than large ones. Either Microsoft or IBM should acquire NewsGator. Oracle is a possible dark-horse - they could deliver something but have not disclosed an end-to-end system.

R.I.P. Enterprise RSS - ReadWriteWeb#comments

January 14, 2009

Ten Reasons Why "Enterprise RSS" Has Failed To Become Mainstream

The article below is interesting in that it does call out a dark truth - enterprise adoption of feed syndication tools has been lacking. However, the article disappoints because it gives too much credit to feed readers as the reason. I wish it was that easy. There are a host of reasons why Enterprise RSS has not taken off yet (vs. died).

The first concept to understand is that the key focus point for Enterprise RSS is not the reader - it's the feed syndication platform (the server back-end) that provides centralized administration, feed management and other services (e.g., synchronization of read/unread marks, de-duping of redundant feed items, etc). These platforms are not cheap - enterprise deals can average a six figure number. Sure - people may not want to pay for a feed reader when there are so many free ones available but that's really not the key blocking factor - just one of several. Here's a list of reasons I've come up with that categorize what I hear from enterprise clients in this area:

  1. A lot of intranets are "content poor" (why subscribe if there's nothing of interest)
  2. Intranet web site owners have not made their sites "RSS friendly"
  3. Employees may not know about feed readers and feed syndication (an awareness, education and training issue)
  4. IT organizations might not have rolled out any tools that focus on RSS
  5. In tools that support RSS as a feature, IT might not have "turned on" that capability (e.g., via administration/policy management settings)
  6. Employees may be unwilling to change their behaviors to take advantage of feed readers (if they have been rolled out)
  7. IT organizations may look at feeds as increasing their attack surface area in terms of security (e.g., malware)
  8. Business and IT decision-makers may be concerned about confidentiality and compliance aspects of feed syndication
  9. IT organizations may be concerned about network utilization and their inability to manage bandwidth concerns
  10. Justification for back-end servers to aggregate and management feeds centrally (i.e., a feed syndication platform) lacks a clear business case

This list is off the top of my head - I could go on...  (feeds might be used to deliver content to a site (corporate portal) without readers even being aware that the information they are viewing comes from a collection of back-end feeds - no large vendor has a feed syndication platform re: IBM, Microsoft or Oracle which might make some IT folks uneasy about relying on a small vendor for essential middleware).

Like many others, I am surprised/disappointed that this market has not hit its stride yet. I think it will take about two years before we see it unfortunately. This is a classic middleware chicken-and-egg problem. Right now, why should people deploy an expensive middleware layer when the ROI is not clear and the pain has not reached a critical mass?

That said, I have always felt that feed syndication platforms constitute the backbone for social software/Enterprise 2.0 tools. This space remains one of the most critical architectural areas for enterprise strategists - it touches on everything organizations are doing with blogs, wikis, tagging and social bookmarking systems, and social networking. Feed syndication platforms will likely play a supporting role when microblogging tools are introduced as well. These platforms can also help with syndicating information from operational systems (more data-centric). The emerging concept of activity streams (which I conceptually refer to as "social presence") will also benefit from such middleware. Kinda "way out", there's also an interesting potential touch point between feed syndication  platforms, analytics, alert/notification and complex event processing.

Bottom Line: It's not dead - it's still being born...

R.I.P. Enterprise RSS - ReadWriteWeb

It's with a heavy heart and a sense of bewilderment that we conclude that the market for enterprise-specific RSS readers appears to be dead. Two years ago there were three major players offering software that delivered information to the computers of business users via RSS. Today it looks to us like the demand simply never arose and that market is over.

A smattering of employees in big companies are using the free consumer app Google Reader, a paltry substitute for a business class RSS reader, and the rest of the business world is apparently satisfied to get information whenever they happen to stumble over it. It's insane - a solid RSS strategy can be a huge competitive advantage in any field. We have no idea why so relatively few people see that.

We love RSS and this makes us really sad. If much of the rest of the world wants to ignore this technology, though, it's their loss. It's our bread and butter. Neglecting RSS at work seems to us like pure insanity.

R.I.P. Enterprise RSS - ReadWriteWeb

Related articles:

Is Enterprise RSS Dead? (Agree but security is just one barrier but not the only (or even primary) reason why this space has not taken off.)

Enterprise RSS at NewsGator is Alive and Well (NewsGator is doing the best of the lot (vs. Attensa and KnowNow (gone under) but NewsGator has a consumer angle, a widget play, a community/social networking extension for SharePoint in addition to its feed syndication platform). I think it's hard to just talk about Enterprise RSS and NewsGator's success.

April 09, 2008

Atom + XBRL = Smart Move By The SEC

From Sam Ruby's blog:

The SEC started using RSS feeds two or three years ago to push information about XBRL filings received under the SEC's Voluntary Filing Program. See http://www.sec.gov/Archives/edgar/xbrlrss.xml

See the prior entry on this blog for a link to the iBlanket widget which makes use of one of the ATOM feeds.

You can go look at the Edgar system and see the ATOM feed here.  Look for the little orange icon, click on it.  You can read the feed in your browser, but the important thing to understand is that a computer application can read this also.

Basically, according to a IRWebReport blog entry, each filer to the SEC has its own ATOM feed which a user can subscribe to.  Imagine that the ATOM feed making you aware of information in an XBRL filing.  A computer application watches the ATOM feed, becomes aware of a new filing, reads the information from the XBRL filing, and updates your internal analysis models or other applications.  That is extremely powerful.

"The SEC, they totally get it." - Blog: Financial Reporting Using XBRL - XBRL as used for financial reporting by business users.

April 08, 2008

Atom Wins? Not Until The Fat Lady Sings

Some parts of Microsoft are adopting Atom/APP ... other groups remain somewhat vague and non-committal. It would be great for the SharePoint team to make a clear statement of direction on support for Atom and AtomPub. Given the growing deployment estimates of MOSS - which for some odd reason implemented only RSS - it seems that someone should commit to fixing an architectural "oops" .

But, put succinctly, Google + Microsoft = AtomPub wins. To paraphrase Dave Winer, the act of putting aside ego and saying a competitor's API is good enough, and that you're going to support it, is a brave and important act in the world of technology. That makes this convergence particularly exciting.

Anil Dash: Atom Wins: The Unified Cloud Database API

March 18, 2008

Building A Robust Feed Syndication Platform (Part 2)

Lawrence was kind enough to respond to my earlier post on the infrastructure NewsGator has put together to build out its feed syndication platform. I mentioned that I remain amazed at how poorly large vendors (e.g., IBM, Microsoft) are responding to this strategic middleware/infrastructure requirement that large enterprise customers will need as part of Web 2.0/Enterprise 2.0 efforts.

I stand by that statement.

Regarding Microsoft, I would refer people to this post where I summarize its efforts "Microsoft Announces FeedSync But Its Strategy Remains Un-Sync'd". It is true that Microsoft has implemented RSS support quite broadly throughout SharePoint. The important point business and IT decision makers is that the implementation is more application-like than infrastructure-like. Microsoft does little to nothing concerning the need to manage feeds from an end-to-end perspective (thus the partnership with NewsGator). Additionally, Microsoft needs to be much more clear on where it will be implementing Atom and AtomPub within SharePoint. The continued support only for RSS is architecturally a dead-end and reflects a poor upstream design decision.

Regarding IBM, they are almost as bad. There is no cohesive strategy coming from IBM concerning a feed syndication platform either. They do support RSS and Atom (in fact, IBM has been very aggressive with Atom/AtomPub and it is well implemented within Lotus Connections). But overall, its implementation of XML feeds across its product portfolio (e.g., Lotus Notes/Domino, Connections, Mashups) still does not meet the requirements of a feed syndication platform (as represented in the market by Attensa, KnowNow and NewsGator). There is some work being done that appears to be under-the-radar. At Lotusphere, IBM demonstrated a possible feed syndication platform in its Innovation Lab. There is also some interesting work being done by some IBM'ers around Abdera. Still, there is no clear product roadmap message from IBM regarding a feed syndication platform that could be deployed at the middleware layer. It also (like Microsoft), implements this capability as part of a product capability (which is more application-like than infrastructure-like).

Lawrence Liu
Senior Technical Product Manager for Community and Social Computing
Microsoft SharePoint Products and Technologies

We (the SharePoint team) understand feed syndication just fine, which is why we have RSS feeds for practically everything in SharePoint, and the feeds are easily configurable by the end user if necessary. SharePoint also has a built-in RSS Viewer web part to consume RSS feeds. As for feed aggregation, management, and sharing, we were hoping that the Exchange team would build that, but they had other priorities. NewsGator has been and will continue to be an excellent partner for us in this area.

Collaborative Thinking: Building A Robust Feed Syndication Platform

March 15, 2008

Building A Robust Feed Syndication Platform

Interesting case study of NewsGator's SaaS-based offering. While this type of scale may not be necessary within an enterprise per se - it does illustrate how such platforms should be approached as a core infrastructure decision. With only three enterprise-class vendors in this space (Attensa, KnowNow and NewsGator), I remain amazed at how poorly large vendors (e.g., IBM, Microsoft, Oracle) understand feed syndication and continue to treat it as an application decision. Stunning.

Solution Overview

http://www.newsgator.com

Customer Size: 65 employees

Organization Profile

Based in Denver, Colorado, NewsGator Technologies develops and markets solutions for the aggregation and viewing of Really Simple Syndication (RSS) feeds.

Business Situation

NewsGator needed to enhance the relational database infrastructure it uses to support 2.5 billion RSS articles totaling 4 terabytes, as part of its RSS aggregation and custom delivery solutions.

Solution

NewsGator is upgrading to Microsoft® SQL Server® 2008 Enterprise Edition (64-bit) database software running on the Windows Server® for 64-Bit Systems operating system.

Benefits

  • High availability with Database Mirroring
  • Reduced backup storage needs with Backup Compression
  • Better control with Resource Governor
  • Scalability
  • Easier data management

Hardware

  • Dell PowerEdge server computers with 4-way, 64-bit, dual-core processors and 32 GB of RAM

Software and Services
Microsoft SQL Server 2008
Windows Server 2008

Vertical Industries
IT Services

Country/Region
United States

Microsoft Case Studies: NewsGator

February 13, 2008

Info 2.0: Harnessing the power of Web 2.0 and Enterprise Mashups

Moderator:
Angelique Matheny, IBM Rational Software
Speakers:
Lauren Cooney, CTO Office, Information Management Group
Sriram Padmanabhan, Distinguished Engineer, IBM Advanced Tech. Group

Info 2.0 Webcast Notes (I assume that replay information will appear at the site):

The Good

  • Need to move way from rigid applications to a more free-flowing approach is correct (synergistic with emergence, user-generated content, architecture of participation and other trends re: Enterprise 2.0)
  • Also valuable to note that IT needs to create "safe sandboxes" for end users to create their own situational applications in ways that IT cannot predict or effectively support
  • Excellent point on need for a transformation layer when talking about data, feeds, user / business context etc.
  • Interesting idea on creation of specific data feeds (perhaps different than normal content-centric feeds) to help with mashup scenarios.

The Bad

  • No connection of Info 2.0 message with other messages coming from Lotus. Odd given Lotusphere was just a few weeks ago.
  • No product alignment or how this fits into the entire IBM portfolio (e.g., Quickr, Connections, etc).
  • Slides point out Google Gadgets but IBM announced at Lotusphere that they were heading down the Eclipse path with iWidget.
  • Mashup Hub is not a feed syndication platform (e.g., Attensa, NewsGator or KnowNow). The talking points made it sound like it was a real feed server and it's not really at that level of completeness, positioning what IBM is doing with managing feeds vs. other solutions in the market should have been made more clear.

And The Ugly

  • IBM demo'd some feed server technology within its Innovation Lab at Lotusphere that could evolve into a feed syndication platform but it seems like this nugget of gold remains undiscovered at the management level.
  • Which means IBM does not seem to strategically understand the importance and role of a feed syndication platform - given the need for enterprise organizations to have a cohesive middleware layer to manage feeds consistently - it remains astounding how major vendors continue to not have any clear direction or solution in this infrastructure area.

For Burton Group clients, we recently published a reference architecture template document on the architectural components of a feed syndication platform. A feed syndication platform:

  • Functions as both a communication channel and hub
  • Implements a publish-and-subscribe architecture that mediates consumers (e.g., applications that receive feeds) and providers of information delivered through feeds, often based on Extensible Markup Language (XML) (e.g., Really Simple Syndication [RSS] and Atom)
  • Contains a collection of functional components that expose services and interfaces, which enable those components to interact with other applications, infrastructure, and environments external to the feed syndication platform
  • Delivers feeds to destination points that exist on a variety of clients (e.g., PC, mobile), applications, and server platforms
  • Integrates with applications that facilitate delivery and interaction with feeds, such as e-mail, web browser, instant messaging, custom applications, virtual workspaces, and portal sites
  • Receives information from a variety of systems (e.g., enterprise content management systems, search engines, messaging platforms, and business applications) that it delivers as feeds
  • Honors policy sources (e.g., permissions, rights management, and compliance) as they relate to information sources, feeds, and feed items, and applies such policies across the feed syndication platform (e.g., subscriptions, storage, download, and user management)
  • Draws on related infrastructure platforms to complete the end-to-end system (e.g., directory, security, and integration services)

January 31, 2008

Jabber XCP Delivers Eventing via Pubsub

What will likely become a very critical component of "lifestreaming" that augments Atom/AtomPub (also a fundamental component):

Our developers are at it again, adding support to Jabber XCP for XEP-0163: Personal Eventing via Pubsub, which should be of interest to anyone following the evolution and use of presence technology. XEP-0163 lets users send updates about anything to users on their rosters. Personal eventing lets people easily publish things about themselves - it doesn’t get any more user-centric than this! The updates are sent using the XMPP Publish-Subscribe functionality used in Jabber XCP’s InfoBroker and described in XEP-0060. One way to look at it is that XEP-0163 takes XEP-0060 functionality to a more personal level.

...

The success of Twitter (which has XMPP in its architecture, BTW) and other similar services proves that personal eventing (in addition to presence, in general) is valued in social network settings. Service providers should be interested in the increased stickiness that personal eventing brings to their communities. Once users get used to seeing their friends’ moods, blog posts, activities, etc. they are more likely to stay in the communities which publish these details. The extension of social network technology to enterprise applications is in full swing, so by adding support for Personal Eventing via Pubsub to Jabber XCP, our extensible and highly scalable real-time presence and messaging platform will take the Power of Presence to a more personal and valuable level. The customers we’ve talked to about PEP have some great use cases and they will use this new functionality in their deployments. How about you?

Jabber Filaments Blog » Blog Archive » Jabber XCP Presence Platform Gets Personal (Eventing via Pubsub)