WSO2 Gadget Server 1.3.0 is out with a bunch of awaited features

This is a short post aiming to notify the new features of WSO2 Gadget Server 1.3.0 which was released recently. The product is popular among the community as a gadget rendering platform, which provides a presentation layer for heterogeneous enterprise services based on Google Gadgets Specification and Apache Shindig. As an enterprise presentation product, the Gadget server is now fully fledged with number of awaited features such as,

And some of the important features of WSO2 Gadget Server are,

Try out The Gadget Server 1.3.0, and provide your feedback to make it better and brighter. You can provide feedback, report bugs and join in with architectural discussions at any of WSO2 public lists and also you can have a better understanding via going through many articles at WSO2 Oxygen tank.

Advertisements

Gadgets On the Cloud

There is no doubt that JavaScript/XML gadgets make a great presentation layer over the web with increasing amount of data floating around. The ability of which these gadgets can be embedded in any place over the web, provides a great flexibility, and a wider reach. Google does this quite nicely with their iGoogle gadgets, enabling the gadgets to be embedded in almost any web page. The success of this great idea, would be only logical if all the data, services and mashups are also available over the web with open access or maybe authenticated access. This is where a cloud story fits-in, and this the very reason why Google can do it quite easily.

However, what if you want to do everything from the scratch and also provide a great presentation layer for the users. For an instance, lets say you have a lot of financial data within your enterprise, and you need to provide some of these to your customers, to general public and some for your employees. To do this, you will have to create appropriate data services, maybe mediate or transform some data, integrate with some legacy data sources, create some business work flows, mashup them with some 3rd party services like Google finance or charts and finally expose the end results to the targeted user group. This is where WSO2 Stratos PaaS comes for your rescue 🙂

If your requirements are such, you will need a strong middle-ware platform to full fill all the above tasks, and if its all on the cloud, you will not have to worry about anything other than writing your business logic. Once the business logic is correctly compiled, you can Mashup some of your data with external service APIs, and then write the presentation logic purely on javascript and xml as XML Gadgets and expose them to the users you need. Once the gadgets are published on WSO2 Cloud Gadget Server its just a matter of linking them up in any web page you want over the web.

https://gadget.cloud.wso2.com/ifr?container=default&mid=3&nocache=1&country=US&lang=en&view=default&parent=https%3A%2F%2Fgadget.cloud.wso2.com%2F&debug=1&up_=undefined&st=john.doe%3Ajohn.doe%3A10717%3Ashindig%3Ahttp%253A//gadget.cloud.wso2.com%253A80/registry/resource/_system/config/repository/gadget-server/gadgets/ngeo_vid.xml%3A0%3Adefault&url=http%3A%2F%2Fgadget.cloud.wso2.com%3A80%2Fregistry%2Fresource%2F_system%2Fconfig%2Frepository%2Fgadget-server%2Fgadgets%2Fngeo_vid.xml#rpctoken=1304649864https://gadget.cloud.wso2.com/ifr?container=default&mid=0&nocache=1&country=US&lang=en&view=default&parent=https%3A%2F%2Fgadget.cloud.wso2.com%2F&debug=1&up_=undefined&st=john.doe%3Ajohn.doe%3A10197%3Ashindig%3Ahttp%253A//gadget.cloud.wso2.com%253A80/registry/resource/_system/config/repository/gadget-server/gadgets/soa.xml%3A0%3Adefault&url=http%3A%2F%2Fgadget.cloud.wso2.com%3A80%2Fregistry%2Fresource%2F_system%2Fconfig%2Frepository%2Fgadget-server%2Fgadgets%2Fsoa.xml#rpctoken=1304649864

The above two gadgets are taken from WSO2 Cloud Gadget Server and have linked in to this blog, to convince about the great flexibility and reach it can add-up. You do not need to use the Cloud Gadget Portal as the only place for your data to be presented (Of cause if you are not using other gadget server specific privileges such as inter-gadget communication etc). You can simply use the Gadget Server as your own gadget repository, and encourage users to discover the gadgets and embed them into their own web pages over the web.

To sum up the story I would say, try-out Stratos, try out the available services and you will definitely find out more use cases, and creative ways to use the platform and leverage the advantages of the cloud

Web Scraping & Parsing HTML to XML in Javascript

Today I was working on a customer POC and happened to create few Google gadgets to visualize selected data sets from *.gov.uk sites. The scenario which is implemented was, mixed with inter-gadget communication and content search over data.gov.uk sites. I created three simple gadgets which communicates with each other, and one acted as the controlling gadget which pushed the search parameters to other two gadgets. The two content gadgets showed UK (1) primary school information and (2) electoral information. The pushed parameter was the postal code of different parts of UK. The direct.gov.uk has a form based implementation of this.

The Requirements for the POC was, simple and we already had working samples of such a scenario at WSO2 library.

  1. Show how one gadget can pass the context to other gadgets
  2. How gadgets can harvest data in various formats (in my previous post I explained on how to get data from RDF endpoints, which are also available in *.gov.uk sites)

The building blocks for the implementation was the search url, which was quite straight forward. for all the requests based on postal codes the direct.gov site served in the same manner (because of this important fact, the automation process became trivial). for an instance the url for primary school information retrial was,

http://local.direct.gov.uk/LDGRedirect/LocationSearch.do?LGSL=13&searchtype=1&LGIL=8&Style=&formsub=t&text=SE1+7DU

Where the param “text” changed according to the postal code. So far everything seemed straight forward, however at implementation, while using Gadgets API for content retrial, I faced problems in parsing text with javascript. Hence the gadgets.io.makeRequest supported HTML as text and the API method returned the retrieved HTML document as string making it quite impossible to process.

With some thinking and advise, I brought the Mashup Server in to the picture and used it to retrieve the data from the gov site and returned the result in XML format. Using the Mashup Server web scraping seems to be a piece of cake, We created a simple mashup using the scraper host-object and captured the result set in the search result page. The mashup code as follows,

function search(searchUrl) {
	var scraper = new Scraper(
		
		    {searchUrl}
			
			    
				
				   
				
			     
			
		
	);
	return new XMLList(scraper.response);
}

And finally the two gadgets were making service calls to the mashup service and retrieved the data as an XML object, making the data processing painless. The final version at the Gadget Server looked quite appealing.

WSO2 Gadget Server with UK gov data
Gadget Server look - in the end

Special thanks goes to Ruchira for helping me out with the mashup service 🙂 You can download the Gadget code and the Mashup service and try the scenario yourself.

Mashing up RDF data with WSO2 Mashup Server

Okey so this is the fun part that I promised to write about :D. I managed to cook up a use-case to demonstrate RDF querying and making use of the semantic data. The data that I am using for querying, is the rdf data sources available in the UK data.gov site. With some analysis I figured out that this task can be fundamentally archived using the combination of Mashup and Gadget Technologies. My choice of tools were WSO2 Mashup Server and WSO2 Gadget Server for their great flexibility and of cause for other obvious reasons :D. However the Mashup Server does not natively support RDF data retrieval, hence I had to do some work to get such functionality integrated. The great fact about the mashup server is its extensibility, the concept of host objects and the ability to write custom host objects and its pluggable nature comes handy in such cases. The high level architecture of what I am trying to achieve is as follows.

RDF data retrival with WSO2 Mashup server / WSO2 Gadget Server

To implement the above architecture with the tools at hand I created a custom host object that can be plugged to the Mashup Server. When dealing with semantic web related tasks and RDF data handling HP’s Jena java library comes in handy. With the use of Jena-ARQ (for SPARQL) api I managed to get the host object working with few lines of code.

.....
            Dataset dataSet = DatasetFactory.create(sparqlObject.rdfDataSource);
            // Create a new query form a given user query
            String queryString = sparqlObject.spaqrlQuery;
            Query query = QueryFactory.create(queryString);
            QueryExecution qe = QueryExecutionFactory.create(query, dataSet);
            ResultSet results = qe.execSelect();
.....
           resultString = ResultSetFormatter.asXMLString(results);
..... OR.....
           ByteArrayOutputStream bos = new ByteArrayOutputStream();
           ResultSetFormatter.outputAsJSON(bos, results);

With the host object in place, the next task was to create a Mashup in-order to query the rdf data with a given source (EndPoint or data source). The javascript service (Mashup) is created to serve this purpose, where the consumer can specify the RDF endpoint or the data source with the SPARQL query and retrieve the dataset in XML or JSON.

.....
function RdfDocQueryService(rdfDataSource, rdfQuery, resultType) {
   var sparqlObj = new SparqlHostObject();
   sparqlObj.rdfDataSource = rdfDataSource;
   sparqlObj.spaqrlQuery = rdfQuery;
   sparqlObj.resultType = resultType;
   return new XML(sparqlObj.getDataFromRdfSource());
}

Finally to bind everything together, lets try querying some data. My example usecase is to use the query at N2 blog to retrieve traffic monitoring points in UK roads. The query to retrieve the data set as follows,

#List the uri, latitude and longitude for road traffic monitoring points on the M5
PREFIX road:
PREFIX rdf:
PREFIX geo:
PREFIX wgs84:
PREFIX xsd:
SELECT ?point ?lat ?long WHERE {
  ?x a road:Road.
  ?x road:number "A4"^^xsd:NCName.
  ?x geo:point ?point.
  ?point wgs84:lat ?lat.
  ?point wgs84:long ?long.
}

To visualize these points I have created a gadget with the aid of Google Maps api. This gadget can be hosted in the Gadget Server, where it can dynamically retrieve traffic monitoring points for each road in the UK and display them in the map as follows.

Traffic points in A4 road, UK

WSO2 Gadget Server 1.1.0, What to expect

WSO2 Carbon 3.0.0 – code name “Iridium” is just about to release in few more days. as of WSO2’s release strategy, all the products will graduate with their next version on top of carbon based platform. As for the newly released Gadget Server it would be version 1.1.0

Features were frozen for version 1.1.0 and that was in the end of February as I recall. We (the GS team) managed to squeeze in few new very important features to this release.

  • Upgraded shindig to the latest version

This was a bummer, since WSO2 Carbon platform is running on OSGi, if you had to use a non native OSGi project (i.e. Shindig) you will have to create an OSGi aware carbon orbit bundle and make use of it at run time. This was done some time back where shindig was on r734876 revision. In-order to leverage new functionalities such as OAuth, Pub-Sub etc. and to patch the bug fixes we thought of updating the shindig carbon orbit bundle. So now shindig is on r910768 and is quite up to date.

  • i18n internationalization support for gadgets

i18n is not a big deal for Google gadgets since the gadget API itself supports it, What we had to do is enable i18n support in shindig. (Which was already implemented by the shindig community)

  • Inter Gadget communication

Inter gadget communication, seemed to be the hot topic in our forums and webinars, all most in all tech talks we did about the Gadget Server, some person in the audience raised the question about gadget-to-gadget communication. Our answer was “it can be done at shindig level, and we are yet to support it”. So without a long await, with GS v1.1.0 we enabled this feature. The architecture is quite fascinating where there will be zero backend calls and all the communication is done simply on the front-end. Basically each publisher will have a publishing channel and the subscribers can subscribe to this channel. After that its simple pub-sub.

  • The portal will completely run on HTTP transport

This was a limitation we had in our fist release. The portal was running only on HTTPS, and the reason behind was that all WSO2 products are running on secure transport and the Gadget Server is also a combination of some specific components which ran on the same platform. For this release we went the extra mile and enabled HTTP for the portal. So once you go to the login page it will switch to the secure transport (HTTPS) and after successful login you will redirect back to the HTTP non-secure mode. (Of cause you can disable HTTP any time and run the portal purely on HTTPS, it all depends on the requirement.)

One disappointment I have is that we couldn’t integrate OAuth on time. even though it is supported at shindig level we have to do a considerable amount of work from the Gadget Server side to fully support it, hence it is postponed to our next release. You can try the sample OAuth GData Gadget, simply adding it by the URL, and that will work like a charm. (nothing useful but just to let you know that we are only few steps behind on it)

Okey so enough sneak peak 😉 download the Gadget Server pre-beta, play with it, and help us to improve (even in the last minute) by reporting any issues.

Cheers !!

WSO2 Gadget Server is out… Download it !! Play with it !!

Yesterday (16th Dec) WSO2 Gadget Server graduated from its beta status and announced its release. WSO2 Gadget Server is designed to serve as a presentation middle-ware product in the SOA space to smoothly display chunks of service oriented data for the end users.

The solution architecture is based on portal / portlet concept but making it far more simpler. Since the enterprises are more and more leaning towards the cloud and service oriented mashups, visualizing those data should not be complicated. Hence the Gadget Server provides a simple platform to write the data visualization code just in HTML, JavaScript and XML the implementation of the presentation logic cannot make more simpler. It is exactly similar to writing a Google gadget (hosted in iGoogle / Gmail / orkut) to Tweet ;).

As far as it goes the Gadget Server’s applicability for the enterprise is somewhat an enterprise dashboard that can be customized according to the user’s need and governed by the authorities. For an instance if you are a manager of a bank, wouldn’t it be great to have a dashboard forecasting and displaying current and future bank transaction stats and predications, while at the same time in a deferent view having your business schedule, calender, mail/IM, and news as small but clear and interactive portlets.

Yeah so thats, what the Gadget Server does, and the interesting fact is, its simplicity and extensibility, What all you need to know is some HTML and JavaScript. (no need to consult Java / .NET / PHP / SOA experts). So Download it !! Play with it !! Give us some feedback !!

Authoring, deploying and using XML Gadgets in WSO2 Gadget Server

We are about to release The long awaited WSO2 Gadget Server within few days of time. These few days I was doing some documentation and content writing about the Gadget Server, Apache Shindig and Google gadgets specification. My 1st article about authoring gadgets is now published on WSO2 Oxygen Tank as a help/Tutorial for Gadget server users. You can also download the Gadget Server release candidate 2 and play with it. Also Paul had written an interesting article about portals and Gadgets Server’s role.