OpenSocial development practices, Part 2: Apache Shindig Overview

2011-04-17  来源:本站原创  分类:Development  人气:138 

Reference Note: the original from http://www.ibm.com/developerworks/cn/web/1104_sunqy_opensocial2/index.html , for the convenience of my reading, the text format is slightly adjusted.

Shindig Profile

Shindig was first launched by Google in 2007, and as of iGoogle Gadget container. Shindig as a reference container, you can run on any web site to support the OpenSocial social networking applications. Google Gadget support at Shindig OpenSocial specification and the specification. Interpretation of the Chinese Shindig grand social dance, as a reference implementation of OpenSocial specification name of the project is very appropriate. OpenSocial provides a developer a common API, API developed based on these social applications (Gadget, iWidget) can run on any OpenSocial specification supports social networking sites.

Shindig's main purpose is to help these social networking sites in a very short period of time to achieve the support of the OpenSocial specification, making social networking applications developers do not have to care about the platform conversion. Since the end of 2007, the Apache Shindig, an open source project, you as the OpenSocial specification and reference implementation to support OpenSocial application container constantly updated, the latest release version is 2.0.1, to achieve the OpenSocial 1.1 specification. Many social networking sites are based on the OpenSocial Shindig realize their capabilities, such as LinkedIn, hi5.

Another goal of Shindig is to support the implementation of languages, there are two versions of Java and PHP, Java version is based on Java Servlet Stack implementation, as well as some examples of this code are based on the Java version.

Shindig's main components include:

  • Gadget Container JavaScript (Gadget container, JavaScript libraries): information such as UI to show, security, interactivity, and other related features extend the functionality.
  • Gadget Rendering Server (show the Gadget server): responsible for parsing the Gadget XML, into a browser using HTML and JavaScript.
  • OpenSocial Container JavaScript (OpenSocial Container JavaScript libraries): Gadget Container JavaScript library based on, in the client's OpenSocial container provides OpenSocial related functions, such as access to People, Activity, AppData and other relevant social data.
  • OpenSocial Data Server (OpenSocial Data Server): provides a container-specific server-side interfaces, including those based on Rest / RPC protocol Services, for access to People, Activity, AppData and other relevant social data, and provides a clear extension points, other sites could then implement their own services.

Shindig's component architecture shown in Figure 1:

Figure 1. Shindig component architecture diagram
OpenSocial development practices, Part 2: Apache Shindig Overview

Gadget by the characteristics of XML and its use constitutes a JavaScript library, the default Gadget Gadget container will be placed inside an iframe to show. When the container ready to Render a Gadget Gadget, the first will get the Gadget of the metadata information, and then the corresponding information through the composition iframeUrl, and the URL set to the iframe src, then it will trigger the server-side titled "xml-to- html "of the servlet that Gadget Rendering Sevlet responsible for handling the request and the final return HTML. JsonRpcServlet and DataServiceServlet handle requests related to OpenSocial, DataServiceServlet handling Rest request, JsonRpcServlet handles RPC requests in the background, they share the same implementation. OpenSocial OpenSocial Hanlder handle requests related to the specific individual related by the following Service implementation. Middle JsonDBOpenSocialService is a realization of a concrete realization of the various Service interfaces to Json file as a data source.

Shindig project based on the Maven build, under the following sub-projects (based on Jave version of the source):

  • shindig-common: The project provides some basic and common method.
  • shindig-gadgets: The project is Gadget Render the Server-side implementation, including parse XML, parse Gadget which uses the characteristics of rewriting the content, return the HTML to the client and so on.
  • shindig-social-api: The project is OpenSocial the Server-side implementation of related functions, providing a People, Activity, AppData, etc. Service and Handler.
  • shindig-smaples: This project is an implementation of the OpenSocial JSON-access data sample.
  • shindig-server: This project is the project's Server-side configuration, including the web.xml and so on. Upon completion of the project to build a war file is generated as a Web application deployment to the server.
  • shindig-features: The project has nothing to do with language, are the Client-side JavaScript libraries, including Gadget container, OpenSocial container used in the JavaScript library, as well as some unused features, this article will highlight some common features.
  • shindig-extras: This project has nothing to do with language, can be seen as available to developers to extend the Shindig, a reference. The entire project is based on Shindig Guice framework, Guice is a Google developed a lightweight dependency injection framework. When users need to expand Shindig realize their functions or features, you can complete with the original Shindig isolation, developing their own Guice module like the last with Guice dependency injection can make the appropriate configuration.

