WSO2 Overview

WSO2 ESB:
    ESB(Enterprise Service Bus):
   An enterprise service bus (ESB) is a middleware tool used to distribute work among connected components of an application. ESBs are designed to provide a uniform means of moving work, offering applications the ability to connect to the bus and subscribe to messages based on simple structural and business policy rules.
          As such, it's a tool that has use in both distributed computing and component integration. The best way to think of this tool is to visualize it as a set of switches that can direct a message along a specific route between application components based on message contents and implementation or business policies.
ESB Tools: OSB(Oracle Service bus),WSO2,Mule soft.
OSB-Oracle Product
Mule Soft-sales force
WSO2-

       1. WSO2 Enterprise Integrator (WSO2 EI) is a comprehensive integration solution that           enables communication among various, disparate applications.
      2.Instead of having your applications communicate directly with each other in all their various formats, each application simply communicates with WSO2 EI, which acts mainly as an ESB to handle transforming and routing the messages to their appropriate destinations.
    3.The WSO2 EI product can be used to manage short-running, stateless integration flows (using the ESB profile) as well as long-running, stateful business processes (using the Business Process profile).

Coming to WSO2ESB Project:

Once you have to create project, we are getting below folders.

API:

endpoints: AddressEndPoint,DefaultEndPoint,FailoverEndPoint,HTTPEndPoint,Load-BalanceEndPoint,NameedEndPoint,RecipientListEndPoint,TemplateEndPoint,WSDLEndPoint.

---->endpoints we can pass two ways

                          !)Static EndPoint

                         !!)Dynamic EndPoint(Save in a  Registry ResourcesProject)

Inbound-endpoints:

local-entries:

Local Entries and Registry Entries:

An entry stored in the local registry. The local registry acts as a memory registry where you can store text strings, XML strings, and URLs. These entries can be retrieved from a mediator.

WSO2 ESB makes use of a registry to store various configurations and artifacts such as sequences and endpoints. A registry is a content store and a metadata repository. Various SOA artifacts such as services, WSDLs, and configuration files can be stored in a registry and referred to by a key, which is a path similar to a UNIX file path. 

For add local entries there will be 3 options for the content to be stored as an entry within ESB

     In-lined Text Entry — text

     In-lined XML Entry — XML

     Source URL Entry — hosted resources accessed via an URL

<localEntry xmlns="http://ws.apache.org/ns/synapse"

key="testEntry">12345</localEntry>

<localEntry key="env" xmlns="http://ws.apache.org/ns/synapse">TEST</localEntry> 

<property name="testProp" expression="get-property('testEntry')" scope="default" type="STRING"/> 

<property name="testProp" expression="get-property('registry', 'conf://custom/testEntry')" scope="default" type="STRING"/>

message-processors:

message-store:

proxy-services:

-------------->Proxy-services-types: Custom proxy,logging proxy,pass through Proxy,Secure proxy,Transerfer proxy,wsdl based proxy.

Sequences:

tasks:

templates:

Palette:

Nodes: Proxy Service and APIResource

Mediators:Call,callTemplate,Drop,Log,LoopBack,Property,propertyGroup,Respond,

                    Send,Sequence,Store,ConditionalRouter,Filter,Switch,Validate,Bean,Class,Command,EJB,Script,Spring,Enrich,Fault,Header,PayloadFactory,Smooks,URLRewrite,Xquery,

XSLT,DataMapper,FastXSLT,Cache,DBLookup,DBReport,Enqueue,Event,Throttle,

Transaction,Aggregate,CallOut,Clone,Iterate,ForEach,Entitlement,OAuth,Builder,

Builder,Rule,BAM,PublishEvent.

Core Mediators:

     Call: Invoke a service in non blocking synchronous manner.

When you invoke a service in non-blocking mode, the underlying worker thread returns without waiting for the response. In blocking mode, the underlying worker thread gets blocked and waits for the response after sending the request to the endpoint. Call mediator in blocking mode is very much similar to the Callout mediator.

   Enqueue: Uses a priority executor to ensure high-priority messages are not dropped.

Send:Sends a message.

Loopback: Moves the message from the In flow to the Out flow, skipping all remaining configuration in the In flow.

Sequence:Inserts a reference to a sequence.

Respond:Stops processing on the message and sends it back to the client.

Event:Sends event notifications to an event source, publishes messages to predefined topics.

Drop:Drops a message.

Call Template:Constructs a sequence by passing values into a sequence template.

Enrich: Enriches a message.

Property: Sets or remove properties associated with the message

Log: Logs a message.

Filter Mediators :

   Filter: Filters a message using XPath, if-else kind of logic.

   Out: Applies to messages that are in the Out path of the ESB profile.

   In: Applies to messages that are in the In path of the ESB profile.

  Validate:Validates XML messages against a specified schema.

  Switch:Filters messages using XPath, switch logic.

  Router:Routes messages based on XPath filtering.

 Conditional Router:Implements complex routing rules (Header based routing, content based routing and other rules)

Transform-Mediators:

  XSLT: Performs XSLT transformations on the XML payload.

 FastXSLT: Performs XSLT transformations on the message stream.

 URLRewrite: Modifies and rewrites URLs or URL fragments.

 XQuery: Performs XQuery transformation.

