Alexander Smirnov’s personal Weblog

April 12, 2010

Google Apps Web Services Hub

Filed under: Semantic web, Uncategorized — Tags: , , — alexsmirnov @ 12:04 am

Last Wednesday, I was on the Google Apps Marketplace meetup. There were awesome presentations from Google’s Scott McMullan who gave a clear view about Marketplace business model and its opportunities for developers, and four excellent examples from companies that already offer their applications there. While I was listening about these applications and services offered by Google, I got an idea that there something is missed. Although each product has tight integration with Google Apps, they have no clue about others, so it’s hardly possible to associate sales contract from myERP with manymoon project, or use JIRA Studio for custom software development contract. MyERP has no payroll feature, but such applications are already presented in the Google Marketplace, yet they cannot be easy integrated with myERP accounting. Without such interaction capability, customers get only set of the independent applications, but not a solid corporate system.

Of course, applications may expose their own web services that can be used by others. For example, JIRA studio can use OpenSocial API ( not sure about RPC that is available for its standalone product), and someone can use it in another project. But, it’s hardly possible for any application to know about all possible partners and create connectors for all of them. Also, each application has to provide its own management tool there user can configure what are included into his corporate domain and how to use them. It would be also a nightmare for an administrator who have to use couple of different management tools just to append new application to domain or change user permissions.

The solution is well known in the software development: that is service dispatcher architecture. Any application should connect to the single controller that knows about all services in the domain and transfer request to appropriate endpoints. That can be REST-style service that only perform lookup tor the desired type of services and return response with service description and endpoint address so application can call discovered services directly.

There should be common contract for all services, so different applications can call any endpoint and understand its response. On the other hand, such contract should be extensible to easy introduce new type of service. I see that as some kinf of the Semantic Web ontology ( Semantic Web Services Registry ), there any developer can introduce a new type of service as extension of the existing one and register it on the service dispatcher. Other application can use it as the base type, while another will be able to get extended information. For example, accounting system can export its data in XBRL format, that extends XML+Stylesheet content, and latest may inherit simple file service. In this case, the same service can be used by an application that simple attach its response to the mail message because any file can be used there. Another consumer can display the same report on web page as result of XSLT transformation. Finally, any financial service that recognizes XBRL format may leverage all available information. In the opposite direction, the same ontology should also provide information about content types that can be accepted by the client, so service endpoint will decide proper format according to the request “Accept” header.

It’s not necessary for such REST web service hub to be provided by Google Apps. It can be independent application compatible with Google Apps contract, that uses OpenId and Oauth to authenticate, with its own management system. Any application in the customer domain can register its services and their descriptions, so another client would get it by request for particular type of services. That hub should also maintain user permissions, so domain administrator can use the single management console to configure services and grant or disable particular users to use some services. For applications that does not follow common format, or do not included into the domain there would be converters that seamless translate calls to target. For example, Salesforse clients can use their account from Google applications. Of course, there should be compatibility kit to test services provided by the third party applications, and libraries for most popular computer languages that makes service development easy.

The hardest part of such project will not be a technical implementation, but carefully designed format of services, and encouraging providers to use these standards. Really, the success mostly depends from how many third party developers will support proposed services. But if they do, all parts participated to the Google Apps Marketplace will be winners: Consumers would get more integrated solution that can improve business performance; developers can use already existing services to increase capabilities of their products, and they can faster put applications to market because it is not necessary to implement already existing features. Finally, it will increase Google Apps market and make it more profitable for Google.



  1. Quality posts is the key to invite the visitors to go to see
    the site, that’s what this website is providing.

    Comment by Elliott — August 10, 2014 @ 10:51 pm

  2. Hi! I could have sworn I’ve visited this site before but after browsing through a few of the articles I realized it’s new to me.
    Regardless, I’m certainly happy I discovered it and I’ll be book-marking it and checking back frequently!

    Comment by colon cleansing — May 15, 2013 @ 7:54 pm

  3. Yesterday I saw unusual case in my city. One guy carried lumber on a convertible Lexus sportcar. Of course, it is possible to use heavy duty track for personal commute or expensive sport car to haul freight, but it is far away from any reason, isn’t it ?
    UDDI and CORBA have been developed for corporate use, that is little different from the Google Apps ecosystem. Google already has about 25 millions of users, and it grows by 3000 users every day, so it is likely to have tens of millions users for the such system while any corporate system does not exceed hundreds of thousands users. Not SOAP nor CORBA scalable for millions of user, yet REST with HATEOS-like architecture there most of data flow going directly between consumers and producers has a chance to serve such amount of requests. Any existed ESB solution will stalled in its bottleneck that is the bus there all request should be dispatched.
    In addition, any corporate SOA solution runs in the predictable environment with less or more stable configurations. For the apps included in the Google Marketplace, there is no single point of control, so service system should be extensible and support different types of data and hundreds of independent service providers; it is why semantic-web architecture is only possible solution. Also, the success of the Google Marketplace is hardly depend of the number of participated providers. REST services are easy, so much more developers can participate to that system.
    Optimal technical solution depends of the business model. Google Apps Marketplace is yet unique, so it requires its own unique solution.

    Comment by alexsmirnov — April 17, 2010 @ 11:24 pm

  4. The use of service discovery, like UDDI or CORBA naming/trading services, predate REST. This observation doesn’t argue against your ideas, but points out that you ideas will work equally well with REST or WS-style web services. In addition to exposing services, it would be useful to expose events and event handlers. I suggest that WebHooks should be integrated into this approach.

    Comment by Robert Folkerts — April 15, 2010 @ 5:59 am

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

%d bloggers like this: