I just started playing around with OpenSocial Gadgets.
Lets consider I have gadgets developed on a Portal Server and on a Jive Instance and I would like to show gadgets from the Portal Server in Jive SBS and the other way around:
1) In an enterprise context, a company would usally like to host there own gadgets. How will this be considered in Jive 5.0?
2) How would authentification and authorisation work in this context?
3) I was woundering how a simple client for the tutorial ( https://developers.jivesoftware.com/community/docs/DOC-1115) would look like?
Something like this Google example:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<script src="http://www.gmodules.com/ig/ifr?url=http://hosting.gmodules.com/ig/gadgets/file/114523496521222973753/Clock.xml&synd=open&w=256&h=210&title=a Clock&lang=de&country=ALL&border=%23ffffff%7C3px%2C1px+solid+%23999999&output=js"></script>
but for the Jive Gadget created in the tutorial: http://apphosting.jivesoftware.com/apps/smz-test-1/app.xml
I'll take a first crack at answering your questions...
#1 Portal & Gadgets
OpenSocial applications and JSR-168 / 268 portlets are two very different things. Here are some differences:
#2 App Authentication / Authorization
OpenSocial applications use OAuth. As the user installs the application into their dashboard, they authorize the app access to their information.
I'm not sure I'm following this question entirely....
When a Jive App is added to a user's dashboard, it will be rendered inside an iFrame. There is no need to create a "client", per se, because the apps are rendered in the page already.
One thing that will help in the discussion is to put forward one or two specific examples of what you would like to accomplish. Then we can help you with how to achieve the goal within the Jive Apps Framework.
If you are interested in more of a general overview, check out these docs - Jive Application Framework Overview Deck & Jive App Framework FAQ. Also, you can always contact me directly via email, and we can set up a meeting to discuss how you can leverage the framework to help your clients.
Stephan ...some thoughts on the topic...as I feel I've already come to terms with many of the aspects you bring up in this new paradigm.
Jive Marketplace houses the Gadget specs...and insures that only people from appropriate instances have access to the JiveApp; however, you can house/own your service layer...which in most cases is the more important aspect of the application.
As for the JSR-168/286...I consider OpenSocial to be a natural derivation where 168/286 leave-off. Without the requirement for a massively rigid framework underneath...OpenSocial is much more portable....re-usable....and pushes app development towards service based abstraction..in my opinion this is a good thing. It's funny though...as OpenSocial picks up where Portal left off...I see it running into many of the concepts introduced in 286..."Inner-Porlet interoperability"....so I definitely think using an analogy of Portal to OpenSocial is relevant...but I think OpenSocial gets rid of much of the complexity that was inherent in the Portal environment.
Thanks for your answers, guys!
Let me narrow down my question (#3)
Like this example I tried (from the 4.5 Jive-Studio-Plugin)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title>Jive OpenSocial Test</title>
<div align="center"><iframe id="j-gadget-ifr-2087" name="j-gadget-2087" src="http://localhost:8080/gadgets/ifr?&parent=http%3A%2F%2Flocalhost%3A8080&container=default&v=9e3f9f8e5dfb7aefdc4b014e2d9a399&lang=de&country=DE&view=home&up_widget_width=170&up_widget_height=400&url=https%3A%2F%2Fsynd.jiveapps.com%2Fsyndication%2Fopensocial%2Fv1%2Fi%2Fe0668283-5d4e-4a51-becb-400d0547c4a3%2F" style="border: 0pt none; padding: 0pt; margin: 0pt; width: 100%; overflow: hidden; height: 400px;"></iframe>
<script src="https://synd.jiveapps.com/syndication/opensocial/v1/i/e0668283-5d4e-4a51-becb-400d0547c4a3&title=OS Jive&lang=de&country=ALL&border=%23ffffff%7C3px%2C1px+solid+%23999999&output=js"></script>
Now in an Enterprise Context I could use the example client from above in order to display that gadget in complete different application. E.g. in a portlet as part of a simple Integration Szenario (show my friends, blog-posts....), correct?
So back to #3
I can take a crack at this question. I'm not sure your proposed approach would work out of the box with what we have built today. We leverage OpenSocial very heavily (even going so far as to define our own features) so I wouldn't expect a gadget to load up properly without all of the supporting functionality of the shindig container.
One thing you could try would be to reverse engineer all of the js resource injection the OpenSocial container is doing in order to developed a self-contained iframe version of your jive app, but even then, you will be missing some of the services provided by shindig for signing requests via JSON RPC.
For what it's worth, we are in the planning stages of our next release, and the goal is to introduce more capabilities to bring the social features of Jive into other enterprise systems in much the same way you describe above.
I hope this helps.
Stephan, loving the diagrams...it really helps. =) My thoughts were along the lines that you'd have difficulty stubbing out the OpenSocial container, especially since Jive handles much of this inter-server communication through Jive Connects. I was going to recommend a possible Jive Native plugin that could maybe be written...that would allow a configuration to be passed in via the querystring...and the plugin could create a view of a single plugin based off that configuration. This is purely hypothetical, and definitely see where you are coming from. I think a tool like for debugging would be a great addition to the tool set for developers...I can think of a couple of ideas such as a back-end console dashboard that serializes events as they happen in the back plus any logging etc..
In the short-term though, Erskine's idea is probably the best idea...which is to stub out the REST Services with a simple interface....albeit..I like where this conversation is going.
OK... Let me start by saying that I'm not 100% sure of the following, so take this with a grain of salt, and maybe a few beers...
Shindig uses an ifr servlet to actually kick off the gadget rendering. That URL is:
Now, that also takes some parameters, namely, the gadget you want rendered, the container, the view, etc.. AND, the security token (st=)
If you open your app sandbox and put an app on the dashboard and open up firebug, you should see something like this:
Open the twistie and you should be able to look at the request headers and get the full URL for the iFrame. You can actually cut/paste that into a browser and the iframe will render.
So, theorhetically, (translation, is your beer cold?), you could construct this. One of the keys (as I recall, and no pun intended) is to get the security token.
All that said.... I like Erskine's idea.
thanks to all of you for your help and support!!!
Yeah, using plain json via Rest or OpenClient -Call and "repainting" the frontend I considered first step in the integration
scenario. I also like this approach, because it is straight forward - even thought it needs effort on the frontend-side.
On the other hand, if the next step (we discussed) will work (@Mark: I'll try to come up with a working client of what you suggested by the end of next week), it would be I nice way of sharing simple open-social apps/gadgets across different platforms. The other aspect of step 2 would be to run a gadget developed on a different platform (e.g. on a Portal Server) the same way we discussed somewhere in Jive SBS (e.g via html widget or ftl-change). Lets see how the iFrame / js - client for the other side will look like
Third step would be to have a global enterprise open-social container (I don't think that external hosting / rendering of gadgets will work in an enterprise context) that hosts, renders and authorizes gadget coming from different platforms -not sure if this will be provided by you guys in SBS 5.0 or 5.x or maybe by an other vendor websphere portal-server, liferay or sap-portal....
Final step could be to develop consolidated gadgets that pull open-social streams / os-api calls from other platforms. I understood (corrected me if am wrong) that this is done by the jive connects api.
Hope I am not completly on the wrong track with this outline
Definitely interested in knowing if you are able to get a client working.
As for the "consolidated gadgets"... I don't think the Jive Connects API is what your are thinking of. This is more the role of the "What Matters" in Jive 5.0. Apps can publish activities to the stream using the standard API. Also, they can post activities from their "home server" via the Apps Gateway.
Thanks for putting me on the right track here, Mark!
Let me put it differently: In general a gadget can make rest or osapi calls to multiple services residing on different platforms and it could gather / aggregate / consolidate data from those platform-services, correct?
Let me give you an example of what I have in mind:
Lets assume there is a multicorporate enterprise. Each cooperation has it's own employee adress-book application developed on different platforms.
The goal would be a) to provide an opensocial platform for all cooperations and b) each cooperation should provide its own phonebook gadget and c) in the final stage maybe to provide one adress-book gadget that consolidates all other adress-books
Of course this kind of integration can be done differently (ldap, database, web-app), but the strategy is to use opensocial gadges.
OK... Let me see if I completly understand your scenario, and then see if what I say makes sense (which is never guaranteed). I'd like to revisit the Jive Connects API in a seperate reply.
<<Lets assume there is a multicorporate enterprise. Each cooperation has it's own employee adress-book application developed on different platforms.>>
So this might look like...
Three different corporate entities, each with their own address book app.It's likely that each of these systems has their own data format, APIs, security, etc. To some extent, whether these apps are OpenSocial gadgets, or some other technology, doesn't really matter because they are tied to the information that resides within their corporate boundaries. IF they were all OpenSocial applications, and IF A, B, and C, were an OpenSocial container, and IF each of them supported the same set of address fields, then that might make it easier in the long run, but there's lots of variables in there already.
Now, as I understand it, the end goal is to have a single app (gadget), that can not only be rendered in the dashboard of users from companies A, B, and C, but also aggregate address information from A, B, and C. One way to do this is to create an "Address Book Service".
The address book service will provide several things:
Does this make sense?
Stephan, coming back to Jive Connects....
One of the things that *may* be possible, is using Jive Connects. In this case, EACH Jive instance will need to be configured to use the address providers (A, B, and C). There are lots of scenarios where this isn't a big deal, for example, if thing you are connecting to is common, e.g. Salesforce, some CMIS system, et. Jive Connects abstracts out the URLs and helps manage different authentication schemes as well. (Jive Connects will also help when there are multiple instances of the same thing. In the example below, imagine C is a CMIS system, and there happen to be three instances of it (one for North America, Europe, and Asia.)
In your scenario, the information that's returned is the same kind of thing, i.e. addresses. We'd end up with three requests to the Jive 5 instance, one for A, one for B, and one for C. If there's any additional logic that needs to be performed, e.g. normalization, this will be done in the client as part of the app logic. This could be an alternate way of implementing your scenario.
From what I have learned from you, this is actually my favorite future scenario (which I had in mind as vague idea - but put it initially wrong as "consolidated gadget"
This scenario will also fits best the requiriments ( there is no need to perform big.time data normalization- some fileld name mapping maybe).
Your input helped a lot to set some things in the right context for me!
Thanks again for your effort here!
your were right! it actually works very easily that way!
Just get the widget's iframe url e.g "https://apps.app-sandbox.jivesoftware.com/gadgets/ifr...." and embed it in an iFrame.
<iframe id="jive-gadget-ifr-test1" name="jive-gadget-ifr-test1" src="https://apps.app-sandbox.jivesoftware.com/gadgets/ifr?&parent=https%3A%2F%2Fapp-sandbox.jivesoftware.com&url=http%3A%2F%2Fapphosting.jivesoftware.com%2Fapps%2Fsmz-test-1%2Fapp.xml&container=default&view=home&lang=de&country=DE&debug=0&nocache=1&v=cce7b05640a2f6461b2e922bb79a701c&st=default%3A2GO53PNkrafR8Ys1V52a9-_hUOsdqMZtlCc9Z6YxYfCFgfrrO7jsjwcDBMpw4SfoNsK1rP6CLNVuJSd8z9mQsmH_Tjf201tbOMTiCzUx56_C9nja28Ma1OU5MWsPrW9HlePS8ecI_JUTe0WCDKhd810meocE2puXvojzWlN9asEaeVMy_Kj2RRtz14iSZfzzeNzsUQ#up_work_location=&up_participant=&up_defaultModeOfTransportation="></iframe>
Of course this will only work while the session / security-token is still valid, so it would be interessiering to know how to generate the security token "st" from an OAuth Consumer Key and OAuth Consumer Secret ....
I can generate a request token from "http://gateway.jivesoftware.com/gateway/oauth2" via oAuth-Client using key and secret (e.g http://term.ie/oauth/example/client.php) but the request-token is probably just a part of the security-token?
The generation of the security token is handled by the Jive 5 instance. I'd have to check our code to see exactly how we do this, but
this is definitely a non-standard use case. Is there any way we could "swizzle" the design of your app to follow the pattern that OpenSocial apps generally use?
© Copyright 2000–2010 Jive Software. All rights reserved.