Summarizing WSO2 Gadget Server

Near after eight months,that I have joined WSO2 team,I feel it's the better time to share some information regarding the product,that I have almost contributed there.It's non other than WSO2 Gadget Server-The Enterprise Information Portal,which provides a framework built on top of the Google gadget specification.For more information regarding Google gadget specification visit .

Simply saying,the key idea of GS is to keep all the relevant information in a single place in a well organized manner according to the portal user's preference.And the user can change this web space as a dynamical information store or either static information store according to his/her requirements.

Accepting the idea of one picture could say more than 1000 words,before going to deep on it,below shows the screen-shot of the portal view of GS.

Highlighted features of Gadget Server...

Embedded Gadget Repository

It is to store gadget xml files and add them to portal once user required.Gadget repository view of GS,provides information of how many users using the gadget,whether it is already added to the portal,gadget description and its ratings.

Allow two ways of adding gadgets to the portal

-- Store the gadget xml in WSO2 gadget repository ,and add it to GS portal.

-- Link to a gadget xml in different location and add it to GS portal.

Maintain role-based gadgets

Once a gadget stored in GS embedded registry,access to that gadget can be limited by setting permissions as below,in gadget permissions part.

Portal Theming Support

Upto now,users could able to customize portal theme from three different customized themes.

Portal custom layout support

Currently portal,supports six layout templates (such as one column layout,2-column layout,3- column layout,2- column 2-row layout,etc).Following is an example for a portal view having such a custom layout template.

Above mentioned are not all the features provide by GS,but a part from that stack.You can get more information from;

Comments

Passing end-user details from client to real backend endpoint via JWT token

In real-world business system,WSO2 API Manager useful on exposing company APIs, in a secured and controlled manner with the features provided by APIManager as; OAuth support [To secure API invocations] Throttling support [To control API invocations] Monitoring support [To track API usage] More technically what happening is when a user sends a particular API request,it will goes to WSO2 APIManager node and from there,the request will route to the real implemented back-end endpoint of the particular API and get back the response and returned it to the API invoked user. There can be a use-case,that this back-end endpoint may expect the details of API invoked user as to pass those details to some internal company usage as; Additional authentication/authorization Track usage data from an internal system. So how to support above requirement from WSO2 AM. There comes the use of JSON Web Token[JWT] implementation done inside WSO2 AM. JWT is a means of representing claims to...

How to rollback/commit processing messages from WSO2 ESB when enabled JMS transaction

This blog post describes the below use-case where WSO2 ESB 4.6.0 act as the intermediate channel in-between two JMS queues. The Use-case First messages will be de-queue to a proxy service deployed in WSO2 ESB from an queue in ActiveMQ message broker. Then inside ESB,the incoming messages will undergo with some message mediation flow and then the message will be send to another JMS queue deployed in JBoss server. Inside the ESB,following failures could be happen; a) Failures during message mediation process failure inside ESB [for example if you use dbreportmediator/lookup mediator inside mediation flow,some times failures can happen due to database connection failures] b) Message sending failure,due to endpoint is unavailability.[For example,the JBoss ...

TPP Journey through WSO2 Open Banking

Introduction 2018 is all set to be a game-changing year for European banking. The Revised Payment Services Directive (PSD2) has opened the door to new third party providers [TPPs] to connect with banks and manage finances of bank customers on behalf of them. The PSD2 regulation has mandated banks to expose their core-banking account data and payment services to authorized TPPs to consume. Thus as a bank it’s essential to have a solution which will securely expose their internal banking services to third party providers in a trusted manner. WSO2 Open Banking solution provides all required components to expose bank APIs in a well secured manner in order to become PSD2 compliant. This article explains about the importance of the TPP role in PSD2 domain, the requirements set that banks need to provide for TPPs by PSD2 regulations and how WSO2 Open Banking solution supports these requirements. From my last blog ,I have given an introduction for PSD2 and WSO2 Open Banking soluti...

Open Space

Search This Blog