Back to top

New Gadget container is more simple and convenient, the corresponding components shown in Figure 4: Use containers to show the new Gadget Gadget's Code Listing 2:

Figure 4 The new Gadget container component diagram
OpenSocial development practices, Part 2: Apache Shindig Overview

New Gadget container compared to the shindig-container clearer, more simple to use, just create a gadget site, then you can call navigateGadget. 2.0.1 version released in the shindig, the new Gadget container to use several small bug, if you want to use the latest Gadget container, please download this article provided the container for the new Gadget patch. New Gadget containers provide a good layered structure and scalability, the user can refer to realize their Gadget of the container vessel. This series of articles will describe how this new Gadget on the container embedded in the current page, to show a Gadget, instead of using the iframe.

OpenSocial OpenSocial container used to create the request, for example: newFetchPersonRequest, newFetchPeopleRequest, newFetchPersonAppDataRequest, etc., defined as Person, Activity, Phone and other objects. Early requests are usually through:

var req = opensocial.newDataRequest();
req.add(req.newFetchPersonRequest(opensocial.DataRequest.PersonId.VIEWER),'viewer');
req.add(req.newFetchPeopleRequest(opensocial.DataRequest.Group.VIEWER_FRINENDS),
    'viewerFriends');
req.send(callback); 

To send the request. Currently use more of is to use osapi:

var batch = osapi.newBatch();
var fields = ['id','age','name','gender','profileUrl','thumbnailUrl'];
batch.add('viewer', osapi.people.getViewer({sortBy:'name',fields:fields}));
batch.add('viewerFriends',
    osapi.people.getViewerFriends({sortBy:'name',fields:fields}));
batch.execute(callback); 

Back to top

Shindig REST implementation outlined in the detail.

Back to top

Shindig OpenSocial API description provided by

Shindig provides two sets of the OpenSocial API: Rest and JSON-RPC for. The following are to be introduced for both API: Rest of the API is used for server to server interaction, JSON-RPC server is mainly used for interaction with Gadget, a lot of services such as osapi through JSON-RPC API call completed.

JSON-RPC Interface

Shindig RPC to achieve all the necessary services, including People, Activity, Appdata, Messages, and System. See a complete list of the methods outlined Shindig in tables and diagrams. This article only a few examples to illustrate the following:

Get all the available RPC services: http://localhost:8080/vulcan/shindig/rpc?method=system.listMethods, returned the following results, you can see all the Shindig support services.

Listing 3. All available RPC services

{"result":[
        "samplecontainer.update",
        "gadgets.supportedFields",
        "userprefs.create","http.head",
        "http.post",
        "activities.supportedFields",
        "gadgets.defaultRenderType",
        "activities.delete",
        "appdata.update",
        "messages.delete","http.delete",
        "userprefs.update",
        "activitystreams.delete",
        "activities.get",
        "gadgets.metadata",
        "messages.modify",
        "activitystreams.supportedFields",
        "activities.create",
        "messages.create",
        "activitystreams.create",
        "cache.invalidate",
        "people.supportedFields",
        "http.put",
        "activities.update",
        "activitystreams.get",
        "userprefs.get",
        "appdata.delete","http.get",
        "gadgets.token",
        "activitystreams.update",
        "samplecontainer.create",
        "appdata.get","messages.get",
        "system.listMethods",
        "gadgets.tokenSupportedFields",
        "people.get",
        "samplecontainer.get",
        "appdata.create"
]} 

