Blogging Roller

re: RDF and OpenSocial

Dave Johnson — Fri, 3 Dec 2010 08:22:48 +0000

This is the closest thing to a blog post that I've written lately, a post to the OpenSocial specification group on aligning OpenSocial with RDF and Linked Data:

This is a topic of interest to me, so I'll try to elaborate.
First, I want to point out that RDF is not a representation, it's a way to model data and it's multiple ways to represent that data (in XML, JSON, etc.). I think the real question is: how do we enable OpenSocial to hook into the RDF-based web of "Linked Data" that is rapidly growing up around scientific data, government open data and the academic world. I'm not going to go into the benefits of Linked Data in this post, but I will disclose that I work for a company that uses RDF as a common data model to enable loosely coupled integration across our web application products (see also Jazz Integration Architecture [1] and OSLC [2]). We'd like to be able to integrate with OpenSocial services in the same ways.

I'll explain the basics of RDF. RDF is way to model web data and ways to represent that data in XML, JSON, Turtle, etc. The RDF data model is simple, we have resources identified by URIs and property values associated with those resources. Resources can have types, each type is identified by a URI. Property types have URIs too. Once you have defined your data model in terms of RDF types and properties, you can represent resources and their properties using RDF representations. There's RDF/XML for XML, there's RDFa for embedding properties in HTML. There's are JSON representations too, but not a standard for JSON yet.

So, to bring OpenSocial in-line with the world of Linked Data, we would define each class of OpenSocial objects as an RDF type, with a URI. We would define each OpenSocial property as an RDF property, with a URI. In some cases, we'll want to use existing properties, like the Dublin Core title, name, etc., and in some cases we'll want to define entirely new types and properties.

As a starting point, I think we would do the following:

* In OpenSocial v2, we would define all OpenSocial objects and properties as RDF types in the OpenSocial Specs. This means simply assigning a URI to every class and every property we define, using standard properties where appropriate and defining new ones as needed. Object and property names would rename the same and we'd have what is essentially an RDF mapping built into the spec. Existing OpenSocial representation formats would stay the same, but we'd add some new RDF representations.

* We'd introduce an optional new OpenSocial spec that services MAY implement: the OpenSocial RDF Specification. The specification would simply require that a service provide RDF representations of it's resources via content-negotiation. The service could offer RDF/XML or HTML with RDFa, JSON/RDF or all of the above.

That's a starting point and I think we could come up with some other ideas if we thought more about use cases. Anybody else interested in aligning the worlds of OpenSocial and Linked Data?

Link: RDF and OpenSocial

OpenSocial State of the Union 2010

Dave Johnson — Mon, 24 May 2010 22:19:34 +0000

Here's summary of last week's OpenSocial State of the Union, including news of two new board members: Cody Simms from Yahoo and Jason Gary from IBM:

Mark Weitzel (on behalf of the OpenSocial Foundation): The event started off with introductions of the Foundation Board members and officers. Cody Simms is Yahoo!’s corporate designate. IBM is a new corporate member and has designated Jason Gary as their representatives. Welcome Cody and Jason. The complete list of your Foundation Officers and Board Members is in the FAQs.
In addition to new corporate members of the OpenSocial Foundation Board, there are two community seats available. Anyone is able to serve on the board. The only requirement to nominate or hold the position is that you must be a member of the OpenSocial Foundation. There are no membership fees to join OpenSocial. All you need to do is fill out a simple on-line membership application.

It’s been an exciting year and a half for OpenSocial! We’ve seen continued adoption of the specification as new containers come on line. Perhaps what is more interesting is that we are starting to see OpenSocial adoption outside of “traditional” social networks. This includes adoption by enterprise vendors such as Jive, Atlassian, and IBM.

IBM talking OpenSocial at Google I/O

Dave Johnson — Wed, 12 May 2010 11:52:04 +0000

IBM is going to be at Google I/O again this year, talking about OpenSocial and giving demos of new OpenSocial features in IBM products. Randy Hudson of IBM/Rational will be there to show how OpenSocial Gadgets can be used in Jazz-based product dashboards (introduced in Jazz Foundation 3.0 Milestone 5).

And IBM's Mark Weitzel, who happens to be an officer of the OpenSocial Foundation, will participate in panel discussion on Best practices for implementing OpenSocial in the Enterprise.

Best practices for implementing OpenSocial in the Enterprise
Social Web, Enterprise - Mark Weitzel, Matt Tucker, Mark Halvorson, Helen Chen, Chris Schalk

Enterprise deployments of OpenSocial technologies brings an additional set of considerations that may not be apparent in a traditional social network implementation. In this session, several enterprise vendors will demonstrate how they've been working together to address these issues in a collection of "Best Practices". This session will also provide a review of existing challenges for enterprise implementations of OpenSocial.

Session type: 201
Attendee requirements: General understanding of OpenSocial technologies. Some Enterprise experience is also recommended.
Tags: OpenSocial, Enterprise
Hashtag: #socialweb7

Date: Thursday May 20
Time: 1:00pm-2:00pm
Room: 9

The Enterprise OpenSocial white paper

Dave Johnson — Tue, 5 Jan 2010 19:16:46 +0000

Here's another thing I've been involved with at IBM: the Enterprise OpenSocial white paper which was published just before Christmas 2009.

The paper is a group effort, written by folks from Alfresco, Atlassian, Cisco, Cubetree, Google, IBM, SAP and SocialText. It explains why OpenSocial is relevant and "ready for both Internet scale web communities and enterprise applications." It also lays out some specific areas for improvement in OpenSocial that will make the technology an even better fit in the enterprise. Here's the opening paragraph to get you started:

Enterprises are collections of people, and thus inherently social. Employees of any organization benefit from social connections, group affiliations and relationships both within their own business and between other businesses. As a result, social networking capabilities have become increasingly popular in business-to-consumer, business-to-business, and internal enterprise collaboration applications. New technologies and standards such as Web 2.0 and OpenSocial [1] are helping software providers better model relationships between people, allowing end-users to benefit from such relationships in day-to-day business processes within their own enterprise, and across business networks.

Read the rest of the Enterprise OpenSocial white paper at OpenSocial.org.

IBM at last month's Enterprise 2.0 OpenSocial panel

Dave Johnson — Mon, 14 Dec 2009 13:32:02 +0000

It's been over a month since the Enterprise 2.0 OpenSocial panel and since we were never able to get a group blog post together, I've decided to publish a short summary of what I said about IBM on the panel. I'm paraphrasing myself from memory so this is not exactly what I said but it should be pretty close:

IBM has been successfully innovating in the area of browser-based components, also known as widgets or gadgets, and social APIs for years now. If you haven't seen the IBM Mashup Center you should visit the IBM booth and take a look at the demo. It allows you to create Web 2.0 style mashup applications by dragging-and-dropping widgets into place and wiring them together. You've probably heard of Lotus Connections. Connections is IBM's social software suite and it includes blogs, wikis, forums, social bookmarking and more. Each one of those components features a comprehensive AtomPub-based REST API.

We're working with the OpenSocial community to ensure that the specification meets the needs of our customers and is able to interoperate with our existing iWidget technology (and I think I mentioned the OpenAjax Hub here too). You can see most of the improvements that we're interested in the slides, so I won't go into detail now, but I will mention a couple of things for example: we would like to see better inter-gadget communication, specification modularity (coming in OpenSocial 1.0) and a stable and predictable specification change process.

I work for Rational, the part of IBM that creates tools for software development and delivery, something that is also social and collaborative in nature. We're enthusiastic about OpenSocial and we hope to enable use of OpenSocial Gadgets in Jazz-based product dashboards sometime in 2010. We may also support some of the OpenSocial Social APIs, but we are still learning and experimenting. Jazz products are developed in an open and transparent way so you can track our progress via our wiki and work-items at Jazz.net.

I won't try to paraphrase what the other panelists said, I'll let them do that, and I'll leave out my SocialSite pitch for now as most of my readers have already heard it. I'll put together an update on SocialSite during the next month and I think I'll have some good news to report.

Trip report: ApacheCon US 2009

Dave Johnson — Sun, 15 Nov 2009 10:59:18 +0000

