Faculty of technology management Information Technology Service Oriented Communications CT30A8901

07.12.2009

SOA, case Google

Written by: Sampo Syrjlinen, 0337918 Jukka Hilvonen, 0337840

Contents
1. Introduction ........................................................................................................................ 2 2. Service Oriented Architecture............................................................................................ 2 3. Google Apps....................................................................................................................... 2 4. Google app engine.............................................................................................................. 3 4.1 4.2 Google app engine for Python .................................................................................... 3 Google app engine for Java ........................................................................................ 4

5. Google Data Protocol......................................................................................................... 4 6. Google Apps APIs.............................................................................................................. 5 6.1 6.2 6.3 Management APIs....................................................................................................... 5 App-specific APIs....................................................................................................... 7 Using APIs.................................................................................................................. 8

7. Google vs. SOA ................................................................................................................. 8 References ............................................................................................................................... 12

1. Introduction
This document is made as an assignment to the Service Oriented Communications course in Lappeenranta University of Technology. In this paper we will first briefly cover the principles of service oriented architecture then describe Google apps, Google app engine, Google data protocol and finally discuss how Googles services fit in to the SOA paradigm.

2. Service Oriented Architecture

OASIS describes SOA in its reference model as a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domain (OASIS Standard, 2006). Individuals and organizations create capabilities to serve various needs and SOA strives to provide the framework for matching and combining the capabilities to address the needs (OASIS Standard, 2006). In software engineering the SOA model allows for applications to call upon various services across the network in a manner that frees the software developer from implementing the same services over and over again in every application. Applications and services needed are modeled after business logic of the company in question. Services are wrapped in standard interfaces and protocols that hide the infrastructure and programming language that produces the service. Once tested and functioning, services are published in a directory in order for users, applications or other services to find them. (http://www.infoworld.com/d/architecture/infoclipz-service-orientedarchitecture-soa-899). Global established SOAs have been slow to develop because of various conventions in data structure, semantics, processes and the lack of widely accepted service registries. Furthermore most services are supported in a strictly professional context which prevents normal internet users from discovering and interacting with services on the web (Schroth&Christ, 2007). Mashup is described by Wikipedia as follows: mashup is a web page or application that combines data or functionality from two or more external sources to create a new service (en.wikipedia.org). A mashup is a way of implementing SOA in web services that doesnt require extensive technical expertise. Resources used for building mashups are directed for the majority of internet users and Google is the leading provider of these resources (Schroth&Christ, 2007).

3. Google Apps
Google provides an extensible online service suite called Google apps. Google apps include services for communication and collaboration as follows:

Communication: Gmail, an unified communication application with email, instant messaging, voice and video communication. Gmail offers features such as spam filtering, large data storage (up to 25Gb with premium edition), offline client and migration tools for Microsoft Outlook and Lotus Notes. Google calendar, calendar application that supports scheduling appointments, shared projects, most mobile devices and a publishing feature.

Collaboration: Google docs, web-based application suite that includes documents, spreadsheet and presentations. Google docs works in the browser and offers the users flexibility to work regardless of their operating system or hardware setup. The same document can be accessed by multiple users at the same time permitting real-time collaboration. Supports popular file formats such as .doc, .ppt, .xls and pdf. Google sites, a tool for creating collaborative sites. Easy to use tool for setting up intra-/extranets and project sites. Sites can be build from templates without coding. Google videos, a service for hosting and streaming videos. Google Talk, instant messaging and voice conversation platform for easy and quick communication with friends and colleagues.

4. Google app engine

Google app engine is a way of running web applications on Google infrastructure. Google provides runtime environments for python and java. Hosting an application on Google app engine is free to start with but when certain limits are reached (500MB of storage and ~5 million page views a month) billing can be enabled in order for the applications to grow beyond free quota. Administrators can set billing budgets for their applications to avoid surprises in the cost of hosting their applications.

4.1 Google app engine for Python

Python was the first supported programming language for Google app engine, the supported version of Python is 2.5. Python applications communicate with Google app engine server via CGI protocol. WSGI-compatible web application frameworks are supported through CGI adapter but Google app engine also includes a simple web application framework in itself called webapp. Applications are isolated to a specific sandbox that ensures that applications do not interfere with other applications or the platform itself. Specific services are allocated

4 for the applications to communicate over the internet and to store data. Datastore and memcache are provided for storing data: datastore for persistent data storage and memcache for fast caching of responses to queries and calculations. Google app engine for python uses GQL query language or query interface to retrieve entities from datastore. Communication over the web is done using http or https protocols using some of the standard Python modules or app engine Fetch service API. Applications can also use Python mail API to send and receive email. Authentication services for the applications are handled by the Google Accounts API. Scheduled tasks can be done with the Cron service for Python. Image data is processed with the images service that allows for manipulating of image data in multiple formats. (www.code.google.com, 2009). Google provides developers with the app engine Python service development kit (SDK). With the tools included a developer can run his applications locally on his computer for test purposes. Other features in the development kit allow for uploading data to the datastore, uploading the application to the app engine service, managing datastore indexes and downloading log data from the service. (www.code.google.com, 2009).

4.2 Google app engine for Java

The second supported programming language so far is Java. Java applications in Google app engine are run in Java 6 virtual machine. Java 5 and later are supported in the Java SDK and the platform can use classes compiled with any version of the Java compiler up to v.6. Similarly to the Python environment the Java virtual machine that runs Java applications in app engine is an isolated sandbox environment. Similar restrictions in writing data to local system or setting up network connections apply to the Java environment and the Python environment. Same services such as datastore, memcache, http/https communication through URL Fetch, mail, images and Google accounts can also be used with Java. SDK for app engine Java developers contains the same functionalities as does the one for Python. Furthermore it includes a plugin for Eclipse that adds features to the Eclipse integrated development environment (IDE).

5. Google Data Protocol

Google Data Protocol is a way to extend the services offered by Google for use in other places, such as inside corporate firewall or in home network. Google Data Protocol is based on REST-style software architecture. In rest architecture, communication is based on clientserver model; clients send requests, servers operate the requests and send responses back to clients. The word REST comes to the concept from that the client can be in two states, between application states, or at rest. When the client is in rest, user can interact with the client, but doesnt consume or load the servers or network.

5 Data Syntax: Google Data Protocol is based on (and extends) various syndication standards such as Atom 1.0, RSS 2.0 and Atom Publishing Protocol (APP). Therefore, o Google Data Protocol uses HTTP-layer as default method for handling the communication (sending and receiving information between the services). o GDP uses XML (eXtensible Markup Language)-standard in the format of Atom-feed to give the information a structure. XML and Atom defines e.g. type-attribute of the information (such as HTML, Text, XHMTL) Element definitions Metadata definitions of the information o Information sent is collected to AtomPub items..

Google Data API (application programming interface) is standard interface which is used in every single more specialised API within Google Services.

6. Google Apps APIs

Google Apps are offered in three editions; standard, premier and education. The edition chosen affects to what kind of APIs users are able to handle. In standard edition, for example, only federated login service, user profiles-, contacts-, documents list-, spreadsheet-, and calendar data and calendar resources APIs are available. Standard edition is free, premier edition is about $50 per year and education edition is also free. Premier edition offers service level agreements, larger storage space compared to standard edition, enhanced support, advanced virus & spam filtering plus much more.

6.1 Management APIs

Provisioning API Google offers to APIs to handle the user management and single sign-on (SSO) of users. User provisioning (management) allows administrators to manage user accounts and synchronize Google Apps users with internal user-management system. Email Migration API With E-mail migration users can migrate email from any legacy e-mail data source into Google Apps. Users can utilize this API by defining email server data store, interface protocol etc. and then upload the email messages to a users mail box. Reporting API Reporting API allows users to watch and monitor the overall usage of Google Apps account. Users can utilize a variety of CSV formatted reports about activity, storage etc.

6 SSO (Single Sign-On) Service Google Apps SSO service uses XML-based SAML (Security Assertion Markup Language) standard for exchange of user authentication and authorization data between secure web domains. With SAML, service providers can contact different online service provider to authenticate users who are trying to get an access to secure location. In Google-SSO and SAML concept (figure 1), Google acts as a service provider who offers services such as e-mail (Gmail) or intranet-style web-pages (Google Sites). Partners of Google act as identity provider who control user information, usernames, password and other information used to identify, authenticate and authorize users for services that Google offers. Google uses also a variety of different open source and commercial identity provider solutions which help implement SSO with Google Apps.

Figure 1: Google SSO transaction model

6.2 App-specific APIs

Specific APIs exist for: Google Calendar, Gadgets, Spreadsheets and Talk. With these APIs users can customize the Apps. Domain Shared Contacts

8 The purpose of domain shared contacts API is to provide possibility for users to import external contacts that are shared to all Google Apps domain users. Shared contacts are visible to every user in the domain and all Google services have access to these contacts. User Profiles API With User Profiles API, client applications can update and retrieve user profiles in the Google Apps domain. Calendar Data API Google Calendar Data API allows users with client applications to manage calendar events in the form of Google Data API feeds. Sites Data API Google Sites API allows users to modify and manage Google Sites Data in the form of Google Data API feeds. Users can use client applications to create and modify the contents of the corporate Google Site, up- and download files, review version history and display user activity history.

6.3 Using APIs

By the nature of the API, Google Apps API is used in programming IDEs by first downloading the correct APIs, which are client libraries. The APIs are used as a tool to write client application for interacting with the services provided by these APIs. To get access to write client or web applications that use particular Google Apps service, whole Google Data Api and specific API should be downloaded. Client libraries can be downloaded from Google Code website. There are client libraries for different programming languages: Java, Javascript, .NET, PHP, Python and Objective-C. After downloading the libraries, they should be imported in the development environment, such as NetBeans or Eclipse. Also the libraries should be imported to the developed project as well.

7. Google vs. SOA

In our understanding the goal of the SOA paradigm is to enhance the efficient use of services through the web, create a service based foundation on which developers can build on and to make the use of web services faster and more flexible. This is profitable for both parties (offering / using). Service provider profit in many ways; reputation increases and interoperability of the service increases, to name a few. Clients that make use of the offered services benefit by that they dont have to invent the wheel over and over again which decreases time required for development of a particular project.

9 Gartner lists the benefits to enterprise IT from SOA as follows (Natis, 2003): Incremental development and deployment of business software Reuse of business components in multiple business experiences Low-cost assembly of some new business processes Clarity of application topology

And the mistakenly SOA attributed benefits: Simple software engineering Free integration or interoperability Technology independence Vendor independence The ultimate architecture for the modern enterprise

As with the Gartner study cited above SOA is seen and discussed mostly in business context. Google on the other hand targets and involves the end user as well as businesses. There is a distinct effort in Googles part to reach out to the masses of internet users. From the SOA service principles (Erl, 2008): Standardized service contract Service loose coupling Service abstraction Service reusability Service autonomy Service statelessness Service discoverability Service composability

From our perspective, Google adheres to following principles: loosely coupled services, abstraction, reusability, autonomy, discoverability and composability. Google uses XML, Atom, APP, HTTP and JSON standards which all are internationally developed and standardized. Google Service APIs are not grounded to special programming languages: they can be used with Java, .NET, PHP and Python. This adheres to abstraction principle of SOA principles. Only counteracting property in the autonomity of Google Services is that someone (preferably every user of the services) has to have Google account to be able to use the services. Otherwise, Google Services are very autonomous and interoperable to legacy- and partners systems and services. The discoverability of Google Services comes from the use of programming-language specific client libraries, which have to be downloaded before using them. Discoverability is not as efficient as in e..g. Web Services, but still very usable.

10

Figure 2: Googles principles

When examining the Google approach from the business perspective, Googles services are very well thought of. Google can offer their services to individual users and education organizations for free, and the price for companies is not high. This is due to the popularity of Google Search engine, business and personal services. The popularity of these services wouldnt perhaps be so overwhelming if the services offered wouldnt be designed that way that; a) they are easy to use, b) they are extensible and c) they are easily integrated and combined to other services, legacy systems and to each others. Very good examples of good services of Google are the Google AdWords and AdSense. With AdWords and AdSense corporations and individuals can advertise their products and services either directly in Google Search Engine results or make some money by attaching the AdSense-service to their websites. Ad-Services are very easy to use and attach to existing code that is one factor explaining the popularity of Google Services.

11 The following figures 5. and 6. illustrate the similarities in SOA and Google services structure.

Figure 2: Google Service Bus and Discovery

Figure 3: SOA Bus Concept (Porras 2009)

12

References:
Reference Model for Service Oriented Architecture 1.0. 2006. OASIS Open. 31s. http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf Schroth, C. Christ, O. IEEE International Conference on Services Computing, 2007, Brave New Web: Emerging Design Principles and Technologies as Enablers of a Global SOA, 9-13 July, s. 597 604 Wikipedia, 2009. Representational State Transfer. From: http://en.wikipedia.org/wiki/Representational_State_Transfer 09.12.2009 http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid), 08.12.2009 Google, 2009. Google Apps. From: http://www.google.com/intl/fi/apps/business/index.html 09.12.2009 Google 2009. Google Apps APIs. From: http://code.google.com/intl/fiFI/apis/apps/overview.html 09.12.2009

13 Google 2009. Google Appengine. From: http://code.google.com/intl/fiFI/appengine/docs/python/overview.html 09.12.2009 http://code.google.com/intl/fi-FI/appengine/docs/java/overview.html 09.12.2009