All of these RPC services are dynamically bound to the final osapi, client users can invoke the corresponding method through osapi services, such as osapi.gadgets.metadata (request). Execute (callback), osapi.people.get (request) . execute (callback), osapi.appdata.update (request). execute and so on. All of these can either be completed by osapi to call, or directly through the RPC call to complete, eventually corresponding to the Handler in the server side to handle, such as activity-related services can be found inside the ActivityHanlder, gadgets can be associated inside the GadgetHanlder found. The following code to gadgets.metadata example to illustrate:

Listing 4 using osapi access metadata

var gadgetUrl = "http://localhost:8080/container/sample-pubsub-2-publisher.xml";
var request = {
    'container': "default",
    'ids': gadgetUrl,
    'fields': [
        'iframeUrl',
        'modulePrefs.*',
        'needsTokenRefresh',
        'userPrefs.*',
        'views.preferredHeight',
        'views.preferredWidth'
    ]
};
osapi.gadgets.metadata(request).execute(function(response) {
    if (response.error) {
        console.debug("error when getting metadata!");
    } else {
        for (var id in response) {
            response[id]['url'] = id; // make sure url is set
        }
        var gadgetInfo = response[gadgetUrl];
        console.debug("iframeUrl is :",gadgetInfo.iframeUrl);
        console.debug("required features are :",gadgetInfo.modulePrefs.features);
        console.debug("gadget title is :",gadgetInfo.modulePrefs.title);
    }
}) 

The result is:

iframeUrl is: http://localhost:8080/gadgets/ifr?
    url=http%3A%2F%2Flocalhost%3A8080%2Fcontainer%2Fsample-pubsub-2-publisher.xml
    &container=default&view=%25view%25&lang=%25lang%25&
    country=%25country%25&debug=%25debug%25&nocache=%25nocache%25&
    v=16b40aa73ad5c7cf1769dcdc4f4b4e7a
required features are {"pubsub-2":{"required":true},"core":{"required":true}}
gadget title is Sample PubSub Publisher

The same results can also directly invoke the RPC access in the browser, type: http://localhost:8080/rpc?method=gadgets.metadata & container = default & ids = http://localhost:8080/container/sample-pubsub- 2-publisher.xml & fields = iframeUrl, modulePrefs.features, modulePrefs.title, the results obtained are as follows:

{"result":{
    "http://localhost:8080/container/sample-pubsub-2-publisher.xml":
    {"modulePrefs":{
        "title":"Sample PubSub Publisher",
        "features":{"pubsub-2":{"required":true},"core":{"required":true}}
    },
    "iframeUrl":"http://localhost:8080/gadgets/ifr?url=
        http%3A%2F%2Flocalhost%3A8080%2Fcontainer%2Fsample-pubsub-2-publisher.xml
        &container=default&view=%25view%25&lang=%25lang%25
        &country=%25country%25&debug=%25debug%25&nocache=%25nocache%25
        &v=16b40aa73ad5c7cf1769dcdc4f4b4e7a"
    }
}}

Request access to through metadat Gadget of iframeUrl information, you can directly set to the iframe src, which is the practice of the new Gadget container. REST API to do with the following comparison, we cite a list of all user requests a list of friends: http://localhost:8080/rpc?method=people.get&userId=john.doe&groupId = @ friends.

Listing 5 using rpc API to access the user's buddy list

{"result":{
    "totalResults":3,"filtered":false,"sorted":false,
        "list":[
            {"name":{"givenName":"Jane","formatted":"Jane Doe","familyName":"Doe"},
                "id":"jane.doe"},
            {"name":{"givenName":"George","formatted":"George Doe","familyName":"Doe"},
                "id":"george.doe"},
            {"name":{"givenName":"Maija","formatted":"Maija Meikäläinen",
                "familyName":"Meikäläinen"},"id":"maija.m"}
        ],
    "updatedSince":false
    }
}       

REST interface

Shindig REST implements four types of service: People, Activity, Appdata and Group. See a complete list of the URI Shindig overview of the tables and diagrams. Below to obtain user's friends list, for example, corresponding to the REST request to: http://localhost:8080/social/rest/people/john.doe/ @ friends.

