We have explained WSO2 platform in many ways. Here I am trying to take a more scenario driven approach.
1. Implementing Business Logic
If you are looking to build a SOA based architecture, first step is to implement your business logic as a set of services. Users can use WSO2 Application Server (AS) to do this, and AS enables users to implement a business logic using any of the following methods.
- Using Java Code (WSO2 AS, any Axis2 .aar file works)
- Exposing data in a data source (e.g. Relational Database, CSV file etc., see WSO2 Data services Server)
- Using Business Rules (Supports Drools, see WSO2 BRS)
Once the service is created, users can secure them using HTTPs or WS-Security. Furthermore, he can enable most of the WS-* support also using WSO2 Application Server.
2. Mediating Messages
Often SOA deployment has third party services, legacy applications and other types of frication that force the architecture to mediate messages that flow between services. Users can use WSO2 Enterprise Service Bus (ESB) to do this. Mediation can be of several forms. (* there are others, and following are only some of them.)
- Message transformations
- Message editing
- Message filtering
- Route (e.g. load balancing, Pub/Sub)
- Support Enterprise Integration Patterns (EIP)
3. Creating the User Interface Layer
Often these services have user facing components. WSO2 platform provides two choices to do this.
- Java Web Applications (.war file) in WSO2 AS
- Google Gadget support in WSO2 Gadget Server
4. Composing Services
If the target application is complicated, specially when service execution flows are dynamic and themselves contains business logic, users may opt to compose those services to create business processes. WSO2 platform provides three choices for doing this.
- Create the process as a BPEL document, deploy, and run the business process using WSO2 Business Process Server
- Create the process as a mediation sequence using WSO2 ESB
- Create the process using java scripts with WSO2 Mashup Server
If some of the services receive higher loads that exceed single node capacity, users would want to scale the system by clustering those bottleneck service. Exact details are usecase specific, but WSO2 platform support clustering through Axis2 clustering
Cross Cutting Concerns
In addition, WSO2 platform supports two cross cutting aspects: namely governance and business actively monitoring.
1. Govern SOA
If a SOA deployment has many services and they goes through frequent business logic and configurations changes, ad-hoc management of the deployment could be very complex. WSO2 Governance registry let users store all service WSDL in a single repository and manage their configurations and lifecycles from a single point.
2. Monitoring the Business
Most businesses needs a detailed close to real time view of their activities. WSO2 Business Activity Monitoring (BAM) let users define trace points in activities (service executions). At the runtime, BAM and monitors data collected at those trace points, and present them to end users through Gadgets that aggregate and visualize them.