Już 62 483 użytkowników uczy się języków obcych z Edustation.
Możesz zarejestrować się już dziś i odebrać bonus w postaci 10 monet.
Jeżeli chcesz się dowiedzieć więcej o naszym portalu - kliknij tutaj
Jeszcze nie teraz ZAREJESTRUJ SIĘlub
Zaloguj »
ZAREJESTRUJ SIĘ
Nie masz konta?
Google Campfire One: Apps Marketplace, Part 2
Poziom:
Temat: Media
>> How do we do that? Well, we use the open
standards that have emerged for distributed
identity on the web. You all know where I'm
going: OpenID. Open ID is the way that you
can take authentication that's maintained
in one place and rely on it in other applications.
So when you build your application, you build
in the cap--the support in your app using
either just the standard or any of the libraries
out there to be an OpenID-relying party. You
build that into your application. You put
a couple of lines into the manifest that say,
"Here's how I'm using single sign-on by OpenID,
and here's my OpenID end point to allow that
to work. The last point of integration that
I'm going to talk about at this level is around
getting access to data. As Vic said, it's
terrific to build a great app, it's terrific
to have all the UI integration so your users
can get between Google Apps and your app and
go back and forth. But what about actually
being able to work with the information that
they are stored--that they have stored in
Google Apps? What if you have an application
that maybe wants to create calendar entries
on behalf of your users, so that the information
they're working with in your application can
be integrated into Google Calendar? Or what
if your application wants to let your users
pick from a list of their contacts that they
store in their Gmail address book, and you
want them to be able to pick from that list
to do some action in your application? Before
I tell you the answer, I want to make sure
people understand the challenge of securely
accessing that data. This is a trust relationship
that you're looking for in your application.
So your application wants to get at some data,
and that data is stored on Google servers.
But it's not Google's data. The data belongs
to a particular user at your customer, and
is administered by the domain admin for that
customer. So what you really want to do is
have your application ask the domain administrator
for permission to access the user's data for
the purposes of your application, and then
make sure that that agreement is passed on
to Google in a verifiable way, so the information
that you need is available, but only the information
you need. That's a four-way trust relationship,
where all the parties have to be able to get
that right. The last thing you want to do
is invent the answer to that kind of four-way
trust relationship yourself. Again, the good
news is the community has invented the answer.
OAuth is the emerging standard for how you
do delegated trust, how you can do authorization
on the web in a secure way for multiparty
trust. And Google APIs use OAuth for authorization.
What we've done in the Marketplace is built
that OAuth, the OAuth grant of trust capability,
into the Marketplace flow. So what your application
does--you're gonna hear a theme here--puts
a few lines in the manifest. You implement
the code in your application to actually access
our APIs using OAuth, and then you put code
in the manifest that says, "Please." You say,
"My application would like access to your
user's calendars, and here's why." In this
case, because I would like to display their
next calendar appointment. By putting the
information, the request for trust in the
manifest, the domain administrator--your customer--is
able to grant you that trust so your application
can access the information on behalf of your
users who are our users; are joint users.
All right, we've built a manifest. We've taken
a simple few points of integration. We've
put them together into a single XML file.
I'd like to ask Ryan Boyd to come up here,
and we're gonna switch from slides to a demonstration
now. So this is a manifest that we've built
for a simple Hello World application. Well,
Ryan is a developer, and he's actually built
a simple Hello World application. So if we
could switch to the demo, what we're gonna
see now, here's the real version of the manifest.
This is what Ryan's been working on. So he's
built his application, he's described the
integration in his manifest file sitting in
a high-tech text editor. Always wondered which
side of the Emacs versus vi war you were on.
Now I know. Um, he's built his application.
So now what does he want to do? He wants to
put it in the Marketplace. So let's switch
to the Marketplace, and you're gonna see now
the same Marketplace UI that Vic showed you
a picture of before. This is the live Marketplace
UI. Has the usual tools you'd expect in a
marketplace that your customers, the domain
admins, use to find the apps they want and
install them. But you'll also notice, if you
look closely at the top right, that because
Ryan is logged in as a vendor, as a software
developer, and because he has previously registered
himself as a vendor with the Marketplace,
he has a new link to his vendor profile. So
if he clicks on that, we're now going to see
Ryan's vendor page. So when we click on the
vendor profile we see here's there information
that Ryan has entered about his company. Contact
information, whatever he wants to put in about
his company. But you'll also see that he doesn't
have anything for sale yet. He hasn't yet
created any apps for sale in the store. Well,
let's do that. Let's go ahead and create his
first listing. So when he's creating a listing,
the first thing that he's going to do is take
that manifest file that he built, copy the
information from the manifest file, and he's
going to paste it into the listing page. There
it is, pasted in. We've now done all the hard
work. Technically, we're done. We're integrated.
What's left is marketing. What's left is let's
tell Ryan's customers, his prospective buyers,
what they need to know to discover and choose
his application. So we'll start by filling
in some information. What kind of application
is this, so we can find it by browsing? Let's
type in a name. Let's put in some of the marketing
material that Ryan's crack marketing team
has been working on to make sure that this
is one of the more compelling apps. He probably
has been working with a pricing consultant
for a while to come up with a business strategy
for making money on his application. And he's
also, I'm sure, been working with a legal
team to make sure that his terms of service
are iron-clad boiler plate, and, you know,
don't allow any exemptions. So terrific. He's
got that in there. If you look at the top
left of the listing page, he has the ability
to put in some more information. This is all
marketing and promotion information, describe
the benefits of his application. He can put
in some media to have a screen shot of his
app. Maybe a video of his app in progress.
Whatever information he wants to use to help
his buyers discover and choose his app and
decide this is the app for them. All right,
he's filled in his listing page. Now his next
step is to save it and preview it. Make sure
that the listing looks the way that he wants
it to look. So we're saving the listing. The
Marketplace is gonna show a preview. Here's
what his listing would look like. He takes
a quick look over it. He sees the information
he entered. He sees a little bit of information
he didn't enter explicitly. If you notice,
under the add-it-now button under Specifications,
it says this application asks for access to
Calendar, because it uses Calendar for part
of its integration. That was extracted from
the manifest. That's information that we know
about, technically, what the app does so we
can put it in the description of the app.
All right, let's submit it. We have a listing,
looks good. Submit it for approval. This kicks
off the quick approval process where we go
through and validate the listing, and turn
it on live in the Marketplace. That might
take a couple of days. Rather than waiting
for a couple of days here, Ryan has previously
published another copy of this app. And now
you'll see he's logged in as the admin and
a customer. So what we're going to do now
is walk through the experience of a prospective
buyer of Ryan's application. So this prospective
buyer, this admin at Acme Systems, has been
looking for a Hello World app. They're looking
for the best one. And they searched in the
Marketplace, and they found a killer description
of Ryan's application. They said, "This looks
like the one I want." So the admin says, "Yes,
I would like to add this application to my
domain." So let's add it. First thing you
have to do, of course, is say what is your
domain, where are you trying to install it?
So Acme Systems Inc. wants to install it.
Now, because we're trying to install an application
on our domain, we have to prove that we are
the admin, that we have the rights to install
it. And all that's left is three clicks. The
first click is let's agree to the terms of
service of this application. So yes, we accept
these terms. These are the terms that you,
as a software developer, have put into the
Marketplace for your buyers to use. Second--we've
been talking about data access-- Well, this
is where the domain admin sees this application
would like to display your next upcoming Calendar
appointment, and therefore is requesting access
to the Calendar a.p.i. to get access to that
information. Sounds good. Let's grant access.
The app is now installed, and all that's left
is to enable it. Flip the switch. Let's turn
it on. So the admin of Acme Systems has now
installed this application. They could manage
it from the control panel, if they wanted,
along with all their other apps. Or they could
go, as an end user, directly to one of their
applications. Let's go ahead, and let's go
to-- Let's go to Gmail, in this case. So now
I'm just a user of Acme Systems, logging in,
looking at my Gmail. I have my regular mail.
And at the top left, I have my nav bar, where
I can see what applications--and look, there's
a new entry in the menu: Hello World. Let's
go ahead and launch this brand-new application.
And now we're launching the application using
the link that we specified in the manifest
to get to the application. No sign-on dialogue,
because we're already signed in. And the app
is actually showing us that it knows who we
are, to show that. And because the app was
granted access to Calendar, can find out that
Mary's next appointment is to join us in eating
some s'mores right after this event ends.
So that's the flow. Build your app, integrate
it, describe the integrations--the manifest--
listen in the Marketplace, sell it--your users
can use it. It's that simple. Thank you, Ryan.
So if we could go back to the slides. You
know, what you just saw was the complete flow
of everything it takes to integrate. But you
saw that flow on a complete sample application.
Just a test application to show the capabilities.
I'd now like to bring up Martin and Mindy
from Intuit, who are going to show you how
using...
