Alex Barnett blog : SOA, enterprise2.0, webservices

Sync Google Calendar with Outlook and more with WideLens

alexbarnett — Thu, 06 Mar 2008 05:37:00 GMT

Google has just released a very cool utility (.exe download for Windows) providing users with the ability to synchronize their Google Calendar with Outlook.

Some nice features in their 0.9.3.0 release:

schedule the sync frequency: every x minutes
define directional flow: 2-way, and 1-way (either way)

A bit of a buzz going on about this...

Now, what if you could do the same over the web - no download, just use your browser (IE, FF, Safari)...? And not just Google Calendar <> Outlook, but others too...?

Well, it's certainly possible...First, watch this screencast I put together tonight (apologies for sound quality...done from home equipment):

About WideLens

A couple of weeks back Bungee Labs released a reference calendaring application, called WideLens, designed to show off some of the power of the Bungee Connect platform, from the kind of rich AJAX UI experiences delivered through to the high level of functionality developers can create by wiring up and integrating multiple web services and distributed web data sources into a single web app.

Video: WideLens User Experience
Video: Developer Overview

WideLens connects to Microsoft Exchange calendar, Google Calendar, Salesforce.com, Facebook, MySQL and iCalendar feeds, representing a variety of protocols and authentication schemes. MS Exchange is accessed through WebDav, Google Calendar through gData, Salesforce.com via SOAP, Facebook through REST and MySQL connectivity is based on client libraries provided by MySQL (integrated directly inside Bungee Connect).

WideLens is an uber-mashup.

WideLens connects to each of the sources in real-time, presenting the user with live data. With the exception of Facebook and iCalendar, users can create and modify events and those changes are immediately posted back to the source. MySQL pulls double duty, serving as both a WideLens native calendar source and as the persistence layer for all kinds of application data including user preferences and credential information for each service.

Developers: Have At it!

As mentioned above, WideLens has been released as a Bungee Connect reference application where we're encouraging Bungee Connect developers to customize the WideLens application as much as they want, deploy their own version of the app as their own app - to their own domain, at no charge, branded however they want and with whatever features / cuts / modifications / extended they want - the WideLens code is released under a BSD licence (read more here).

To get going with Bungee Connect and develop your own vision of what WideLens could do, sign up for your Bungee Connect account.

Mashup design patterns

alexbarnett — Tue, 22 May 2007 16:27:00 GMT

<warning: the following post meanders, is unstrucutured and doesn't arrive at any conclusion>

In the middle of last year, I invited Dion to meet with me and other members of Microsoft's Data Programmability team to discuss REST in the context of data access over the web. Dion's perspective is one of the reasons our team was able to recognise the potential of a RESTful programming model against relational data, manifested today as Project Astoria.

I've been waiting to read Dion's thoughts on Project Astoria (via John Musser). It's an interesting take, contextualizing Astoria within the overall architectural trends we're seeing take place.

I liked this diagram and got me thinking (dangerous...):

Dion warns that the diagram like this could never be complete representation of the concepts discussed in his post and is work in progress. The mapping done here for the 3 types of applications (Composite Applications, Recombinant Software and Mashups) makes some sense to me. However, it reminds me that I have used the terms "Composite applications" and "Mashups" interchangeably (but never Recombinant Software) depending on who I'm speaking to and without really thinking through what I mean by these terms. To try and clarify my own thinking on this, here's my effort to do so...

Here are the Wikipedia definitions of Composite Applications, Recombinant Software and Mashups.

Composite applications

"the term composite application expresses a perspective of software engineering that defines an application built by combining multiple services. A composite application consists of functionality drawn from several different sources within a service oriented architecture (SOA). The components may be individual web services, selected functions from within other applications, or entire systems whose outputs have been packaged as web services (often legacy systems)."
Recombinant software
<none>
Mashup
"A mashup is a website or application that combines content from more than one source into an integrated experience."

So nothing in Wikipedia for "Recombinant software", but in searching for a definition I did come another post by Dion written in June 2006 - "Is IBM making enterprise mashups respectable?". Here Dion asserted:

"Accepting that information, visuals, and software can be remixed and combined at multiple levels in an application stack means that there are (at least) five places that mashups can take place."

Dion then went on to define 5 mashup types:

