MARK WEITZEL: Welome, my name
is Mark Weitzel and I'll be
talking about best practices
for OpenSocial in the
enterprise with some of
my colleagues here.
By way of introduction I work
for IBM, part of their strategy
and technology team and I'm
also an Officer of the
OpenSocial Foundation.
As we get going you can follow
along with Google Wave.
There's the bit.ly and we have
the bit.ly link on the bottom
of the slides so you don't
have to worry about
remembering it now.
And the hashtag for all you
Twitter guys is #opensocial.
So we'll do a little bit of
introduction, background, make
sure we level set on what
OpenSocial is, how it works and
then we'll talk about where we
can start applying that inside
the enterprise in some
interesting ways.
So what is OpenSocial?
When we think about it
really breaks down
into three big things.
The first big thing is it's
a social graph, social API.
So it has a data model for
profiles and people, but it
also has a Web 2.0
component model.
It allows you to take these
components and move them around
inside of applications.
So you can do some very rich
application embedding and
that's the gadget part of it.
So if we think about the social
data model this gives a
standard representation because
OpenSocial is an
open foundation.
It provides a standard
representation for profile,
people, their relationships
and feeds or activities.
And we'll talk a little
bit about activity
streams later on.
But their activities, it gives
a standard representation
for those things.
And it's also easily
extensible, so if you have some
information, particularly in
enterprise contexts, it's easy
to extend that model.
And if you abstract that out
what you're really talking
about is a connected
graph of people.
And those are fundamental
to the way business works.
The other thing that we have
inside of OpenSocial is a set
of these core APIs, the social
APIs that you can get from
both JavaScript and via REST.
So you can use the JavaScript
API in the gadgets to get
access to people and when
you're doing things where you
don't necessarily have
JavaScript you can get
access to that same
information via REST.
If we talk about for example,
in gadgets, you know we've got
basically HTML, CSS, JavaScript
model that we wrap a little bit
of XML around and that gives
us a way to modularize and
create a standard component.
We can take that component and
move it around into different
websites that we
call containers.
So things like iGoogle,
Myspace, all of those things
are what we would call social
network containers, but we can
also take that same technology
because there's an open source
reference implementation, we
can take that same technology
and we can use that behind the
firewall to build really
interesting apps and get
that same modularization.
And again, the JavaScript
API is for accessing that
information, for accessing
people is available
in JavaScript.
There is a reference
implementation available
in open source called
Apache Shindig.
Part of the technology that was
donated by Google was some of
the gadget technology
that they had.
But it's important to remember
that both OpenSocial and Apache
are not Google related efforts.
This is really a community
effort that we have.
We have an open foundation
that's made up of a number
of member companies.
Google is one of them.
Myspace, several others.
As well as an open source
project that's run at Apache,
so anybody can contribute.
So that's a very important
thing as we start thinking
about how we take this forward.
This really is a
community driven effort.
In Shindig you can have
a Java or PHP server.
You have both of them,
so you have your choice
of technology there.
And Shindig is widely used
and widely deployed at most
of the social networks.
So it's important as we think
about this to understand
how gadgets work.
One of the key pieces of
technology is that the social
container, the thing that
provides the social contact to
the application that your
embedding does not necessarily
have to be on the same server.
They can be in fact spread
across the firewall if you
will or even you know,
outside your enterprise.
And that's very important
because this allows some very
interesting application
embedding scenarios.
If you have a business
relationship between
enterprises you can
surface that relationship
using gadgets.
So what happens when the page
loads, somebody comes in and
they get to a browser, the
browser makes a request.
Say you're loading up a
dashboard, for example.
And then what will happen is
you'll go into the gadget
rendering part of Shindig or
your OpenSocial container.
It will fetch the gadget
definition, which is simply
an XML file around CSS,
HTML and JavaScript.
It'll fetch that.
It'll return it and process
it and then send that back
down to the dashboard.
And then you can turn around
and make another request if you
will to the gadget rendering
service to get some social data
and return that all back.
Now this flow can actually
be optimized in the 1.0 and
0.9 versions of the spec
through data pipelining.
So you can take that whole
thing and make that one time
and you don't have to do this
constant bouncing back.
What becomes very interesting
though is as we think about
that application running inside
the browser, what you end up
having is one place to get
social context and another
place to have business logic.
And so if you think about all
of the applications that you do
inside of your enterprise,
where you have people,
relationships with people, and
the things people do, and now
you have a way to get that
information from one place and
use it with business logic from
another place it becomes
very, very powerful.
So I can take business logic
from a business partner
or another part of my
organization, I can bring it in
and I can compliment all of
that with some social data.
And it's important that we
don't think about necessarily
friends in the traditional
sense as Helen and I are
friends, but it could be that
Helen and I are colleagues
collaborating on a
presentation for Google I/O.
Helen works for Cisco.
I work for IBM.
And the things that we do and
the people that we interrelate
with can be reflected in that
kind of social network as well.
So speaking of that we
started about a year ago.
It was last Google I/O where
we did an initial enterprise
OpenSocial session.
It was a collection of us that
got together really looking at
this component model,
recognizing the value that a
standard based component model
would have when you could take
this and move it around the web
and deploy it in
context, right.
How that social context.
And we started thinking about
how we can work together to
kind of have a collective voice
around, you know guys, you
started this in the consumer
space and it worked really
well, but as you move into the
enterprise there's a couple
things that we need
to start looking at.
And that was the result that
we started talking about.
And it turns out that you know
Jive, and Atlassian, Cisco, and
SAP you know, we all have the
same sorts of concerns and we
said this is the way we can
work in the open, transparently
and collectively to advance
this specification.
Because [? inter-op ?]
works good for all of us.
That's a shared
goal that we have.
So one of the things that we
did was we had a meetup in
September and we started
working on this white paper.
Thinking about you know, how do
we go off and define and these
are some of the folks that
participated in the white paper
who have either proof of
concepts or are interested, are
looking at things around
OpenSocial and how we do it.
Some of the folks that are
on there actually have
implementations of that and
are using that as well.
And so this was the result.
We put together an Enterprise
OpenSocial White Paper and we
really looked at this through
the lens of if I'm sitting
behind my firewall and I'm in
my enterprise, what are the
things that I need that
OpenSocial doesn't have?
We need to think
about manageability.
The kind of interoperability
that we have has to be better
because our customers aren't
going to have the, well it
kind of mostly sort
of works over here.
And there are just the
little things that are off.
So interoperability,
portability, security, which
Mark Halvorson will talk about.
And then tooling, right?
It has to be easier.
There was a session earlier
about being able to build
OpenSocial gadgets easier, so
tooling is another aspect.
So these are things that we
identified and we don't
necessarily have all the
answers, but these are
the kinds of things that
we're working towards
collectively as a group.
So one of the things that I get
to do in my role at IBM is I
get to do a lot of early
prototyping and early
looking at technology.
And that's part of my
role in the strategy
and technology group.
Is to look at this and
understand how and what we
can do with these emerging
things in the market.
So one of our goals has always
been about aggregation.
This has been the focus of IBM
for a long time and we did
portal aggregation in JSR 168
and it works great, right?
And we even went so far as to
say you know, OK, now that
we've got portlets that we can
bring these things together,
how do we get them when we have
different kind of
portlet servers?
So we can do things like WSRP,
the remote portlet stuff.
But now what we've started to
see is we're doing aggregation
on the client and how do
we start thinking about
aggregation on the client?
And this is really getting
into the AJAX model, right?
The CSS, the HTML,
the JavaScript.
And so how do we start
thinking about that?
And so as we look around we are
building and our customers are
buildings these very rich apps.
You know, with things like Dojo
and jQuery and script.aculo.us
and those sorts of things.
And if we think about bringing
gadgets on top, well now we get
a little XML wrapper around
that and we get some very, very
interesting and additional
capabilities like
OpenSocial markup language
that we can use.
Or you know, a
gadget lifecycle.
When things are added to
the page, when things are
taken off the page, we
get some callbacks there.
We get the oauth that's already
in this specification.
We get things like data
pipelining and features.
So that little shell of XML and
the fact that we've got a
container to interpret that
brings a lot of value and can
start standardizing on how we
can move these components and
these embedded applications
around on the web.
And that gets more fun
when you start thinking
about the social APIs.
Having the social context
available to that application.
Again, let's not think about
friends if you will, but people
and people being connected to
people and the things
that those people do.
And that's a large part of what
we've got here in OpenSocial.
Is a nice, abstract way to
think about those things.
And then you can complement
that with the kinds of things
like media items, which are
your videos, things like that.
So you can start having
a standard programming
model for these things.
Because that standard
programming model is there you
can do this inside the browser
inside these gadgets and if
you're dealing with something
like a hybrid app well you
know, we can push that down
and render that on a
smart client, right?
A smartphone kind of thing
or if you want to build a
native app, there you go.
You can use the REST APIs.
So one of the things that we've
done at IBM is we have a
product called mashup center.
One of the things that we've
found is a lot of companies
have an initiative like
this on their own.
In IBM we have one that we call
iWidgets and a lot of our
products are done with
iWidgets, which aren't really
the same as OpenSocial gadgets.
And so it's important
that all of these things
start to interoperate.
And can communicate, so they
all need to be treated as sort
of first class citizens.
And so one of the things that
this demo will show is if I'm
in a business context and we
just took health care
as a random example.
This could be retail
or it could be travel
and transportation.
But you know, what would
we start to look at?
What would something
like this look like?
So we mocked this up using
our mashup center product.
And what's going to happen is
if I click-- I get a demo here.
There we go, OK.
So what's going to happen is,
we go through this is you're
going to see that I can take,
regardless of the type of
component, so that happens to
be one of our internal iWIdget
type components and I can add a
feed and I can bring that up.
That's from the CDC.
And the other thing that I
can do is I can start to
build these rich mashups.
I can take these OpenSocial
gadgets, these iWidgets and
I can put them and lay them
out using the mashup center
product all on the same page.
And what you're going to see is
one of the things that we're
working on right now is we're
working with the technology
that IBM did in the Open AJAX
Alliance, which is another open
foundation to build
AJAX components.
And there's an underlying
technology here called the Open
AJAX Hub, which allows you to
do secure eventing between
components in the browser.
So I can do secure eventing
between two OpenSocial gadgets.
I can do secure eventing
between two iWidgets.
I can do secure eventing
between an iWidget and
an OpenSocial gadget.
So now I can build these very
rich interactive mashups using
this type of technology.
And so we're doing a
couple of things.
We're taking the eventing
piece, that core technology
called the Open AJAX Hub and
we're bringing it inside of
Apache Shindig and then
ultimately we'll write the spec
around what does an event
look like for the gadget.
So you can actaully have that
as a formal part of the API.
And so what you're going to see
here is in this example this is
really simple, it's
a patient list.
So here are the patients that
some doctor John Doe is
going to see for the day.
And so if you've used Shindig
you'll recognize George
and [? Jainee ?]
and those guys because this is
just pulling some sample data
from the sample container
inside or just the sample json
database that comes
with Shindig.
And what's going to happen is
as I start to build this up
I'll select on [? Jainee ?]
and you'll see the data
populate in the back.
And that uses that eventing
mechanism and all of this is
in OpenSocial so what we
interpreted as friends is a
doctor and the patient list.
So that's one way we can show
that abstract API here.
And again, you see
I selected it.
Things populate and
life is great.
So you can start to see how we
can put all of these things
together to get this
very rich experience.
We can look at the abstract
social model and apply that
in a business context.
OK, so now I'm going to turn
it over to Mark Halvorson,
who will talk a little
bit about security.
Mark.
MARK HALVORSON Thank you Mark.
I'll keep it easy for you guys.
My name is also Mark.
I'm Mark Halvorson.
I'm the Chief Imagineer
at Atlassian Software.
So now that Mark's shown us
some of the things we might
want to do with gadgets like
this let's start talking about
how we're actually working with
these technologies
in the real world.
So a componentized model like
this is a great way to write
small UI components and bring
them together in a context
to relates to what the
user is trying to do.
So things like a dashboard
or wiki page can now have
rich content that's coming
from back end systems.
But when you start to try to
write these small UI components
you're always faced with the
same challenge inside
an enterprise.
And that's that these back end
systems are going to require
some sort of authentication.
You're trying to pull data from
an Oracle or from SAP or from
some other system you're going
to be challenged for
credentials in order to
get that information.
Now in the past there's
ways to work around this.
Whether you prompt the user for
the username and password and
pass that on to the back end
application or if you happen to
have an SSO solution in house
like that's great, things
will work automatically.
There's lots of different ways
you can kind of work around
this security challenge.
However, all of these
different solutions have
one thing in common.
When you're asking the user
for these credentials
you're authenticating
to the back end system.
You're actually
authenticating as that user.
That means that the gadget
itself can do all of the
actions in the back end
system that the user
could do by themselves.
So that could be bad.
If the gadget were to go and
change your password for
example it, could completely
lock you out of that system.
So in an enterprise, when
you're talking about enterprise
systems that actually run the
business like SAP or things
that have your financial
numbers it can hinder adoption
of things like these dashboards
or gadgets if the CFO or
somebody has to hand over their
credentials because that
could be a liability.
There has to a better way and
that way is through OAuth.
So OAuth is actually
authentication at
the API level.
So instead of handing over your
credentials and letting a
gadget behave exactly like you
in the back end system, with
OAuth you're granted a token
that will only allow them to
interact with certain APIs
on the back end system.
It's like a valet key for
your application as it were.
There's a lot of nice
things about OAuth.
It's an open standard.
That means that everybody's
doing the same thing, so as
Oracle is writing REST APIs or
SAP's writing your REST APIs we
can all kind of be on the same
page as how we're
authenticating in the
back end system.
And how that's nice with
OpenSocial in specific
is that it's just baked
into the specification.
So in order to get a REST
endpoint on a back end system
to work with an OpenSocial
gadget you simply have to tell
that gadget where the endpoints
are for the OAuth
authentication.
And then you hand off all the
complexity of getting that
authorization to the
container itself.
So it's literally adding these
three lines of code to your
gadget specification and you're
able to be OAuth enabled.
So how this looks to the end
user is when they're presented
a gadget that is not authorized
to the back end system the
gadget will ask the user
to authorize the gadget.
When they click the button
they're actually passed off to
the other application where
they enter their credentials.
So they're never actually
giving over their username and
password to the gadget itself.
It all happens within the
application that they're
trying to work with.
After that application gets the
credentials from the user it
then asks the user to
authorize the gadget.
And when they authorize the
gadget they're actually going
to authorize only the APIs that
that gadget needs access to.
And then finally they're
redirected back to the gadget.
So Atlassian itself has widely
adopted OpenSocial inside of
all of our products, so all of
our products currently are
OpenSocial gadget producers.
And then we have OpenSocial
containers inside of JIRA and
Confluence, which means that
you can have dashboards or
create wiki pages with which
gadget content out
of the box today.
One of the areas that we're
working on within the
enterprise open social group is
that while OAuth is great on
many levels there are still
some little niggles about
how you work with OAuth.
So if you place for example, in
this case on one Confluence
page two gadgets that point at
the same back end system you're
going to have to authorize each
gadget independent
of one another.
That's because each gadget
runs inside of an iFrame.
It is completely walled
off from the context
within which it runs.
So that can be kind of a hassle
for the end user because that
means they have to
authorize each individual
gadget one by one.
So we're looking at ways to
modify the specification to
make it so that if they
authorize one gadget on a back
end system and another gadget
from the back end system is on
that page that both get
authenticated at the same time.
So with that I'm going to hand
it over to Helen, who's going
to talk a little bit about how
they're reusing existing
infrastructure inside Cisco.
HELEN CHEN: Thanks, Mark.
Hi everyone.
My name is Helen
Chen from Cisco.
I'm the Engineering Manager.
So I'm going to share with you
some of the experience we
got when integrated with
the existing systems.
So before you start, you really
need to think about very
carefully about your
deployment plan.
For example, your existing
application, what is the
relationship with the new
OpenSocial application you
are going to develop?
And also, the gadgets inside
your firewall, does it need to
access outside services or,
outside services need you to
get some information
from your services.
And also, what's your
IT policy for this?
Do they need to allow your
server to do a server to server
call from your server machine
and how about through
the proxy server?
All those kind of things you
need to think through it before
you start otherwise you
probably need to redesign
the whole architecture.
So of course, when are two of
those kind of things we're also
facing some kind of challenges
over there when we're designing
and implementing our
social applications.
For example, the standard, even
though the standard mentioned
the people information could
be extended, but it doesn't
address the granular [? role ?]
controlled authorization.
For example, some of the
gadgets you probably only
allow them to access by your
financial department or some
other gadgets may be only
available for the
sales department.
Secondly, for the issue ID from
the specification it doesn't
tell you too specific much
about how the user ID looks
like and these enterprise
[UNINTELLIGIBLE]
you probably only have the
single user ID how those
things could be addressed.
And thirdly, the
inter-gadget communication.
What we're addressing in
the future release is.
I mean, you're here and we
are here to work together
to make that happen.
And then thirdly is the
guidance for extension.
All of us will provide some
kind of surface from there, but
what that kind of extensions
the detail should be?
The guidance for this
extension will improve the
interoperabilities even
from the extended APIs.
So this is some other
lessons we learned.
You already have
people's information
in your LDAP server.
Why you ask the users to input,
to fill their profiles from
scratch if you know kind of
most of the social app they
monitor your profile.
How many percentages
that have been filled.
You can see that kind of
challenge is most people
don't really like to
fill their profile.
So we find out since the LDAP
already has those kind of
information so we extended the
person services from the
Shindig and from that we get
all those kind of LDAP
information automatically
for your users.
When the user first time log-in
they'll get pretty much 80%
of their profile filled-in.
And they're automatically
synced with the back
end server every night.
Of course, we also extended
the social API [? juice ?]
module to bind you're
[UNINTELLIGIBLE]
with that interface.
And also, the enterprise
extension, when you create your
services I'm very sure you're
allowed to simply create
another social app.
You add your unique
values to it.
How do you do that?
From Cisco's experience we
basically created the new pulse
services and also this kind of
template looks like the first
part, the pulse services and
then gives a guid, which is an
e-mail address and then the
service ID and followed by
some other parameters.
Currently we support
the response data like
XML and the JSON.
The whole [UNINTELLIGIBLE]
works.
So I'll do about like
a two minutes demo.
In front of there is
about 30 minutes.
Something like the marketing
like those kind of demos.
Just get ignored.
The reason we put that one in
front is because we want to
provide to those elements
What's Cisco's doing using
elements to the OpenSocial and
what's the OpenSocial
helped us?
[UNINTELLIGIBLE]
Could we get the sound?
I'm not sure.
Do I hit play?
DEMO VOICE: Cisco Pulse is an
innovative search and analytics
platform that taps into real
time information flows over the
network and discovers the
collective expertise
of an organization.
Cisco Pulse allows you to
search for people with
experience with a
specified term.
The people found in a search
are ranked by their net pulse,
which is determined by the
tagging of e-mails and web
traffic, as well as rich
media that is shared
across the network.
In addition, Cisco Pulse finds
relevant documents and videos
for the specified term.
Cisco Pulse leverages
and extends OpenSocial
in several ways.
For example, companies
typically store user data,
such as name and corporate
address in their LDAP
directory services.
Cisco Pulse can leverage this
LDAP data and in turn make it
available through
it's people API.
The real power of Cisco Pulse's
OpenSocial implementation is
the portability of the feature
set to other containers.
Through extensions of the
existing OpenSocial APIs the
search and analytical services
of Pulse are available
via external gadgets.
By leveraging OpenSocial it is
possible to easily integrate
Cisco Pulse's intelligence
into a users workflow.
HELEN CHEN: So maybe
hand it to Matt.
He will address more OpenSocial
enterpirse challenges.
MATT TUCKER: All right, so the
one thing we practiced was our
transitions, can you guys tell?
My name is Matt Tucker, I'm
the CTO at Jive Software.
And I'm going to cover a couple
of specific challenges about
using OpenSocial in the
enterprise context and then
I'll bring it home and we'll
open it up for questions.
So I'm going to cover
another OAuth topic.
One of the fantastic things
in a consumer world
is the simplicity of
monolithic services.
There's only one iGoogle,
there's one Facebook, there's
one Twitter and if you guys
have ever done any development
using OAuth against Twitter for
example, you know that to
interact with any Twitter user,
you as a developer go to the
Twitter website, register for
an OAuth consumer key and
a consumers secret and
use that for everyone.
Now unfortunately that just
doesn't quite exist, that
same model doesn't exist
in the enterprise world.
For example, Jive SBS which is
our product, there are
thousands of implementations of
our product and a lot of them
are behind the firewall.
So consider what that means
for a developer with
the OAuth model.
Essentially, as a developer,
you need to go to every single
Jive instance and register for
an OAuth consumer key
and consumer secret.
That's an explosion of
complexity and it's much, much
harder because you have to deal
with the firewall issues.
So obviously this is not a
good situation and there
should be a solution.
One possible solution
would be OAuth 2.0.
It's an emerging specification.
It's starting to go
through the ITF process.
Facebook recently launched part
of their social graph API using
OAuth 2.0 And it's possible to
use the SSL certificate at
methodology and OAuth 2.0 to
make it simpler to do
that negotiation.
There's another possible
solution that we
are looking at.
And essentially it's to somehow
make all these different Jive
SBS instances look like
one monolithic service.
And two advantages to that.
One is we solve the
OAuth problem.
It is now you register as a
Jive instance when you're first
signing up as an administrator
with a public cloud and
secured data connecter.
Then as a developer you
go register what the
cloud service wants.
You get one OAuth consumer
key and consumer secret.
And you can use that
to communicate with
any Jive instance.
So we solve the OAuth problem
and we also solve the firewall
problem because the secured
data connector will let
you do the communication
through the firewall.
Now of course we have to make
sure that we're handling
security the proper way and
that if you want to communicate
with a gadget on a particular
Jive instance that you're
actually authenticated
to do that.
But once you get that all
working this is a much simpler
model for developers.
All right, another
issue with OpenSocial.
We're kind of [? grazing ?]
the enterprise world trying
to use a consumer defined
specification perhaps.
So I've pulled all these words
from the actual OpenSocial spec
and you'll see things on here
like whether you're a smoker,
your favorite TV shows, your
body type, whether you drink.
These are not necessarily
enterprise friendly concepts.
And all of it's optional and
there is a little bit of work
to do in order to take what was
defined in the consumer world
and make it work well
from the enterprise.
Of course, that is was done for
the consumer world is the whole
reason that it's simple and
that's why we all find it very
interesting is it's a very
simple programming model and
much better than anything we've
had in the enterprise before.
So what are some of the things
that we are doing in order to
address the fact that it is
a consumer specification?
First, the group of us and the
larger enterprise OpenSocial
working group are doing some
efforts to define some business
friendly profile fields as
well as activity verbs.
So as you do an action like
file an expense report, what
kind of verb would
you use for that?
And another thing that's
fantastic about OpenSocial
itself is that
extensibility is built in.
Helen talked a little bit about
how Cisco has taken the
extension mechanism in
OpenSocial to add access
to their own data.
So the fact that that's built
into this specification itself
makes it much simpler for
vendors like all of us.
There's also a technology in
OpenSocial called osml tags.
It's a simple templating system
if any of you have programmed
against Facebook with FBML it
would look fairly familiar.
And that system is
extensible as well.
So it makes it very easy to add
container specific osml tags.
And then finally one effort
that we're all excited about is
ongoing work to merge together
the activity streams
specification with
OpenSocial activities.
There's a lot of good work
going on right now and I think
I saw that the first patch for
the Shindig OpenSocial project
to integrate with some activity
streams pretty recently.
All right, so what are
we working on with the
actual OpenSocial spec?
The 1.0 release just came
out fairly recently.
We're targeting that next
release of the spec after 1.0
for the end of the year.
And a few things that
matter a lot to us in the
enterprise working group.
First, is to solve the
inter-gadget communication
problem that the first
Mark talked about.
So make it possible to
securely share data between
gadgets on the same page.
Second, we want to solve
some OAuth issues.
One in particular is installing
multiple gadgets on the same
page and only having one OAuth
request flow, which the
other Mark talked about.
We definitely want to be
ahead of the curve with
OAuth 2.0 as well.
So the plan is to try to have
some working code and then as
the OAuth 2.0 standard goes
through the ITF,
we'll be ready.
Don't know quite exactly when
that will all play out, but our
intention is to be ready so
that we can move to OAuth
2.0 when the time is right.
And finally, it should
be possible to view
gadgets through mobile.
And so we wanted to find a
mobile view for the gadget
specification so it's
possible to consume gadgets
from mobile devices.
So what do we want you to
leave this session with?
First, that OpenSocial is an
open, standards based and most
importantly, Web 2.0 style of
building apps and gadgets.
So it's HTML, it's
CSS and JavaScript.
This is simple.
If we think about what's been
in the enterprise for a long
time, JSR 168 portlets really,
this is far simpler, far
better and that's why we're
all excited about it.
Second, that there's
enormous opportunity
for this technology.
And for social in general
in the enterprise.
There are going to be a
lot of domain specific
social networks.
We saw one example of that with
the patient physician social
network that Mark talked about.
And finally, it's easy to use
this technology to leverage
what you already have.
Because it's HTML and CSS and
JavaScript that means you take
your existing enterprise apps,
turn them into gadgets in a
very easy way and all of us as
vendors are also trying to make
it very easy to leverage things
like your existing LDAP back
end in order to build out the
social graph in a simple way.
We have collected a few
resources if you're interested
in exploring more.
You can find these in
the slide deck later.
In particular, the white
paper that Mark mentioned
is a great resource.
Talks a lot about why we think
this specification is very
important in the enterprise.
And with that we'll end
a little bit early.
Thank you so much and we'll
open it up for questions.
AUDIENCE: Hi.
This is not an enterprise
specific question, but a more
OpenSocial in general question.
I'm implementing an app that
pulls together contacts and
events from different networks
like Facebook, Twitter,
Linkedin, and all that.
So currently what I'm doing is
using OAuth for each of those
networks and then using the
APIs that each of these
networks provides, REST APIs.
So my question is, is there
any benefit of looking at
OpenSocial API to access data
and what's the advantage
versus using the custom API?
Because it seems to me that you
know, you lose some power and
the second thing is what
do we do with Facebook?
Thanks.
MATT TUCKER: All right, I'll
start an answer and then we
can pass it down perhaps.
So why use OpenSocial?
Why [? Am ?]
said, let's say you have OAuth
and you can bring together
all the social web
services together.
The hope is write once and
use it with many different
social networks.
And the fact is OpenSocial
isn't tremendously successful
in the consumer web.
It is adopted by almost every
social network except for
Facebook, but it's not Facebook
so that does limit its
usefulness perhaps.
In the enterprise world and
specifically, the ability for a
developer to write a single
application and to have that
work in all of our different
containers that's
very important.
And that prevents vendor
lock in and it makes
programming simpler.
And it's true, you can always
use the proprietary APIs in
order to grab the social data,
but it is a fairly rich API
that OpenSocial provides
and so, why not use it.
It's pretty elegant and get as
far as you can there and then
build a little bit of extra
stuff if you need access to
the container specific data.
MARK WEITZEL: I think it's also
important to recognize that
OpenSocial is an open community
and an open standard, right?
So you're not locked
into a proprietary API.
That's one of the things that
we found very good working
together is we can come and to
say we need to advance this
specification, this way whether
it's mobiles or some of the
gadget communication or
extensions to profiles
for enterprise.
So being able to work in an
open environment, being able to
engage openly and have some say
in the direction, I don't think
we can underestimate that.
Other questions?
MATT TUCKER: Don't bore us.
MARK WEITZEL: Well a number of
us have spaces in the sandbox.
Please feel free to stop by,
ask questions, and you can
see some of the things that
we're working on there.
Thank you very much
for your time.