(Last week, I returned after a week of vacation and a week of conferences in the SF bay area. Instead of posting my trip reports to the limited audience that reads my internal IBM blog, I'm going to post them here so that everybody can benefit from them.)

Here's my report from ApacheCon US, focusing on the projects I'm involved with: Roller, Shindig and SocialSite.

Roller session#

In my session, I covered the new features in 5.0, Roller history and sort of a Roller state of the union. I explained that nobody is working full-time on Roller these days, it's an all volunteer effort with about three people active and if folks want us to keep on making official Apache releases then those very same folks had better step-up and get involved so we can knight some new PMC members. I also did a demo of the new features in Roller 5.0 including OpenID and the file upload and management improvements.

What's new in Apache Roller 5.0, Dave Johnson
http://www.us.apachecon.com/c/acus2009/sessions/280
Announcement: Roller 5.0 beta 1 available
http://markmail.org/message/rwk6pj4voxbyuaj3

Shindig session#

After my Roller talk and in the same room, I attended Paul Lindner's talk on Apache Shindig. Paul has worked on OpenSocial implementations at Hi5 and LinkedIn and he's also a committer on the Apache Shindig project.

Empowering the Social Web with Apache Shindig, Paul Linder
http://www.us.apachecon.com/c/acus2009/sessions/281

I'm familiar with Shindig so this was mostly review for me. I liked Paul's assessment of Shindig quality, saying that they have good processes in place, use code reviews and have good test coverage. Paul acknowledged problems with Shindig's developer friendly-ness and said that the community is working to fix them. I've heard similar complaints from multiple source and seen myself that it's not as easy as it should be to understand the codebase, figure out how to plug-into it and understand which parts are really required for OpenSocial and which are just sample code.

Paul also talked about the Open Stack concept, a set of open standards that enable social networking interoperation including OpenSocial, ~OAuth, OpenID and portable contacts. He said that Shindig is the best way to implement the stack and keep up with the evolving standards. He had a nice quote about "Shindig is to OpenSocial as Apache HTTPD is to HTTP"

Social Widgets / Gadgets meetup#

On Thursday night, I attended Social Widgets / Gadgets meetup which brought together members of the Apache Shindig, Apache SocialSite and Apache Wookie Communities.

Apache Shinding: OpenSocial Reference Implementation
http://incubator.apache.org/shindig
Apache SocialSite: Headless Social Networking server plus Gadgets
https://socialsite.dev.java.net/
Apache Wookie: W3C Widgets, OpenSocial and Wave Gadgets server
http://incubator.apache.org/wookie

There were about 25 people there including folks from Google, Atlassian, Yahoo, Ning, LinkedIn, Hippo (CMS/portals ISV) and, I'm guessing, a bunch of SF bay area startups. The meetup started around 8PM and lasted over two hours.

I presented a lightning talk on Apache SocialSite using a couple of slides from the JavaOne talk and including a quick status report. Status is this: still waiting on Sun to come through on code grant, Globant is having some success with SocialSite in production and work is almost complete in converting the build over to Maven. I also did a quick talk about the Enterprise 2.0 OpenSocial panel, which occurred the day before.

SocialSite Mavenized
http://code.google.com/p/socialsite-mavenized

Next, Jas Nagra did a very entertaining and informative mini-presentation on Caja, complete with XMen 2 references. Caja is a way to run Javascript code (e.g. gadgets) loaded from different locations, each in its own secure sandbox where it can't interfere with others and can't do evil -- but without relying on iframes. Shindig uses Caja, but it's optional and off by default.

Google Caja - A source-to-source translator for securing Javascript-based web content
http://code.google.com/p/google-caja/

After that Paul Linder did a quick talk on the Open Stack idea and revised his Shindig quote to "Shindig is to the Open Stack as Apache HTTPD is to HTTP." Then we broke up and folks stuck around to talk about APIs, projects, possibilities and everything else for quite some time.

That's all I've got for now. I hope to document some of my experiences on the "Enterprise OpenSocial" panel at Enterprise 2.0 later, possibly in a blog post on the OpenSocial blog.

Trip report: Social Web Camp, Santa Clara, CA

Dave Johnson — Mon, 9 Nov 2009 10:07:19 +0000

(I just returned to work after vacation and a week of conferences in the SF bay area. Instead of posting my trip reports to the limited audience that reads my internal IBM blog, I'm going to post them here so that everybody can benefit from them.)

On Monday Nov. 2, I attended Social Web Camp at Sun's Santa Clara campus. There were about 40 people in attendance. The event was organized by Sun's Henry Story, an expert in semantic web technologies and inventor of the FOAF+SSL approach to implementing Social Networking features (relationship based privacy). Unfortunately, Henry was not able to attend the conference because he was detained by US immigration.

Social Web Camp, Santa Clara, CA
http://barcamp.org/SocialWebCamp-Santa-Clara
Sun's Santa Clara Campus - AKA the Agnews Insane Asylum
http://www.nps.gov/nr/travel/santaclara/agn.htm
FOAF+SSL distributed/open social networking
http://esw.w3.org/topic/foaf+ssl
Henry detained for 6 days, case dismissed in 30 seconds
http://twitter.com/bblfish/status/5509198135

During the camp, I lead a session on OpenSocial using my "What's up with OpenSocial" slides from BarCampRDU. Surprisingly, very few people were familiar with OpenSocial, so this was an introductory level discussion.

What's up with OpenSocial preso from BarCampRDU
http://docs.google.com/present/edit?id=0AWuMBlP1tnN6ZGcyY2ZuendfOThmcXMydjdmcQ&hl=en

I participated in a session on enterprise social networking and shared a little about we do with micro-blogging inside IBM, mentioning BlueTwit and the new features in Lotus Connections. A couple of folks from Boeing were present and described the home-grown social networking and micro-blogging system.

BlueTwit mentioned in Business Week
http://www.businessweek.com/magazine/content/08_22/b4086056643442.htm

John Panzer of Google pitched his new Salmon protocol, a distributed commenting system that allows comments made on items in downstream systems (e.g. aggregators, social networks, FriendFeed, etc.) to find their way back upstream to the source item. The protocol is based, in part, on AtomPub. Comments are signed and posted back upstream. Seems like this could be useful in both Lotus Connections river of news feature, Jazz-based products and Roller; so I'll going to track this one closely. It might be fun to try to implement Salmon for Roller.

Salmon: comments and annotations to swim upstream, spawn more commentary
http://www.salmon-protocol.org/

I missed a little of the conference because I had lunch with some of my former co-worker from Sun and I left a little early to return my vacation rental car and make my way to Oakland for ApacheCon US 2009. More about that later...

Latest Links: August 11, 2009

Dave Johnson — Tue, 11 Aug 2009 21:12:00 +0000

Your blog still loves you
"it's time to use the web again to store our ideas, and instead of relying on Silicon Valley companies to link our stuff together, let's just use the Internet."
ZDNet Asia: 'Ferociously loyal' users to stand by Sun
"47,000 enterprise customers and a ferociously loyal customer base"
The Connections Blog: Full house! Lotus Connections 2.5 video demos
screen-casts for 8 of the Lotus Connections components
Chromium Blog: Google Chrome Developer Tools for Eclipse Users
"Set breakpoints, inspect variables and evaluate expressions from within Eclipse"
First impressions of Google Wave | Enterprise Web 2.0 | ZDNet.com
"won't be ejecting existing enterprise collab tools from the workplace any time soon"
Shindig-based OpenSocial Container from Lockheed Martin
"written in Java and is based on open source projects such as GWT, Hibernate..."

ApacheConUS 2009 registration open, sign up now!

Dave Johnson — Tue, 11 Aug 2009 20:09:21 +0000

The early-bird special ends on August 14, so you'd better get moving.

Sign up for ApacheCon US by 14 August and save up to $500!

This year's ApacheCon US promises to deliver our most extensive program to date, and largest anticipated gathering of the global Apache community to celebrate the ASF's milestone 10th Anniversary. The San Francisco Bay Area is where the very first ASF official user conference was held, and we hope that you will join us in celebrating the ASF's success!

Apache members, code contributors, users, developers, system administrators, business managers, service providers, and vendors will convene 2-6 November in Oakland, California, for a week of training, presentations, sharing and hacking. ApacheCon US 2009 features new content tracks, MeetUps, and GetTogethers, as well as a number of events open to the public free of charge, such as the Hackathon and 2-day BarCampApache, in appreciation of their support over the past decade.

Be sure to register by 14 August to save up to $500! To sign up, visit http://www.us.apachecon.com

I'll be there and speaking on the topic of What's New in Roller 5.0. I also plan to attend the Social and Widgets Meetup with folks from Shindig, SocialSite and Wookie. I hope to see you there.

Latest Links: OpenSocial and OSLC

Dave Johnson — Tue, 9 Jun 2009 16:00:03 +0000

Stutzman on WUNC's the State of Things
Stutzman and others on the etiquette, the addiction and the future of Facebook
Is Twitter Really That Big?
40% of Twitter users haven't tweeted since 1st day, 25% not following anybody
YouTube - Towards Privacy-aware OpenSocial Applications
Talk by Kun Liu of IBM Research on privacy scoring and applications

Google I/O video - Atlassian and OpenSocial
using OpenSocial to connect enterprise apps and power developer dashboards.
Atlassian - OpenSocial Videos
Atlassian has gone ga ga for Gadgets

YouTube - What is New in Rational Team Concert 2.0 Web UI
from Dejan Glozic, Team Concert Web UI and Dashboards Lead
Mainsoft Document Collaboration for Rational Jazz
connects Rational Team Concert to your corporate collaboration infrastructure.

The Open Services for Lifecycle Collaboration (OSLC) initiative
creating open interfaces for software development services: requirements, change requests, user stores, test cases and more.
dW podcasts: Abrams, Zetie and Kerston on OSLC
Interview with some of the folks behind OSLC.

SocialSite@Apache

Dave Johnson — Thu, 23 Apr 2009 23:00:49 +0000

I took a break from blogging during my first couple of weeks at IBM. My blog broke and it took me a while to find the time and motivation to fix it, but now it's time to return. I think. I have been doing some internal blogging at IBM, but so far it's been mostly boring stuff: status reports and the like.

What I want to talk about today is Project SocialSite. Since my last post, where I mentioned that Sun is willing to contribute SocialSite to Apache, I did some work to move things along. I wrote an Apache Incubator proposal, started a discussion and this week calling for a vote on the proposal. Here are the relevant links:

Proposal: Apache SocialSite

Discussion and vote thread on the Incubator General mailing list

Subscripton info for the Incubator mailing lists

If you want to support the project, and especially if you're on the Incubator's Project Management Committee, now's the time to do so.

The future of Project SocialSite: Apache?

Dave Johnson — Fri, 27 Mar 2009 13:17:27 +0000

Since January, the future of https://socialsite.dev.java.net">Project SocialSite has been in the hands of the SocialSite community. During that time, I continued working on the project almost because I think it's got great potential and I would really like to see it live on in some form. That's also why I continued to talk to Sun about the project.

Today, I'm very happy to announce that Sun Microsystems is willing to contribute Project SocialSite to the Apache Software Foundation. It's not clear whether SocialSite should be contributed into Shindig or as a new incubator project, but either way I think this is the best thing for the project and will give it the best possible chances for building a thriving community. I've started some discussions about this on Apache-private mailing lists and I'll let you know what happens next.

This post brings to an end my series of posts about Shindig for blogs and wikis. Here are links to the earlier posts:

By the way, I delivered my Shindig talk just a couple of minutes ago. It was well-attended and I think it went pretty well. You can find the slides online at the ApacheCon EU 2009 site here: http://www.eu.apachecon.com/c/aceu2009/sessions/184">Shindig for Blogs and Wikis. Now back to your regularly scheduled programming...

OAuth everywhere (continued)

Dave Johnson — Thu, 26 Mar 2009 02:00:00 +0000

In my earlier OAuth everywhere post I explained at a high level "how I got a Roller Gadget working, one that uses OAuth to call Roller and enables Roller to use OAuth to call back to the social network." I ended with some unanswered questions:

How do I add my gadget to SocialSite so users can install and use it?
How does SocialSite get the Consumer Key and Secret needed for calling Roller?
How does Roller get the Consumer Key and Secret needed for calling SocialSite?
How does the user authorize Roller's access to his Profile information in SocialSite?
When is OAuth support coming to the Roller trunk and can you use it for AtomPub?

(that last question was answered in OAuth for AtomPub in Roller earlier this week)

Now that I've wrapped up my work on OAuth in SocialSite and OAuth in Roller, I'm prepared to answer those questions. I'll do it by reviewing how I developed my Social Roller gadget and set it up to work on http://rollerweblogger.org, my Roller and SocialSite powered site.

Along the way, I'll provide links to source code and screen-shots. I'll be referring to the diagram from first post, so I'll reproduce it here for the sake of convenience:

NOTE: this post is based on the current code in the Project SocialSite SVN trunk. The things described below WILL NOT work with the SocialSite M3 release.

Step 1 - Develop an OpenSocial Application#

My first step was to develop an OpenSocial application for Roller. This application is made up of the three parts listed below. These are the parts show in light-blue in the diagram above.

An OpenSocial Gadget for Roller that a user can install into his SocialSite profile. An OpenSocial Gadget is defined by Gadget Specification, an XML file with the metadata, HTML, CSS and JavaScript that render the gadget's user interface. I developed my gadget as a Roller page template and you can view it's source code here: gadget.xml
A gadget setup page, a new JSP page in Roller that is called by the gadget to enable and disable Activity posting. This JSP page is protected by OAuth and returns data in JSON format to the gadget. View the source code here setupgadget.jsp
A Roller Task that runs periodically, checks to see if any gadget users have created new blog posts and if they have, posts a Activity to SocialSite for each, by calling the OAuth-protected OpenSocial REST API provided by SocialSite. View the source code here SocialRollerTask.java

Step 2 - Register gadget with SocialSite#

This section answers the question "How do I add my gadget to SocialSite so users can install and use it?"

My next step was to register my application. Remember that SocialSite is intended to add social features to existing web sites and has very little user interface of its own, it's mostly made up of gadgets. So, the way you register a new application on a SocialSite-enabled site is to sign-up as a user of that site, go to your profile page, install the SocialSite Developer Gadget and then use that gadget to register your new application.

You can see a screenshot of the SocialSite Developer Gadget below. In the simplest case, you just enter the URL of your Gadget Specification, but I needed to take a couple of extra steps because my gadget needs to call an OAuth protected resource in Roller.

This next paragraph answers the question "How does SocialSite get the Consumer Key and Secret needed for calling Roller?"

I need my gadget to call back to the Roller setupgadget.jsp page (that's part #4 in the diagram above) to enable/disable activity posting. Because that page is protected by OAuth, I had to go into Roller and get Roller's site-wide OAuth key and secret (see also: OAuth for Roller) and then enter those it the Developer Gadget. SocialSite stores them and will use them to take care of the OAuth authentication process on each gadget call to Roller (in part #2 above).

Step 3 - Approve gadget registration#

Since I'm the administrator of my site, I approved my own gadget registration. I did this by logging into my site's SocialSite admin console, went to the Gadget Management tab, saw my new gadget registration request and approved it. Here's a screenshot of the Gadget Registration approval page:

Step 4 - Add OAuth consumer key and secret to Roller#

This next paragraph answers the question "How does Roller get the Consumer Key and Secret needed for calling SocialSite?"

After your gadget is approved for use on a SocialSite enabled site, you'll find the consumer key and secret that Roller needs to call the OpenSocial REST API (that's step #6 above) in the SocialSite Developer Gadget. Here's what you see in the Developer Gadget once you gadget is approved.

My OpenSocial Roller application needs to know about those keys, so I put them in its configuration. For simplicity's sake, I'm not going to go into the details of this step.

Step 5 - install the Social Roller gadget#

Finally, the OpenSocial Roller application is ready for use. To install it, I went to my profile page, clicked the Gadget Directory button, browsed through the gadgets until I found it and then clicked the install button. Here's a screenshot of the SocialSite Gadget Directory, which you can access from the SocialSite Profile Gadget:

The Social Roller Gadget is the last item in the list, the "Simple Roller Gadget."

Step 6 - authorize and enable the Social Roller gadget#

After I installed the gadget, it appeared in my Profile page as you can see in the screenshot below. It's installed and ready to run, but it's not yet authorized to access my Roller account so it tells me "Before you can use this gadget, you must authorize it to access your Roller account."

Finally, I can answer the question "How does the user authorize Roller's access to his Profile information in SocialSite?"

I want the gadget to access my Roller account so I clicked on the authorize link and saw this page popup, directly from Roller, which asks me to take the final step to authorize access.

After I clicked the authorize button, page disappeared and the Social Roller gadget redisplayed itself as you can see in the screenshot below. The gadget is now ready to access my Roller account and is asking me to enable activity posting:

I clicked the enable posting button and saw this:

And now, whenever I post a new blog entry, an activity is added to my profile. Here's proof in the form of a screenshot:

Conclusion#

I've done the work to enable OAuth in SocialSite and Roller, so now it's possible to develop OpenSocial gadgets for Roller that will work with SocialSite and other OpenSocial containers. The Roller side of this work is now available in Apache Roller (in the SVN trunk), but the future of the SocialSite is still uncertain.

I think SocialSite still has great potential. That's why I'm spending so much time promoting it and moving it forward, but I can't do it all myself. I'm joining IBM next week and as far as I know, SocialSite will NOT be part of my job. I'll wrap up this series of posts tomorrow with a post discussing the future of Project SocialSite.

Socialsite on rollerweblogger.org

Dave Johnson — Wed, 25 Mar 2009 23:59:59 +0000

The value of Project SocialSite is that it allows you to add social networking features, including the ability to run OpenSocial gadgets, to existing web sites and have those sites all using the same "social graph" of data about people and relationships. To demonstrate this, I've deployed SocialSite to my site, http://rollerweblogger.org, and finally implemented those things I described in my August 2008 Social Roller post (except for protected entries).

My site includes a blog and a wiki, Roller and JSPWiki, so it's a pretty good candidate for demonstrating how SocialSite can work with multiple existing webapps. It's not perfect because it's got a very small number of users, less than a dozen, and because it's private; you have to login to see the social features, but it'll have to do. In this post, I'll explain the steps you have to take to add SocialSite to a multi-application web site and I'll illustrate the steps with examples, links to source code and screenshots from my work on this site.

NOTE: this post is based on the current code in the Project SocialSite SVN trunk. The things described below may or may not work with the SocialSite M3 release.

Step 1 - Setup an Authentication Delegate page in your site#

SocialSite doesn't do any user management, it leaves that to the sites that it enables. In my case, I've got Roller and JSPWiki setup to authenticate against the same database table of usernames and passwords, and I've got Tomcat's simple SSO setup so that logins work across both webapps. I want SocialSite to depend on Roller to verify that users are logged. SocialSite's Authentication Delegation mechanism makes this possible.

Here's how SocialSite Authentication works. You add a delegate page, a dynamic page (JSP, PHP, etc.) to the webapp that is to do the authentication, configure SocialSite to trust that webapp and then at runtime, SocialSite will call that delegate page to verify user logins. In my case, I want Roller to do the authentication so I added a delegate page to Roller called socialsite_context.jsp.

When a SocialSite gadget running inside of Roller needs to call back to the OpenSocial API provided by SocialSite it will pass Roller's login cookie with the call, an assertion about who the logged-in user is and the URL of Roller's authentication delegate page (socialsite_context.jsp). SocialSite will then call that delegate, pass the cookie and verify that assertion. SocialSite expects the delegate to return some JSON data like this:

Example: JSON data from socialsite_context.jsp


  {
    'timeout': 30,
    'assertions': {
      'containerId': 'rollerweblogger.org',
        'viewer': davej,
        'owner': davej,
      }
    }
  }

In the above example, Roller is confirming the assertion that the user is 'davej' and the owner of the page containing the gadget is also 'davej'. Knowing this, SocialSite can decide what data the caller is allowed to access.

Step 2 - configure SocialSite to trust your Authentication Delegate page#

SocialSite won't trust just any authentication delegate page. Once you have created your page, you must configure SocialSite to trust it. You do this by editing a SocialSite configuration file in WEB-INF/classes/socialsite_context.xml. Here's an example that sets up a trust relationship with Roller's socialsite_context.jsp page:

Example: socialsite_context.xml in SocialSite


  <rules>
    <rule>
      <sources>
        <indirect>*</indirect>
      </sources>
      <assertions>
        <reject>*</reject>
      </assertions>
    </rule>

    <rule>
      <sources>
        <direct>http://rollerwebogger.org/socialsite_context.jsp</direct>
        <direct>*</direct>
      </sources>
      <assertions>
        <accept>*</accept>
      </assertions>
    </rule>
  </rules>

Step 3 - Add SocialSite Context declarations to target pages#

Once the Authentication Delegate page is in place, you're just about ready to start adding gadgets to the pages of your web applications. Each page that includes gadgets will need to include a couple of SocialSite scripts and information about the SocialSite context, i.e. the URL of the authentication delegate. Here's an example of the the JavaScript that I include include in Roller pages that use SocialSite gadgets:

Example: SocialSite context declaration for a Roller page template


  #set($viewer = $utils.getAuthenticatedUser().getUserName())
  #set($userName = $model.getRequestParameter("user"))
  #if ($userName)
    #set($owner = $userName)
  #else
    #set($owner = $viewer)
  #end
  #set($contextURL = "${url.absoluteSite}/socialsite_context.jsp")
  <script type="text/javascript" 
    src="${url.absoluteSite}/social/js/consumer.jsp"></script>
  <script type="text/javascript">
    socialsite.setContext({
      'delegate': {
        'method': 'GET',
        'url': '$contextURL?owner=$owner&amp;viewer=$viewer',
        'headers': {
          'cookie': document.cookie
        }
      }
    });
  </script>

The above code pulls in some JavaScript from SocialSite and sets up the context necessary for gadgets to call back to SocialSite. It uses Roller's $utils.getAuthenticatedUser() to determine the logged-in user and a request parameter 'user' to determine who owns the page.

Step 4 - decide where to put key social networking pages#

Finally, you're ready to add gadgets to the pages of your site. First, you'll want to do some planning. You'll want to decide where to place some key pages. The SocialSite widgets are designed to support a dashboard page, which allows users to browse people, make friends and receive messages. They also support both personal and group profile pages.

For rollerweblogger.org, I decided to use one Roller page template 'people' to act as both the Dashboard and Profile page. If you access the page with a URL that specifies a user, then you'll see the profile page of that user. If you access the page with without specifying a user, then you'll see your dashboard page. Here's what I put in the socialsite.properties file to set all this up:

Example: SocialSite URL properties from socialsite.properties


  # People page shows your Dashboard
  socialsite.dashboard.url=\
    http://rollerweblogger.org/project/page/people

  # People page with user parameter shows profile of specified user
  socialsite.profile.url=\
    http://rollerweblogger.org/project/page/people?user=${userid}

  # Group profile page will be hosted in JSPWiki
  socialsite.group.url=\
    http://rollerweblogger.org/wiki/Wiki.psh?page=${groupid}

NOTE that in the above configuration, I'm using my wiki to host group profile pages; more about that later.

Step 5 - add OpenSocal Gadgets#

Once you've decided how to set things up, you're ready to start adding gadgets. Assuming that you've added the SocialSite context declarations in your pages, you can add a gagdet with a single line of JavaScript. For example, to add the SocialSite Owner Activities Gadget you'd add this code:

Example: add gadget code from a Roller page template


  <script type="text/javascript">
    socialsite.addGadget({'spec':'local_gadgets/owner_activities.xml', 
      'removable':false, 'height':75, 'includeChrome':true});
  </script><br/><br/>

NOTE that you can add any OpenSocial gadget by specifying its URL in the spec argument of the socialsite.addGadget() call.

Screenshots#

It's screenshot time. I've included small thumbnail images belo, which you can click for a closer view. If you're on my site, photos will display in a light-box. First up, is the new People page that you will see if you are logged into rollerweblogger.org. It uses the SocialSite Profile, Face, Status, Friends and Activities gadgets.

Next up, the dashboard page. It uses just one gadget, the SocialSite Dashboard, which provides a bunch of different features and was introduced in the SocialSite M2 release. In one tab you can see the most recent activities of your friends or any of your groups:

In the second tab of the Dashboard Gadget, you can search and filter the people in the social network. You can filter by friends or by your groups. You can also create new relationships and accept or ignore relationship requests from this view.

In the last tab of the Dashboard Gadget, you can view and manage incoming messages and friendships requests:

Want to see the source code? You can see the page template code for my People page in the Roller page templates people, which contains the SocialSite context declaration, and people, which contains the main body of the page.

Finally, let's take a look at an example group profile page, which is located in my wiki.

Hmm... I never explained how I got SocialSite gadgets working in JSPWiki. Better fix that now.

A note about SocialSite in JSPWiki#

To get SocialSite gadgets working in JSPWiki, I had to to a little extra work. In my instance of JSPWiki, I don't allow HTML so I couldn't just drop in the JavaScript code necessary to declare the SocialSite context and make the socialsite.addGadget() calls. What I had to do was to create a couple of JSPWiki plugins, one for the SocialSite context and one for the add-gadget call. Here the raw wiki text of the Atomic Group page pictured above:


  !!!SocialSite Group: Atomic

  [{SocialSiteGroupContext group='atomic' 
    consumerUri='http://rollerweblogger.org/social/js/consumer.jsp' 
    authUri='http://rollerweblogger.org/socialsite_context.jsp'}]

  Demonstrates the SocialSite Group gadgets, running in JSPWiki.

  !!Group Profile Gadget

  Below is the Group Profile for group __Atomic__. You can use the buttons at 
  the bottom to edit the group's profile properties, to send a message to 
  the group and to add OpenSocial gadgets to this page.

  [{SocialSiteAddGadget spec='/local_gadgets/group_profile.xml' removable='true'}]

  !!Installed Gadgets

  This is where the group's OpenSocial gadgets will appear.
  [{SocialSiteAddGadget collection='GROUP'}]

And here are links to the source code for the two plugins: SocialSiteContext.java and SocialSiteAddGadget.java.

Conclusion#

That should give you a pretty good idea of what you can do with SocialSite. Don't be dissappointed if the gadgets don't look like exactly what you want. The important thing is that SocialSite gives you a centralized social graph service and the infrastructure needed to add social networking features to your sites via OpenSocial gadgets. If you don't like the gadgets that come with SocialSite, you easily write your own using the standard OpenSocial APIs and the SocialSite extensions to those APIs.

Sidebar: What is OAuth and why should you care?

Dave Johnson — Mon, 23 Mar 2009 08:01:39 +0000

I'm going to be following up my OAuth everywhere! post, with several more OAuth related posts this week. So, just in case you are wondering "why is Dave going off on this cockamamie OAuth tangent?", I'll take some time now to explain a little about OAuth to help you understand.

OAuth is a emerging protocol that one web site can use to access your data on another website without asking you to reveal your username and password. For example, when the sinister BuddyNet9000(TM) Social Network site wants to access your GMail account so it can spam your "friends" on your behalf, you can use OAuth to give it access without telling it your username and password. Why risk your GMail security when all you want to do is spam some people? There are less snarky examples, but that one makes the point well, I think.

There's a good end-user oriented introduction on OAuth.net titled Beginner's Guide to OAuth: Protocol Workflow. OAuth is not that widely deployed yet, and is not perfect, but it is emerging and going the IETF standards route.

I'm interested in OAuth because it's part of the OpenSocial spec, used to authorize access to the OpenSocial REST API and to enable OpenSocial Gadgets to call out to OAuth protected resources. Also, because it's used to protect AtomPub-based services, including the Google Data APIs. I needed to learn about it for my Roller and SocialSite work and if you're going to be doing much OpenSocial work, you'll need to learn about it too.

ApacheCon EU 2009!

Dave Johnson — Sun, 22 Mar 2009 14:19:16 +0000

I'm off to ApacheCon EU 2009> tomorrow in Amsterdam to speak on the topic of Shindig for Blogs and Wikis. I'm really looking forward to catching up with my Apache friends and colleagues. That's the conference venue in the photo on the right, the Movenpick hotel (in the background behind the music hall).

I'm staying a couple of extra days, so I hope to have time for bicycling around the city as I've done in the past (see also: Flickr photo sets for 2007 and 2008). Unfortunately, the weather forecast stinks. There's a 60% chance of rain every day that I'm in town. Oh well; guess I'll have plenty of time for blogging.

Speaking of blogging.This week, I'll be posting some blog entries to highlight the work that I've done in preparation for my talk. Here's what I plan to cover:

* Monday: OAuth for AtomPub in Roller
* Tuesday: OAuth for ROME Propono
* Wednesday: SocialSite on rollerweblogger.org
* Thursday: OAuth everywhere (continued)
* Friday: the future of Project SocialSite

If you plan to attend my talk, at 4:30PM on Friday March 27, then you should follow along. Pay special attention to the SocialSite on rollerweblogger.org and OAuth everywhere (continued) posts, which will include detailed background info. I'm looking forward to seeing you there.

OAuth everywhere!

Dave Johnson — Fri, 6 Mar 2009 11:10:54 +0000

For my ApacheCon EU talk, which is now just a couple of weeks away, I'm going to talk about Shindig for Blogs and Wikis. I promised to show social features and OpenSocial Gadgets running inside Apache Roller and Apache JSPWiki (incubating). This post explains, at a very high level, how I got a Roller Gadget working, one that uses OAuth to call Roller and enables Roller to use OAuth to call back to the social network. It assumes you have a basic understanding of OpenSocial and OAuth.

Use case: posting Activities from Roller #

Specifically, what I want to show is a "Social Roller" Gadget that you can install into your Profile Page and that will post an Activity every time that you post a new blog entry in Roller.

Sounds simple, but I didn't realize just how much work it would take. To do it the right way, I needed OAuth everywhere! I needed OAuth Consumer and Provider support in both my Shindig-powered Social Network Server, that's SocialSite, and in my Blog Server, which of course is Roller. Unfortunately, when the layoff axe fell at Sun the SocialSite team had not finished OAuth support and Roller didn't have any OAuth support at all. Good thing is, SocialSite and Roller are open source and I had nothing better to do than to learn about OAuth and crank out some code. I'm not going to let a bunch of axe-wielding bean-counters stop me from keeping my promises.

How it works#

I now have complete OAuth Provider and Consumer support in SocialSite and Roller working and ready to demo. I'll post a screen-cast of the UI changes once I polish it up a bit (and finish my slides). For now, all I've got for you is a diagram that explains how the gadget interacts with SocialSite, Roller and OAuth to post activities to your profile.

Here's the deal. You install the Social Roller Gadget into your Profile Page within Roller. The gadget needs to talk to Roller so (#1) it calls Roller via the JS Container APIs. (Note that the blue indicates parts of the Social Roller Gadget.)

(#2) The container will work with the SocialSite Proxy servlet to add the right OAuth consumer keys, secrets and/or tokens to the request and will then send that request off to Roller. It must first (#3) negotiate with the OAuth Servlets in Roller. If you have not authorized the gadget to access your Roller account, then the container will show Roller's OAuth authorization page so you can hit the Authorize button, or not.

Once the gadget is authorized to access your Roller account, it will (#4) call the gadgetsetup.jsp page via HTTP GET to determine if you have enabled Activity posting. If you want to enable or disable, it will use an HTTP POST to tell Roller what you want.

The setup page will then (#5) call the Gadget Task to tell it to look out for your new blog posts and post an activity for each. The Gadget Task is controlled by Roller's cluster-friendly task management system and setup to run every minute.

Once you've enabled Activity posting, when the Gadget Task runs it will check to see if you have made any new posts and if you have, it will (#6) call the OpenSocial REST API to post an activity for each to your Profile. Negotiating with the OAuth Servlets as needed. And that's that.

What I didn't cover#

There are a lot of things I didn't mention and I hope to document some of them in the next week or so, while I'm still unemployed. Here's a quick summary of missing pieces:

How does SocialSite get the Consumer Key and Secret needed for calling Roller?
How does Roller get the Consumer Key and Secret needed for calling SocialSite?
How does the user authorize Roller's access to his Profile information in SocialSite?
When is OAuth support coming to the Roller trunk and can you use it for AtomPub?
How do I add my gadget to SocialSite so users can install and use it?

There are happy answers for all those questions, but that's all I've got time for today. I've got some slides to finish in a hurry.

G Friend Connect

Dave Johnson — Tue, 17 Feb 2009 22:31:00 +0000

I started a new blog on this site to explore what's possible with Google Friend Connect (GFC). It's called the G Friend Connect blog. I've added the GFC Members Gadget and I replaced Roller's built-in comment macro with the GFC Wall Gadget. In theory, if you have a Google, Yahoo or Open ID account, you should be able to login via a gadget, make friends with other site members and leave comments. If you have a minute or two, try it out. Join the site and leave a comment. That will give me (and you) a better idea of how things work.

So far I'm not particularly impressed with the Wall Gadget as a comments replacement. Here is an example. It doesn't support rich-text editing, no HTML is allowed, the comment area is too small and there's no preview button. Maybe that's why it's called a Wall Gadget rather than a Comments Gadget. Or maybe I'm just not doing it right.

Preparing for my Shindig talk next month

Dave Johnson — Fri, 6 Feb 2009 12:58:34 +0000

The day before the layoff axe fell at Sun, I blogged about my upcoming Shindig for Blogs and Wikis talk at ApacheCon EU in March. Since then, I've been working almost non-stop on finding a new gig and have had little time to work on my presentation. That's not good, because I have fairly ambitious plans for this talk. I'll explain.

I want to be able to show how to add social features including OpenSocial support to a blog server and a wiki server by using plain old Shindig and then Project SocialSite. I'm targeting Roller and JSPWiki because they're the blog and wiki source code bases that I know best right now and they're both Apache efforts, but the same techniques should work with other systems like Wordpress or Drupal. If I have time I might be able to demo those too (but I wouldn't count on it).

I'm not sure how far I can go with plain old Shindig because, like most blog and wiki servers, neither Roller nor JSPWiki has detailed profile data, social relationships or activities. I should be able to get Google Gadgets working via Shindig, but OpenSocial Gadgets will take a lot more thought and effort.

I'm much more confident in the Project SocialSite approach. SocialSite provides for storage of detailed profile information, groups, activities and app data as well as the necessary UI. I'm confident enough that I'm going to deploy it on this site. So, stay tuned. I hope to have something to show by the end of next week.

Oh, and by the way. Today is the last day to register for ApacheCon EU with the early-bird discount. So sign-up already!

ApacheCon Europe 2009 (link)

23-27 March 2009 | MÃ¶venpick Hotel, Amsterdam
Pricing (register before Feb 6 for discount)

Google's Rajdeep Dua on Project SocialSite

Dave Johnson — Tue, 20 Jan 2009 16:58:51 +0000

I'm always happy to see Google talking about Project SocialSite in their OpenSocial presentations and pitches. We need all the help we can get with getting the word out.

Now, Rajdeep Dua of Google Developer Relations has put together a 25 page presentation on Project SocialSite Architecture with data model diagrams, UML and lots of detail. Good stuff. I posted some comments and corrections to the Shindig-dev mailing list

SocialSite's Opensocial extensions, part 1: Web services

Dave Johnson — Wed, 15 Oct 2008 17:45:54 +0000

I'm on SocialSite blog patrol this week, which means that I need to post interesting stuff at blogs.sun.com/socialsite, or here or both places at once.

So here's some blog fodder, a series of posts describing the extensions we are making to OpenSocial for Project SocialSite. I'll start by describing the web services, then the JavaScript API and finally I'll provide an example or two.

Background

As I may have mentioned before, the idea behind SocialSite is to add Social Networking features to existing web sites and applications. Any site or sites should be able to use our Widgets and Web Services to all the standard Social Networking features. To meet our Widget requirements we have to extend OpenSocial to support full read/write access to Social Graph data with support for "friending" with configurable relationship levels, profile editing, group invites, group management, application management and other things.

A word about implementation

On the server-side, our extensions are implemented as Shinding/Java DataRequestHandlers, which makes them available as both a REST API and a JSON-RPC interface. This means that they're available in a form very similar to that of the standard OpenSocial REST API and in a form very similar to the standard OpenSocial JSON-RPC API.

To give you an overview of the SocialSite extensions, I'll review the REST form of our APIs including all of the URIs we support and the HTTP verbs we support for each.

td.uri { width:40%; font-family: Courier; font-size: 10px; } td.data {width:5%; font-family: Courier; font-size: 10px; } td.verbs {width:55%;} td.uri, td.verbs, td.data { border-bottom: grey dotted 1px; vertical-align: text-top} td.routetitle {background: #efefef; color: black; padding: 3px;} table.apiref {width:100%; font-size:13px; margin-bottom: 0.5em;}

People and friending

The standard OpenSocial APIs don't support "friending" -- the process of requesting and negotiating some form of social relationship with another user. So, we've added some new URIs to the /people route in OpenSocial because support . These URIs return and accept standard OpenSocial Person objects, for example to request a relationship with somebody, you POST a representation of that person to your @friends collection.

People
/people/{userId}/@friends	Person	POST - Person to request or accept relationship
/people/{userId}/@requests	Person	GET - List of Persons requesting relationship
/people/{userId}/@requests/{personId}	n/a	DELETE - ignore a Person requesting relationship
/people/{userId}/@friends/{personId}	n/a	DELETE - remove relationship with Person

Profile editing and metadata

The standard OpenSocial APIs don't support creating and updating profile data. So, we've added new /profile and /profiledef routes to enable metadata driven profile property editing. You can create, retrieve and update profile properties for each user. You can also get metadata that defines all profile properties, their types and accepted values.

Profiles
/profiles/{userId}	Profile	GET - SocialSite profile data properties for one user PUT - Update profile data for one user
/profiles	Profile	POST - add a new profile via SocialSite profile data properties
/profiledef	ProfileDefinition	GET - SocialSite profile property metadata in JSON format

Profile Privacy Settings

The standard OpenSocial APIs don't give you any control over who can see which parts of your profile or activities. So, in the standard SocialSite setup, we have grouped the standard OpenSocial properties into seven sections: identification, contact, extended contact, personal, more personal, experience and education. For each of these sections you can choose a visibility level; here they are from most restrictive to least: private, friends only, visible to some your groups, visible to all of your groups and public.

Privacy settings
/sectionprivs/{userId}	List of SectionPrivacy	GET - section privacy settings for user
/sectionprivs/{userId}/{sectionName}	SectionPrivacy	GET - section privacy setting for one profile section PUT - update section privacy setting for one profile section

Group creation, management and invitations

The standard OpenSocial APIs don't support any group creation, management or invitation capabilities. So, we added those too. Like SocialSite Profiles, Groups have properties which are defined by a metadata definition file. Here are the URIs and HTTP verbs for each:

Groups
/groups/@public	Group	GET - all public groups POST - create a new public group
/groups/@public/{groupId}	Group	GET - group specified by group ID
/groups/@public/@current	Group	GET - owning group specified by context (security token)
/groups/{userId}	Group	GET - all of user's groups
/groups/{userId}/@friends	Group	GET - all of user's friend's groups
/groupdef	GroupDefinition	GET - SocialSite group property metadata in JSON format

Looks like that's all I have time for today. Dinner time is here I'll cover the rest of the Web Services in part 2, later this week.

re: Shindig/Java internals

Dave Johnson — Wed, 24 Sep 2008 08:59:09 +0000

If you want more on Shindig/Java internals, then check this out. Rajdeep Dua has written a very detailed article on the topic and he is asking for feedback: Overview of REST Implementation in Shindig - Java Version.

Shindig/Java internals diagram updated

Dave Johnson — Tue, 23 Sep 2008 16:09:52 +0000

A lot has changed since I did my first and even my second "how does Shindig/Java work" diagram. Believe it or not, there are now two separate web services protocols in OpenSocial and thus in Shindig. I'll explain that and then I'll share my updated diagram and synopsis of Shindig/Java internals.

NOTE: this post covers the social API implementation only and not the Gadget server portions of Shindig.

Here's what happened. There was a long discussion on the OpenSocial spec mailing list about the merits of REST vs. RPC for the OpenSocial web services APIs (e.g. here and here). I'm not going to characterize the two sides as the JavaScripty Gadgeteers and the XML-smokin' RESTafarians because that would be just plain silly. Long story short, neither side really "won" and so the latest rev 0.8.1 of OpenSocial includes two separate web services protocols:

The OpenSocial REST API, which is based on AtomPub but with support for XML and JSON formats in addition to Atom format XML. There is no support for batching of operations. (There was a proposal for RESTful batching, but it did not gain consensus.)
The OpenSocial JSON-RPC API where methods are called by HTTP POSTing JSON data and there is full support for batching of operations.

Seems a pity to have two separate protocols that serve essentially the same purpose, but thankfully there are a lot of similarities. For example, the JSON-RPC protocol methods are GET, POST, PUT and DELETE. And the JSON format used in the JSON-RPC protocol matches the one in the REST API. That makes things a little easier for implementers and if you use Shindig as the basis for your social network's OpenSocial implementation, it's even easier -- you implement one set of interfaces and you get support for both REST and JSON-RPC. Next, I'll explain how that works with my updated diagram:

And I'll explain by walking through the processing of one request; here's the walk-through (new stuff is highlighted in yellow:

1... A request enters Shindig via either the DataServiceServlet at /social/rest or the JsonRpcServlet at /social/rpc, which has a map of DataRequestHandlers (which it got from the HandlerProvider) keyed by the route that each handles. It's also got a pair of bean converters, which will come into play later when we need to convert outgoing POJOs to XML or JSON representation.

2... The Servlet creates a RequestItem, which parses the request for easy access later. The request item also has a pair of converters which can be used to convert incoming XML or JSON data into Java POJOs.

There are two different request items, one for REST RestfulRequestItem and one for RPC RpcRequestItem. The RESTful request item parses the incoming URL for parameters and treats data from a POST or PUT as typed data, to be automatically converted from JSON, XML or Atom into a Java POJO object from the SPI.

In the RPC case, everything is a POST and the request item grabs its parameters and the typed payload from the JSON object that was posted to the server.

3... The Servlet calls the appropriate handlers. If the request is a single request, then the Servlet looks up a DataRequestHandler based on the request's "route" (i.e. the first segment of URL's pathinfo). The Servlet calls the selected handler, hands it a request item. If the request is a batch request then the Servlet does the same as above, but in a loop collecting request items.

4... One of Shindig's three request handlers then handles the request and returns a ResponseItem or (plural) items containing the Plain Old Java Objects (POJOs) to be returned to the called. This is the point where incoming XML or JSON data is de-serialized to POJO form by a call to requestItem.getTypedParameter(). Shinding provides three DataRequestHandlers:

PersonHandler: returns Person objects with detailed profile information
ActivtyHandler: returns Activities of people or group, allows activity creation
AppDataHandler: returns Gadget data, allows Gadets to store data

NOTE: If want to add your own REST/RPC APIs to extend Shindig, as we are doing in SocialSite, you can do it by hooking in your own handlers. Use Guice dependency injection to hook in your own custom HandlerProvider, one that returns your own custom handlers.

5... The Shindig handlers call the Shindig Service Provider (SPI), which is defined by a set of interfaces with methods that return ResponseItems. There is a set of model objects, aka POJOS, shown in green that represent the different data types that can be returned by the REST or RPC APIs. The service implementations return these POJO objects and expect the Shindig infrastructure to automatically map POJO to either JSON or XML as appropriate.

PersonService: returns Person objects with detailed profile information
ActivtyService: returns Activities of people or group, allows activity creation
AppDataService: returns Gadget data, allows Gadgets to store data

NOTE: the SPI is where you hook in to Shindig if you want to expose your application's Social Graph data via the standard OpenSocial REST or RPC API. You implement these interfaces with code that calls your back-end to create, retrieve update and delete data. And you hook your implementation via Guice.

6... The handler returns a ResponseItem, which wraps one or a collection of POJOs. The Servlet may then write that response out or, in the batch case, continue to call handlers and collect more ResponseItems.

7...Servlet converts/serializes and returns ResponseItems. In the REST API case, once the handler, or handlers in the batch case, returns the response item(s), the DataServiceServlet calls the appropriate converter to serialize the item(s) to either JSON or XML format depending on what was specified in the 'format' request parameter.

And that's that...

Project SocialSite opens up!

Dave Johnson — Fri, 8 Aug 2008 15:36:08 +0000

My teammates and I have started a new blog over at blogs.sun.com to cover Project SocialSite and to break the big news: we're open!

We are very pleased to announce that source code is now available for Project SocialSite (under a CDDL/GPL license) and the project is now operating as an open source project following the Glassfish governance policy. We're working in the open and welcome contributors of all stripes. Read more...

OpenSocial summit next week

Dave Johnson — Thu, 8 May 2008 19:19:43 +0000

There will be a OpenSocial Summit: May 14th, at the Googleplex covering the new v0.8 spec changes and all sorts of other interesting things. Wish I could make it, but I'll be happily back home in the old north state. Hopefully, somebody from the SocialSite team will be able to attend.

Sweet OpenSocial preso

Dave Johnson — Tue, 4 Mar 2008 18:56:07 +0000

From the Graphing Social Patterns 2008 conference, a sweet OpenSocial presentation with a nice overview of the emerging standard, status of the Apache Shindig project, details of the Hi5 implementation, some cute pictures of my buddy Pat Chanezon's kids and some very fine art (I think Pat forgot to credit the artist).

Latest Links: Feb. 16, 2008

Dave Johnson — Sat, 16 Feb 2008 12:48:07 +0000

More on MySpaceâ€™s Open Development Platform - GigaOM
"made up of three APIs â€” primarily Open Social and extensions weâ€™ve added"
ZDNet.com: Progress report on the OpenSocial Web
Summary of latest OpenSocial news and hackathons from Dan Farber
Facebook to Punish Stupid Applications, Reward Good Ones - ReadWriteWeb
"Metered messaging based on user engagement could save the Facebook Platform from a growing sense of app fatigue"
Roumen's Weblog: Android plug-in for NetBeans
"the screenshots look promising"
Rob Williams' Blog: finally ditched LifeRay
"we have finally ditched Liferay in favor of JBoss Portal. So far so good. It is much more stable. The code base is not a rat's nest of untested Struts goop."
Indoor WiFi Signal Booster by Meraki
"Meraki Mini is a small, easy-to-use wireless mesh repeater."

AtomPub in OpenSocial 0.7

Dave Johnson — Tue, 5 Feb 2008 11:38:30 +0000

I missed this one in my social networking API link-fest yesterday: Google announced version 0.7 of the OpenSocial API, some of the data APIs are outlined in the spec and they're still using AtomPub protocol (just like GData).

I had heard there was some push-back against AtomPub, but I really don't know what is going on because there is no transparency at all in the specification development process. So, who knows, but I really don't think they have time to invent an all new protocol. In fact, they'd better wrap things up tout de suite because Google's planning to go live with OpenSocial on Orkut during the last week of February.

Lots of latest links: social networking APIs and more

Dave Johnson — Mon, 4 Feb 2008 14:00:07 +0000

First, some links from open source projects I'm trying to follow. Check out the JMaki Webtop widget, it looks pretty useful. Now that I've got JMaki support in Roller, this could be the basis for some cool drag-and-drop blog layout. Wish I had time for that; I'm still trying to carve out some time to dig into the Abdera server framework.

jMaki Webtop
Cool iGoogle style portal interface via JMaki
JSPWiki: JSP Wiki 3 Design
JCR back-end, wiki spaces and more...
Abdera Server Implementation Guide
"The Abdera Server module provides a framework for constructing Atom Publishing Protocol server implementations."

I'm also following OpenSocial and Shindig (the reference implementation of OpenSocial) pretty closely, but thus far have not had time to dive into the code. There's lots of activity on the Shindig list, but thus far there's no server-side and security is still up in the air -- both are pending change to the spec itself. Marc Cantor has an interesting perspective on the OpenSocial.

ShindigStarted - hyves_api - Trac
"a small guide on how to get started on Shindig."
CNET Mark Cantor: Waiting for the OpenSocial hammer to drop
"We all hope that MySpace, Bebo, and others will open up and go beyond the original scope of OpenSocial to lay the groundwork for a truly open world of social networking."
<a href="http://www.techcrunch.com/2008/01/17/kickapps-publishes-api-kit-adopts-facebook-and-opensocial-platform- standards/">KickApps Publishes API, Adopts Facebook and OpenSocial standards
"KickApps has adopted Googleâ€™s OpenSocial developer platform standards and is working with Facebook to adopt that companyâ€™s standards as well."

I'm also following Facebook. While Google and friends scramble to catch up, Facebook Apps are getting easier to write, thanks to a new JavaScript API, and easier to deploy thanks to Amazon Web Services.

Facebook Extends Platform to the Web - The Unofficial Facebook Blog
"This is a huge step in Facebook extending their platform beyond the Facebook.com domain and letting people leverage the power of the social graph"
JavaScript Client Library - Facebook Developers Wiki
"Applications that use this client library should be configured to load in an iframe, not be rendered with FBML"
Facebook JavaScript Client Library
"This JavaScript client library allows you to make Facebook API calls from any web site and makes it easy to create Ajax Facebook applications"
Amazon Web Services Blog: AWS For Facebook Applications
"we've teamed with Facebook to collect all of the resources that you need to be the next big success story in one convenient location."

Personally, I really like the idea of the web itself as the social network and your blog as the home for your personal profile. So, I think the new Social Graph API is a step in the right direction, as is the blog-based Distributed Social Networking (DiSo) project.

BuzzMachine:The internet is the social network
"The internet doesnâ€™t need more social networks. The internet is the social network."
Social Graph API - Google Code
Project homepage
Google Social Graph API Released on Dion Almaer's Blog
"Would you like to be able to make a quick call to get a JSON response that ties together a social graph made up of resources available on the Web?";
diso - Google Code
"DiSo (dee â€¢ zoh) is an umbrella project [for] as Chris puts it: 'to build a social network with its skin inside out'"
The Existential DiSo Interview on Vimeo
Factory Joe interviews himself re: Distributed Social Networking

And, I'm happy to see support for Twitter-like microblogging in Wordpress and Facebook like activity streams from Movable Type.

Introducing Prologue: WordPress.com
"Weâ€™re fans of Twitter around here, [but] while the format appealed to us it really just whetted our appetite for something more"
Building Action Streams - MovableType.org
"framework for collecting your actions from services around the web into one place for you to share back out as you see fit."
Action Streams | Plugin Directory | movabletype.org
"aggregate, control, and share your actions around the web "

And to wrap up: maybe I don't need to worry about the intersection of Blogging and Social Networking at all. Maybe there's no need to following all these APIs. Maybe the hype has peaked and Facebook and friends are about to go the way of the CB radio. Apparently, folks aren't spending quite as much time Facebooking as they used to:

ZDNet.com: Ohmigod! Social networkers just canâ€™t take it any more!
"it is entirely possible that people are beginning to question just how much time they spend socially networking, rather than socially living."

Latest Links

Dave Johnson — Tue, 18 Dec 2007 14:00:07 +0000

Today, I've got a couple of additions to my powered-by-Roller list:

GMJ Designs : Apache Roller 4.0 Released
"I love the interface and it works great."
Toast Technology Blogs : Weblog
SOA and business portal consultancy blogging with Roller
Limlom.com company blog
Business solutions and J2EE consultancy blogging with Roller
Biblical Recorder journals
Blogs and Baptist Planet all powered by Roller

More about the opening of the Social Networking platforms of the world:

Dare Obasanjo: Thoughts on the Opening of the Facebook Platform
"looks like Facebook plans to assert their Intellectual Property rights on anyone who clones their platform"
OpenSocial API Blog: Let's get this Shindig started
"We're thrilled to tell you the initial commit to the Shindig repository is in"
Ruminating on DiSo and the public domain
"Iâ€™m hopeful about projects like Shindig that call themselves â€œopen sourceâ€ and are able to be sponsored by stringent organizations like the Apache foundation. But..."

And some more about the intersection of corporate interests and community open source:

InfoWorld: Open source and the corporate elephant (FOSS.IN coverage)
Danese Cooper: "Having a well-read blog is the best defense you can have against any problems you may encounter"
eWeek: Sun Open-Source Support Questioned
"The only reason anyone should be surprised by anything Sun does with [the open-source projects] it controls is because that person has fundamentally created an expectation that access to source code meant more than just thatâ€”and that is a flawed assumption."
Reg Developer: Bruce Perens on the OpenDS spat
"In general open source is only going to work if you let it be a community led project. Sun has had a hard time learning this, and some of their open source projects have had a hard time getting outside contributors, because Sun has insisted on owning the [project]"

Latest Links: Feedsync, AtomPub for SOA, OpenSocial and more

Dave Johnson — Thu, 6 Dec 2007 14:00:10 +0000

snellspace.com: Sync!
"Within the course of implementing several Atompub servers, the issue of â€œfeed synchronizationâ€ has come up repeatedly"
Paul Fremantle's Blog: A new kind of (SOA) Registry
"as we looked at the REST space, we kept noticing how close the [AtomPub] is to our needs"

OpenSocial - Berlin Web 2.0 Expo
Google API evangelist Pat Chanezon's OpenSocial presentation
opensocket - Run OpenSocial Gadgets in Facebook
An OpenSocial container written as a Facebook application.
Ruby on Rails: OpenSocial container plugin 0.0.1
"This is a very early version, but it is under very active development "

IBM's Carol Jones on Web 2.0 Research and Collaborative Software
Redmonk video discussion of Lotus Connections, Dogear, internal/private vs. external bookmarking
Wayne Horkan's weblog eclectic: Weblog language translator
With Roller specific functionality. Based on JavaScript and Google translation API
ZDNet.com: Social nets and identity fragmentation
FaberNovel Consulting has mapped out some trends in social networking and digital identity"
Postgres at Hi5: June 2007 user group preso
How unique features of PostgreSQL helped Hi5 scale (PDF presentation)
Scaling Java and PostgreSQL with Hyperic
Another perspective on PostgreSQL scalability at Hi5 (PDF presentation)
Skrentablog: Scaling Facebook, Hi5 with memcached
"discussion of high volume [sites] using memcached as a critical scaling tool"

Apache Shindig voting in progress and more OpenSocial details emerge

Dave Johnson — Fri, 30 Nov 2007 12:48:25 +0000

I wrote about Shindig before, it's a new open source project to implement the Google OpenSocial APIs. Well, now the official voting to accept the Shindig project into the Apache Incubator is in progress and some interesting details have emerged in the latest version of the proposal. First, as you can see by the initial list of committers in the proposal Google has joined the Shindig effort in force. Second, the proposal says that Shindig will be the reference implementation of the OpenSocial APIs. And third, Shindig will not only include the client-side JavaScript container but also a Java back-end. Brian McAllister has already made some "gnarly" initial client-side container code available, I can't wait to see the Google contribution.

Shindig: open source implementation of OpenSocial

Dave Johnson — Tue, 13 Nov 2007 11:29:50 +0000

Apache member Brian McAllister, who works for Ning, has proposed a new project for Apache called Shindig. Here's an excerpt from the proposal:

OpenSocial provides a common set of APIs for social applications across multiple websites. With standard JavaScript and HTML, developers can create social applications that use a social network's friends and update feeds. A social application, in this context, is an application run by a third party provider and embedded in a web page, or web application, which consumes services provided by the container and by the application host. This is very similar to Portal/Portlet technology, but is based on client-side compositing, rather than server. More information can be found about OpenSocial at http://code.google.com/apis/opensocial.

Shindig is an implementation of an emerging set of APIs for client-side composited web applications. The Apache Software Foundation has proven to have developed a strong system and set of mores for building community-centric, open standards based systems with a wide variety of participants. A robust, community-developed implementation of these APIs will encourage compatibility between service providers, ensure an excellent implementation is available to everyone, and enable faster and easier application development for users.

. . .

Ning, Inc. intends to donate code based on their implementation of OpenSocial. The backend systems will be replaced with more generic equivalents in order to not bind the implementation to specifics of the Ning platform.

Brian is pretty excited about OpenSocial as a light-weight client-side alternative to Portal/Portlet technology, not just for social apps but for webapps of all kind. He'd like to see both Apache Roller and Apache JSPWIki (incubating) become OpenSocial containers, despite the fact that neither product stores the social graph of user/friend relationships. Blogs and wikis are already great platforms for web development, OpenSocial could make them even stronger. Very interesting stuff.

I hadn't planned on talking OpenSocial during my session tomorrow, but I might have to add a slide or two to illustrate the possibilities.

Latest links Nov. 12, 2007: Glassfish, OpenSocial and more

Dave Johnson — Mon, 12 Nov 2007 07:23:08 +0000

Sound Opinions from Chicago Public Radio and American Public Media
Best podcast ever

The Aquarium: GlassFish Interim Governance Board - Now Complete
"The complete roster is Tony, Greg Luck (Wotif.com) and Pierre Delisle (Google), and Simon and myself (Sun)"
Bistro!: GlassFish/SJS AS in production - which bundle, which profile, ...?
Explains differences between developer, cluster and enterprise profiles
GlassFish Podcast: The GlassFish Podcast
Finally, a Glassfish podcast! Props to Alexis Moussine-Pouchkine
Apple - Downloads - UNIX & Open Source - GlassFish
Download Glassfish V2 directly from Apple
Red Hat and Sun Collaborate to Advance Open Source Java Technology
"Red Hat has signed Sun's broad contributor agreement that covers participation in all Sun-led open source projects."

Megginson: First looks at OpenSocial: part 1 (URLs)
Lists the URIs for the AtomPub collections available in OpenSocial
Megginson: First looks at OpenSocial: part 2 (members and friends)
How OpenSocial members and friends are represented in Atom format
Megginson: First looks at OpenSocial: part 3 (activities)
How OpenSocial activities are represented in Atom format and manipulated via AtomPub protocol
Megginson: First looks at OpenSocial: part 4 (persistence data)
How OpenSocial persistence is implemented via AtomPub protocol
Google: OpenSocial Container Sample
Shows "basic demonstration-level OpenSocial container can be implemented"
Dare Obasanjo: OpenSocial Tech. Overview and Critique
"Despite these misgivings, I think this is a step in the right direction. Web widget and social graph APIs need to be standardized across the Web."

snellspace.com: Notes, Part 2
"lots and lots of things that can be modeled as collections of web resources"
netzooid: Building Services with AtomPub
"While APP is not the one true protocol, I think I?m hooked"