Presentation Mashup: This is the shallowest form of mashup in the sense that underlying data and functionality don’t meet. Information and laout is retrieved and either remix or just placed next to each other. Many of the Ajax desktops today fall into this category and so do portals and other presentation mashup techniques.
Client-Side Data Mashup: A slight deeper form of mashup is the data mashup which takes information from remote Web services, feeds, or even just plain HTML and combines it with data from another source. New information that didn’t exist before can result such as when addresses are geocoded and display on a map to create a visualization that could exist without the underlying combination of data.
Client-Side Software Mashup: This is where code is integrated in the browser to result in a distinct new capability. While a component model for the browser is only now being hashed out as part of Open Ajax, there is considerable potential in being able to easily wire together pieces of browser-based software into brand new functionality.
Server-Side Software Mashup: Recombinant software is probably easier right now on the server since Web services can more easily use other Web services and there are less security restrictions and cross domain issues. As a result, server-side mashups like those that in turn use things like Amazon’s Mechanical Turk or any of the hundreds of open Web APIs currently available, are quite common.
Server-Side Data Mashup: Databases have been linking and connecting data for decades, and as such, they have relatively powerful mechanisms to join or mashup data under the covers, on the server-side. While it’s still harder to mashup up data across databases from different vendors, products like Microsoft SQL Server increasingly make it much easier to do. This points out that many applications we have today are early forms of mashups, despite the term. Of course, the more interesting and newer aspects of mashups happen above this level.

Back to the plot...

When speaking with an "enterprisey" architect I use the term "Composite applications". "Enterprisey" architects think and talk in terms of governance, security, scale and complexity. They also like to hear and use technical sounding terms that confound non-IT folks ;-)

When speaking with a developer, I tend to use the term "Mashups". Developers are smart and lazy - they want to write fewer lines of code, do more with less and love to impress. In my mind at least, the term "mashup" implies a speedy development / test / deploy cycle, design flexibility and simplicity in the sense that its "less hard to do".

Now, if I'm talking to a developer who works in the enterprise context (enterprise as in a large business) the term "enterprise mashup" can connect the "enterprisey" values - governance, security, scale but without the complexity AND with the "mashup" values - speed, flexibility and simplicity.

Reviewing the 5 mashup design patterns above, there is reasonably defined line: Client-side vs. Server-side. Some of the fall into the WOA space - referring to Dion's diagram above:

"Another important item: The bottom of the overlapping circle contains a cryptic acronym near the edge of the circle: WOA. This stands for Web-Oriented Architecture, a concept that I’ve written about several times here and here in this blog. It’s an idea that basically states that software that goes naturally with the “grain” of the Web, extending the core infrastructure of the Web in natural ways, works the best."

Announcing Bungee Connect

alexbarnett — Mon, 16 Apr 2007 07:11:00 GMT

At last, I can tell you more about what Bungee Labs has been up to...

We've just announced details about Bungee Connect, a 100% on-demand web development and deployment environment that will be going into Beta phase in May.

Over the next three days at the Web 2.0 Expo 2007 and on bungeeconnect.com we'll be providing a lot more detail on exactly what Bungee Connect is, how it works and why we think it will be a big deal when we go live.

So before I go on, let me quote a couple of people who have already seen Bungee Connect in action behind closed doors. The following are from tonight's two press releases (1 and 2)

First off, Dion Hinchcliffe:

“Ajax is just the beginning of the RIA story and Bungee Labs provides the rest of the solution with a web-based IDE, on-demand scalable deployment, a well-designed community model and a built-in component ecosystem with real-world licensing options,” said Dion Hinchcliffe, ZDNet blogger; President/CTO, Hinchcliffe & Co.; and editor in chief, AjaxWorld Magazine. “Bungee Connect is a surprisingly complete one-stop shop for the RIA development, deployment and operations lifecycle.”

Next, Dana Gardner:

“Given the current disjointed state of tools, testing and deployment models, most developers find creating rich internet applications (RIAs) to be complex, time-consuming and expensive,” said Dana Gardner, Principal Analyst, Interarbor Solutions. “By combining development, testing and deployment functions into an integrated, low-cost-of-entry service approach, Bungee Connect both broadens the numbers of developers that can produce web applications as well as slashes the barriers of entry for creating innovative ecommerce services and web-based businesses."

The Bungee Labs team has been working very closely with the Amazon team (and others API providers) the last few months to make sure Amazon's web services "just work" with Bungee Connect. Jeff Barr, Senior Evangelist for Amazon's Web Services:

“Bungee Labs’ decision to make their development environment integrate seamlessly with Amazon Web Services is great news for our developer community,” said Jeff Barr, Senior Evangelist for Amazon Web Services. “AWS developers can now use Bungee Connect to directly access our services, which means they can build Web-Scale applications in an easy to use, browser-based development environment.”

Another provider of web APIs, Salesforce.com has also been working closely with the Bungee Labs engineers. This time a quote from Adam Gross, Vice President, Developer Marketing, Salesforce.com:

“Salesforce.com has demonstrated that the innovation and ideas of the consumer Internet are at the core of the next generation of business applications. Bungee Connect together with Salesforce.com’s Apex platform makes it easier for developers to create mashups for their businesses, and in doing so hastens the transition from traditional enterprise software to the new on-demand model of building and deploying applications.”

So, what is Bungee Connect? Well, it's a lot of things:

Bungee Connect is a completely web-based integrated development environment (IDE) for building and deploying rich Ajax web applications, from simple web apps to seriously sophisticated Ajax applications. No install for developers, no installation of delivery infrastructure, and no client install for end users.
Bungee Connect is for developers, not for consumers. Yes, it provides a huge amount of automated support for the integration of SOAP and REST-based web services, Ajax app development and state management. You can develop sophisticated apps that integrate powerful (as well as simple) web services plus develop your own logic without having to write a line of code. It massivley reduces complexity. But, nonetheless, it is for developers, not consumers.
Bungee Connect provides a completely integrated means of deploying apps to the live web. No FTP. No separation between your dev, staging, production and live environment. No local set-up on your machine. No bits to install anywhere. No web servers, no app servers, no stacks, nor libraries to install, patch or manage. No 'Yak shaving'. It's all taken care of for you. You develop your app through the browser, then deploy your app through the browser and map the app to your domain / URL (or embed the app in your site) - It's your app. Oh, and you get IE, Firefox and Safari cross-browser compat taken care of too - you build your app once and it just works in these three browsers. Sweet.
Bungee Connect includes a whole code share and team collaboration concept. You can keep your code proprietary, or you can share it with other Bungee Connect developers in your workgroup or with the wider Bungee Connect developer community. There's a lot more to this than I can cover here and I'll be writing a lot more on this soon, but I like how Mat Asay described the community aspect as a 'Sourceforge for the 21st Century'.
Bungee Connect allows developers to leverage the world of web APIs. We've been working with the API engineering and evangelist teams at Amazon, Ebay, Google, Microsoft Windows Live, PayPal, RealNetworks, Salesforce.com and Yahoo! to ensure Bungee Connect works sweetly with the multitude of their rich APIs (both WS* and RESTful). The aim is to ensure Bungee Connect can work with any web service that you choose and by working with these teams and their APIs in developing Bungee Connect, we've got a great test-bed to make sure we can achieve this goal.
Bungee Connect is No Fee for the developer to use in developing and testing Bungee-powered apps. You only pay once you've deployed your app commercially or unrestricted. We expect this to be US$1 per computer-network-interaction-hour, billed monthly. Again, more on this later.

And there's so much more. Tomorrow, anyone attending Web 2.0 Expo will be able to get hands on with Bungee Connect. We've got a booth with PCs (Windows, Macs and Linux) with the browser open (IE, Firefox and Safari) where you run through some tutorials and judge for yourself if you think we're all smoking crack (see pics below - no crack, just the booths). We'll also be updating the site with screencasts and plenty more details and Martin will be presenting and demo'ing with Brad on Wednesday morning. And by then I'm sure David might have something more to say too...

To underline a couple of points here: we're not live yet. We go into Beta in May and are looking for web developers who ideally already have experience in progamming against the APIs of the companies I mentioned earlier. So sign up if that sounds like you...

---

Update:

Dana Gardner has written up his thoughts on Bungee Connect.
Short but sweet mention on Mashable.com by Pete Cashmore.

Update 2 (4/18/07)

Richard MacManus blogged it over at Read/Write Web
Ryan Stewart blogged us too :-)

7 Thoughts on the Business of API Throttling

alexbarnett — Fri, 06 Apr 2007 12:21:00 GMT

John Musser over at ProgrammableWeb.com has summarized the various ways (he's outlined 12) API providers can control access to their web services. As John says,

"There are good reasons for this ranging from preventing abuse, controlling costs, or other business-driven reasons."

John triggered a few thoughts for me with his post...Thinking out loud now...

7 Thoughts on the Business of API Throttling

1. Web APIs will be a key driver of future of the networked, services-based economy
2. The science of web API throttling is set to become a core business competency - not just a technical competency - for (hundreds of) thousands of businesses
3. Businesses need to learn about the business of API-based business models (an area where there is some experimentation and learning is going on today, but not enough)
4. Business expertise in designing and evolving API-based business models will be a highly valued skill / commodity
5. Standardized business models need to (and will) emerge regarding web APIs, similar to how there are standardized business contracts today
6. API throttling will become exponentially more complex to execute and operate
7. A significant number of small and medium-sized business (the long tail of today's economies) that want to thrive in the networked economy will need to make a decision in the near future: "do we spend large amounts of resources in the technical operation of API service delivery and throttling expertise in-house, or should we outsource this?"