Articles

Installing the registry and the ESB is pretty easy. You can find the download for the WSO2 registry here (http://wso2.org/downloads/governance-registry) and for Mule here (http://www.mulesoft.org/download-mule-esb-community-edition). Both come packaged in various formats which can just extract into the directory of your choice. Now we'll start these applications to see if they are installed correctly. For Mule you can use the following command: /bin/mule.bat, and for the registry: /bin/wso2server.bat. If you're not on windows there is also a /bin/mule and a /bin/wso2serversh which you can use.

Read the full story here.

When you have many services it is a good thing to register them somewhere so your consumers can easily find them, see what they are about, determine whether the service levels are good enough etc. When you look back at the heyday of SOA everyone was pusing registries (or repositories, but that terminology is a different subject). To fully do SOA you needed a UDDI registry to accompany your SOAP based services, defined by a WSDL and XML Schemas.

Read the full article here.

This article introduces performance and discusses why architects should consider performance implications when creating solution architecture. Then the article dives into Enterprise Service Bus (ESB) performance, and details recent WSO2 ESB improvements and performance impact.

A context can be defined as a construct that strictly binds the execution environment. As the WSO2 Carbon Context is a runtime container for your app(s), you gain the benefit of leveraging the Carbon Context runtime API to obtain contextual information about various actors utilizing your web apps and web services. For example, you may want to use registry cache for a particular user or tenant. The Carbon Context allows you to access 5 APIs and has several utility methods. Each time we create something user specific, we create a Carbon Context for that user to store specific things. This is valid for all WSO2 Carbon 3.2.2 based servers.

In this article we focus on the performance benchmark aspects of the WSO2 ESB under two different approaches: Message Relay (MR) and Pass-Through (PT). We discuss how efficiently the ESB can handle messages of different sizes under different concurrency levels. We provide a set of detailed statistics to allow comparison of the different approaches.

My previous article on MDM (Master Data Management) discusses how to connect to MDR (Master Data Repositories) and access Master Data. This article focuses on an end-to-end MDM solution including the connector layer.

This is the part 1 of a series of articles that describes various file exchanging scenarios which can be implemented using WSO2 ESB. This first article describes how to read or fetch a file or a special file (such as an archived file like *.zip, *gz or *.pdf etc..) from various sources such as a local file system, an ftp server or sftp server. Although the material is suitable for readers who have experience with WSO2 ESB, the material is self explanatory as much as possible.

Service-oriented architecture (SOA) and the cloud complement each other and at the same time are in different stages of their lifecycles. At WSO2Con 2011, Paul Fremantle, WSO2 co-founder and CTO, led a panel to discuss three aspects of these technology approaches. First was an examination of SOA, which has been through the hype cycle and out the other side, and how hindsight here might help understand cloud computing. Second, was to examine the interaction between SOA and the cloud, and third was to look to the future and what is next. Joining Mr. Fremantle were panelists Sastry Malladi, eBay distinguished architect; Brad Svee, Concur Technologies senior manager of IT development and engineering; Narendra Nathmal, Cognizant Technologies Advanced SOA Center of Excellence chief architect; and Afkam Azeez, WSO2 director of architecture. Here are highlights from their discussion.

Moderator: Paul Fremantle, Panelists: Sastry Malladi, Afkham Azeez, Brad Svee, Narendra Nathmal