Architecture

Unlike static server capacity measurements (e.g. CPU processing speed, memory size), performance is a dynamic measurement. Latency and throughput are strongly influenced by concurrency and work unit size. Larger work unit size usually negatively influence latency and throughput. Concurrency is the number of aggregate work units (e.g. message, business process, transformation, or rule) processed in parallel (e.g. per second). Higher concurrency values have a tendency to increase latency (wait time) and decrease throughput (units processed). Read Srinath's full blog post.

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.

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.

Fellow architects and designers, I fear that we as an industry are moving our applications and data into the cloud without first having mastered service-oriented architecture, the basic discipline of building distributed systems. In the process, we’re setting ourselves up for failure.

Most enterprise usecases model real life activities. Therefore, such processes often need to interact with humans as a part of their executions. This article introduces Human Tasks, a mechanism to integrate interactions with humans to enterprise applications. The article describes how humans tasks are realized and where they can be useful.

Most of the large enterprise systems consists of many software systems. These different systems provide various functionalities required by the whole system. Therefore in order to provide some features across the platform these smaller software modules has to communicate with each other. However different software modules use different technologies and provide various protocols to communicate with the external systems. Standard transports like HTTP, SMTP, JMS, FTP, FIX and various adapter types such as SAP are widely being used. These transports can use different message formats such as SOAP, POX messages and different text message formats. Hence integrating these systems efficient and manageable manner in a distributed system is a well known problem.

Enterprise service bus (ESB) is a commonly used solution for this problem. ESB provides the communication path between heterogeneous systems by providing support for different transports, and message format conversion is done by using a canonical form such as XML. This intermediate canonical form can be used to process the message at the ESB as well.

Store and forward messaging patterns play a major role when it comes to asynchronous messaging. When its comes to Enterprise application integration, store and forward patterns can be used for Integrating systems that supports different message traffic patterns, handling fail over scenarios, priority mediation of messages etc...