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.
Alexander Smirnov's personal Weblog 