WSO2 Carbon – @nuwanbando

The Vision Behind WSO2 User Engagement Server

“A picture worth a thousand words” is a known fact which doesn’t need proof. At present we discuss about the value and the power of data. We use various tools to analyze them, we do business intelligence capturing trends or anomalies. However in the end you need to express the meaning in a sensible manner for the key decision makers. Would you go write thousand words or rather draw something, summarize the findings and let the stakeholder explore for more.

WSO2 Middleware stack has all the pieces you need to harvest, store & analyze (both real-time and periodical) vast amount of data sets, but when it comes to summarizing and presenting, the stack had somewhat a week tool set. We envisioned the idea of “SOA Last Mile” since latter part of 2009 with products such as WSO2 Gadget Server, WSO2 Mashup Server and frameworks such as viskit. We experimented, wrote code and delivered enterprise grade products to achieve this vision. For instance WSO2 Gadget Server was one of the most downloaded products during 2010 – 2011 time span, and even now people are using it for various data presentation purposes.

Continue reading The Vision Behind WSO2 User Engagement Server

{HowTo} WSO2 Carbon Server logs to be stored in a database

Thought of documenting this for my own reference, hope this will help. I am also planing to make a knowledge base article out of it to be posted in WSO2 Oxygen Tank.

As you may know, if your are familiar with Log4j, that the logs created with it, can be stored in a database instead of a file. In order to do that you need to add few configuration values to the log4j.properties file.

In-terms of a WSO2 Carbon based server this properties file resides in CARBON_HOME/lib directory. before adding these configurations there are few steps to visit.

[1] Create database {LOG_DB}
[2] Create the log table {LOGGING} with the following fields

create table LOGGING (
             id decimal NOT NULL,
             prio varchar(15),
             cat varchar(255),
             thread varchar(30),
             msg varchar(255),
             layout_msg varchar(255),
             throwable varchar(2000),
             the_timestamp timestamp);

[3] Create a user and assign to the DB

           {user: logger / pwd: logger}

[4] Copy jdbcappender.jar to {CARBON_HOME}/lib and {CARBON_HOME}/repository/components/lib along with the database driver

{jdbcappender.jar can be found at http://www.dankomannhaupt.de/projects/jdbcappender/lib/jdbcappender.jar}

Thats it. All preconditions are set, Now open up the log4j.properties file and add the following appender settings to the end.

#log to db appender
log4j.appender.DB_APPENDER=org.apache.log4j.jdbcplus.JDBCAppender
log4j.appender.DB_APPENDER.url=jdbc:mysql://localhost:3306/LOG_DB
log4j.appender.DB_APPENDER.dbclass=com.mysql.jdbc.Driver
log4j.appender.DB_APPENDER.username=logger
log4j.appender.DB_APPENDER.password=logger
log4j.appender.DB_APPENDER.sql=INSERT INTO LOGGING (id, prio, cat, thread, msg, layout_msg, throwable, 
the_timestamp) VALUES (@INC@, '@PRIO@', '@CAT@', '@THREAD@', '@MSG@', '@LAYOUT:1@', '@THROWABLE@', '@TIMESTAMP@')
log4j.appender.DB_APPENDER.layout=org.apache.log4j.PatternLayout

Scroll to log4j.rootLogger and add the appender to the list,

log4j.rootLogger=ERROR, CARBON_CONSOLE, CARBON_LOGFILE, CARBON_MEMORY, CARBON_SYS_LOG, DB_APPENDER

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 !!