Listing 6. Using the REST API to access the user's buddy list

{"startIndex":0,
    "totalResults":3,
    "entry":[
        {"name":{"givenName":"Jane","formatted":"Jane Doe","familyName":"Doe"},
            "id":"jane.doe"},
        {"name":{"givenName":"George","formatted":"George Doe","familyName":"Doe"},
            "id":"george.doe"},
        {"name":{"givenName":"Maija","formatted":"Maija Meikäläinen",
            "familyName":"Meikäläinen"},"id":"maija.m"}
    ],"itemsPerPage":3
} 

Back to top

Introduction of features provided by Shindig

Shindig provides the basic features in shindig-feature of this project which, while some extended features in the shindig-extra items inside. Gadget OpenSocial specification according to which the core specification, the Gadget of the world in two contexts (context): one is the Gadget own context; one is Gadget Gadget which can be embedded into the context of the container. shindig default iframe to show the form of a Gadget, so the two contexts is completely isolated. Outside the context of the container as container, which is called the context Gadget gadget. This shindig features which are based on both context to form, each feature has a feature.xml to describe the characteristics of the name depends on the characteristics and properties used in the JavaScript file. And for different contexts may require different JavaScript files.

To pubsub-2, for example, the following display is a pubsub-2 defined by this feature feature.xml. Container is needed for pubsub-2-router instance of this file a openajaxhub, for gadget requires pubsub-2 to create a new hubclient. Therefore, the feature for two different contexts define different JavaScript files.

List of properties defined 7.Shindig

<feature>
    <name>pubsub-2</name>
    <dependency>globals</dependency>
    <dependency>org.openajax.hub-2.0.5</dependency>
    <gadget>
        <script src="pubsub-2.js"/>
        <script src="taming.js"/>
    </gadget>
    <container>
        <script src="pubsub-2-router.js"/>
    </container>
</feature> 

shindig features can be divided into the following categories:

  • One is surely will be used to show a Gadget features, such as globals, shindig.auth, core, rpc.
    • globals define some global variables such as gadgets, shindig, osapi.
    • shindig.auth provides a setting, access, and update security token of the method; security token is a shindig of the basic authentication mechanism, which includes the viewer, owner, appid, domain, container, gadgetUrl and other information.
    • show a core feature provides the core functionality needed Gadget, including io operation, user settings and so on.
    • rpc rpc call feature provides the entire implementation. shindig default iframe to show the Gadget, if the Gadget requires access to some of the methods defined outside the container, you need to do an rpc call.
  • Gadget container is used in a class of features, such as the shindig-container, container.
  • One is related to some of the OpenSocial features, such as osapi, opensocial-data, opensocial-reference and so on.
  • One is some of the util features, such as shindig.uri, shindig.xhrwrapper, xmlutil.
  • One is the server-side implementation of features such as content-rewriter and security-token.
  • One is the user interface more with the Gadget-related features, such as settitle, tabs, views, minimessages, flash.
    • settitle the name suggests is to set the title of Gadget, Gadget using this feature which can be set dynamically as needed Gadget title.
    • tabs inside the Gadget features support easy to create multiple tab and the corresponding content.
    • views can provide a feature to switch between multiple view feature. We know that Gadget can define more than one view, use the views feature can be free to switch between multiple view.
    • minimessages feature provides several types of cue information, for example, show how long the message will automatically disappear tips.
    • Gadget flash feature which can be embedded in the flash file.
  • Another type is to be used for communication between Gadget features, pubsub and pubsub-2.
  • Another feature is oauthpopup, OAuth authentication to provide support for the shindig a feature.

The next article in this series will detail pubsub-2 and OAuth-related features.

Back to top

Conclusion

The first article in this series describes how to write his first OpenSocial Gadget, and the basic concepts, this article focuses on the Shindig OpenSocial reference implementation of the basic architecture, client and server-side processes and basic characteristics.

相关文章