Header: Sets or removes SOAP headers.

Fault (also called Makefault):Create SOAP Faults.

PayloadFactory: Transforms or replaces message content in between the client and the backend server.

Advanced-Mediators:

  Cache: Evaluates messages based on whether the same message came to the ESB profile.

ForEach: Splits a message into a number of different messages by finding matching elements in an XPath expression of the original message.

Clone: Clones a message.

Store: Stores messages in a predefined message store.

Iterate:Splits a message.

Aggregate: Combines a message.

Callout: Blocks web services calls.

Transaction:  Executes a set of mediators transactionally.

Throttle: Limits the number of messages.

DBReport: Writes data to database.

DBLookup: Retrieves information from database.

EJB: Calls an external Enterprise JavaBean(EJB) and stores the result in the message payload or in a message context property.

Rule: Executes rules.

Builder: Builds the actual SOAP message, from a message, which is coming into the ESB profile through the Binary Relay.

Entitlement: Evaluates user actions against a XACML policy.

OAuth: 2-legged OAuth support.

Smooks: Used to apply lightweight transformations on messages in an efficient manner.

Data Mapper: Converts and transforms one data format to another, or changes the structure of the data in a message.

Extension-Mediators:

Bean: Manipulates JavaBeans.

Class: Creates and executes a custom mediator.

POJOCommand: Executes a custom command.

Script: Executes a mediator written in Scripting language.

Spring: Creates a mediator managed by Spring.

Agent:

BAM: Captures data events and sends them to the BAM server.

Publish Event: Constructs events and publishes them to different systems such as WSO2 BAM/DAS/CEP/SP via event sinks.

EndPoints: AddressEndPoint,DefaultEndPoint,FailoverEndPoint,HTTPEndPoint,Load-BalanceEndPoint,NameedEndPoint,RecipientListEndPoint,TemplateEndPoint,WSDLEndPoint.

Links: ESB Link

DefinedSequences:

DefinedEndPoints:

WSO2 ESB usage of get-property function

What are Properties?

----->WSO2 has a huge set of mediators but property mediator is mostly used       mediator for writing any proxy service or API

----->Property mediator is used to store any value or xml fragment temporarily during life cycle of a thread for any service or API.

------>We can compare “Property” mediator with “Variable” in any other traditional programming languages (Like: C, C++, Java, .Net etc).

----->There are few properties those are used/maintained by ESB itself and on the other hand few properties can be defined by users (programmers). In other words, we can say that properties can be define in below 2 categories:

1)ESB Defined Properties

2)User Defined Properties.

These properties can be stored/defined in different scopes, like:

⦁ Transport

⦁ Synapse or Default

⦁ Axis2

⦁ Registry

⦁ System

⦁ Operation

------->Generally, these properties are read by get-properties() function. This function can be invoked with below 2 variations.

get-property(String propertyName)

get-property(String scope, String propertyName)

--------->1st function doesn’t require to pass scope parameter, which always reads propetries from default/synapse scope.

Solution (Scope-Style Reading):

--------->Instead of using get-properties() function these properties can be referenced by below prefixes separated by colon

⦁ $ctx – from Synapse or Default Scope

⦁ $trp – from Transport scope

⦁ $axis2 – from Axis2 Scope

⦁ $Header – Anything from Header

⦁ $body – for accessing any element in SOAP Body (applicable for SOAP 1.1 and SOAP 1.2)

Example:

Lets assume that there is any property set with name “Test-Property”

From Default Scope:

<property name=”Read-Property-value” expression=”get-property(‘Test-Property’)”/>

<property name=”Read-Property-value” expression=”$ctx:Test-Property”/>

From Transport Scope:

<property name=”Read-Property-value” expression=”get-property(‘transport’,’Test-Property’)”/>

<property name=”Read-Property-value” expression=”$trp:Test-Property”/>

From Axis2 Scope:

<property name=”Read-Property-value” expression=”get-property(‘axis2′,’Test-Property’)”/>

<property name=”Read-Property-value” expression=”$axis2:Test-Property”/>

Note:We should prefer to use all second property format for accessing these properties for better performance.

Please note this syntax is not applicable for few ESB defined properties, like: OperationName, MessageID, To

It will work as expected with get-properties, but not with $ctx.

So, please make sure you are using correct way for accessing ESB define properties.
System requirements:

• 3 GHz Dual-core Xeon/Opteron (or latest)
• 4 GB RAM (2 GB for JVM and 2 GB for the operating system)
• 10 GB free disk space
• ~ Recommended minimum - 2 Cores. For high concurrencies and better performances - 4 Cores.

Disk space is based on the expected storage requirements that are calculated by considering the file uploads and the backup policies. For example, if three WSO2 product instances are running in a single machine, it requires a 4 GHz CPU, 8 GB RAM (2 GB for the operating system and 6 GB (2 GB for each WSO2 product instance)) and 30 GB of free space.

WSO2 Software's: 

we need to install below software's.

1.wso2-integration-studio-win64-x86_64-6.5.0
2.wso2ei-6.5.0
3.wso2am-2.6.0