– 28th Oct 2.00p.m – 2.30p.m PDT – Run Your Own Mobile App Store
– 28th Oct 4.00p.m – 4.30p.m PDT – Governance for a Connected Ecosystem
– 29th Oct 9.00a.m – 9.30a.m PDT – Connected-Health Reference Architecture
WSO2 recently published a new white paper on what WSO2 platform can offer for developers. The paper talks about all the elements of WSO2 middleware platform and how it can aid a developer to build & govern enterprise applications.
The paper discusses about REST and SOAP service development with technologies like JAX-RS/WS and also using more of modern ways like jaggeryjs. The author have illustrated the plusses of each paradigm, when to use it and how to use it. The paper discusses how to write such services with support of WSO2 developer tooling, deploy them into WSO2 middleware and also manage them using WSO2 governance toolset.
The paper takes a deep dive into technologies like Apache CXF use and JEE support within WSO2 platform and how to use these frameworks to develop applications.
The paper also talks about API management which is a hot topic at present and how WSO2 API management solution can easily expose fully managed APIs for already created services.
There is a section on modern visualization composition in the paper where it discusses creating dashboards, micro-sites and simple html pages for the purpose of information visualization and management. This is with the use of WSO2 User Engagement Center
Use of cloud APIs via WSO2 integration platform (WSO2 ESB Cloud connectors) is highlighted in the paper giving the developers an insight on how to connect their applications to external APIs.
The paper also talks about using the AppFactory; WSO2’s newest tool for application development, management, governance, team management.
Do checkout the white paper as it gives an end-to-end idea about application development lifecycle with WSO2 platform
There seems to be a false alarm spreading over the online forums that WSO2 ESB cannot handle messages larger than 16K and results a corrupted response. This situation occurs only when a user enables one of the synapse properties which is disabled by default.
Streaming XPATH option is the aforesaid culprit, which is a newly introduced feature to optimize the performance in different message filtering / routing scenarios. However this does not effect the default workings of WSO2 ESB which does handle large messages successfully in thousands of enterprise deployments with the default XPATH implementation that ships out of the box.
As any new component achieve perfection with time, WSO2 ESB team have fixed all reported issues against streaming XPATH component (in ESB v4.8.0) and thrives to be the fastest ESB and the integration platform.
Following case study provide mode details on large message handling of WSO2 ESB in production.
UPDATE (02/17/2014) : WSO2 has released the latest performance stats, which details on the stream XPATH stabilization as well.
I’ve been doing release management and product engineering for almost three years in WSO2. By no means am an expert. Am still learning and trying to tame the beast. However I do have my fare share of experience and knowledge which I have gathered by screwing it all up and also sometimes, doing it right as well 🙂
Recently we have done a successful 1.0.0 release of WSO2 User Engagement Server and I felt writing this post as the release retrospect.
Team is the most important part of any product innovation. Without a strong, competent and hard working team you cannot achieve much (period !!). You feel it when it comes to agile release management. You cannot spoon feed your team. Each member will own a part towards success. You have to believe the quote “A Team Is Only As Strong As Its Weakest Link”, so your weakest got to be quite smart.
Milestones are short, quality of deliverables are high. The build *has* to pass always keeping the master stable. That’s a lot of work. A lot of smart work. So the team does matter and that’s the number one.
Well, WSO2 has the best from the Best and luckily UES had the dream team 🙂
Number two is the Vision. Its not about the person whose leading the effort need to know the product vision. The team got to have a shared understanding about the vision of the product that they develop. Everybody has to be on the same page. If a button was moved from left to right everybody must know the reason behind that decision.
Non should develop a component without knowing the bigger picture of where that component fits in. (s)He should know the future of that component, what are the improvements can be done, how can it aid to market the product and how does it contribute to achieve the product’s vision.
Reviews play a major role. They sync up the team. First you review the design, then review the architecture, the UI/UX and then the code. You get this right, you get a complete product feature.
During UES release, we did a lot of these. Our design review meetings were war zones. We talked about architecture and clean design patterns. Applied them appropriately and iteratively reviewed them. Our UI mockups were all over the whiteboard, we iterated until we achieve perfection. We reviewed our code, identified the improvements.
We started re-engineering WSO2 Gadget Server during 2012 Winter. We were brainstorming of how we can change it to be more flexible and accommodate wider enterprise data/information presentation use-cases. We wanted to give more power to the developer, not just the ability to drag and drop widgets and select a layout. We wanted these pages to be discovered around the organization. With such ideas in mind we created multiple mind maps to get a clear idea
We had plenty of email debates, F2F meetings of what we need to do ? Are we there yet ? Is this what developers/business users need ? etc. Continue reading WSO2 User Engagement Server: How it kicked off from the whiteboard