3. Evolution of Integration
Point to Point Integration
● Custom code, data formats for
majority of integration ( data
extraction, business rule
processing, data loading)
● Costly over time (maintenance,
complexity)
● Tight Coupling
● Scalability is an issue
● Less reusability
4. Evolution of Integration
Use of Enterprise Service Bus ● Consistency: Clear set of guidelines
(EIPs) results in repeatable and
successful integration
efforts/projects.
● Reusability: Tested and
preconfigured components provides
repeatable approach to
integration.(transports/connectors/m
ediators etc)
● Effectiveness: A common integration
framework (with related abstract
concepts) improves integration
developer's productivity.
5. Connected Business
An internally and externally connected business.
Image courtesy hRp://jdamico.net/wp-content/uploads/2010/04/collaborate-with-B2B-channel-partners.jpg
ESB were used to connect
internal systems in the past.
Current need is to connect
internal/external parties quickly
and flexible manner.
E.g. Employees, Internal/External
systems, Partners, Customers.
7. Integration and APIs - The Close Cousins
• APIs cannot replace Integration
– Integration of internal services, systems, data and cloud apis
• Cannot mangle SOA for API Management needs
• Using SOA and API in combination is the key to success of
Connected Business.
9. WSO2 Integration + API Management Platform
In practise API management and
integration co-exists providing
flexible, faster ways to connect
required parties such as users,
internal/external systems, employees
etc.
13. Example Mediators
Name Description
Log Mediator Logs full or part of the message, at various severity levels ( Trace, Debug, etc)
Sequence Mediator Invokes existing sequence - Sequence name can be static or dynamic
Send Mediator Sends a message out, using static information or endpoint definition.
Datamapper Mediator Transform data from one form to another
Switch Mediator Evaluates messages contents against regular expression and invokes the
corresponding mediator (switch-case-default)
Validate Mediator Validates message or parts of message against XML schema (schema can be
local or in registry)
PayloadFactory Mediator Create a message payload from an existing message or from scratch
Fault Mediator Transforms current message into custom Fault message
15. Connectors
• A connector is a ready made and convenient
tool to reach publicly available web API’s.
• ‘Cloud to Cloud’ and ‘Cloud to Enterprise’
Integration
• ESB Connector Store : https://store.wso2.com/
16. Connectors
• Every connector is self-contained and
independent from ESB code
• Dynamically plug in to ESB
• Dynamic Tooling support with WSO2 Developer
Studio
• You can write, ‘your own connector’ and just plug it
in
19. Proxy Service
• Acts like a virtual service.
• Receives messages and mediates
them before sending them to the
endpoint (usually an actual
service)
• Mainly to expose as SOAP Service
20. API/HTTP Service
• APIs can accept REST messages which allow clients
to provide additional information on how to
mediate the message
• Defined under a URL Context (e.g: /customer)
• Can define multiple resources under a URL context
• Resources
– Component of API accessed through HTTP call
– Similar to proxy service (in, out, and fault
sequences)
– Can restrict resource’s scope using URL
patterns and URI templates
21. API/HTTP Service
• URL mapping
– Path mappings (eg: /test/*, /foo/bar/*)
– Extension mappings (eg: *.jsp, *.do)
– Exact mappings (eg: /test, /test/foo)
• URI template
– /order/{orderId}would process /order/A0001
– /dictionary/{char}/{word}would process /dictionary/c/cat
– Use get-property to retrieve exact values
<log level="custom">
<property name="Character" expression="get-property('uri.var.char')"/>
<property name="Word" expression="get-property('uri.var.word')"/>
</log>
25. Endpoints
• Logical representation of one or more real backend
service, jms queue etc.
• Address, HTTP Endpoints – A logical endpoint for an
existing BE service
• Load balancing / Failover – Group of endpoints for
existing BE services
26. Message Store and Message Processor
• Asynchronous/One-way Messaging, JMS
• Store and forward
• Guaranteed Delivery and Rate matching
• JMS Message broker as the persistence store – WSO2 MB, Apache
Active MQ etc.
27. Message Processor in a Cluster
• One consumer per cluster – Guaranteed in-order delivery
• Multiple consumers – Guaranteed delivery
One Consumer Multiple Consumers
28. Tasks
• Allow configuration of scheduled jobs to execute internal/external
commands
• Inject a message into a proxy service or a named sequence
33. WSO2 ESB 5.0 – Upcoming release
• Beta version is available (Released on May 2016)
• Improved usability of the ESB through debugging, data
mapping capabilities through developer studio tooling
• The product is released as a tuple of runtime, analytics
and tooling
• Dedicated analytics distribution(DAS) for ESB specific
monitoring with pre built dashboards
35. WSO2 ESB 5.0 – Statistics/Tracing
• Fine grained statistics/tracing on mediators (message level)
36. WSO2 ESB 5.0 – Statistics/Tracing
• Fine grained tracing on messages
37. WSO2 ESB 5.0 – Visual Data Mapper
• Visual Data mapper
– Different input/output options (XML, JSON, Files, Schemas)
– Apply functions while mapping the data (Split, Aggregate, Uppercase, Lowercase)
38. WSO2 ESB 5.0 – Mediation debugger
• Debug mediation flows from the Developer studio
39. WSO2 ESB – What’s new in 5.0
Other new features
• JMS 2.0 support
• Websocket support
• JMS distributed(XA) transaction support
• Rabbitmq/MQTT performance improvements
41. WSO2 Integration Cloud (Upcoming)
Integration Platform as a Service (iPaaS)
• Running integrations on the cloud
• Analytics integration
• Develop integrations using WSO2 Developer studio
44. WSO2 Business Process Server
• BPMN 2.0
• WS-BPEL 2.0
• WS-HumanTask 1.1
• BPEL4People
● Define and execute business processes
● Define workflows interacting with People
● Graphical process modeling/administration/monitoring
48. Fundamentals of WSO2 Message Broker
Messaging Models
● RPC Style
- Request/Response (there is always a response)
- Synchronous (client waits for response)
- Non-persistent (message is lost if something failed)
● Point to Point (Queues)
- A message is delivered only once to a single Broadcast a
message to all the subscribers
● Publish/Subscribe (Topics)
- Broadcast a message to all the subscribers
49. Fundamentals of WSO2 Message Broker
Messaging Models
● Publish/Subscribe (Topics)
- Broadcast a message to all the subscribers
● Durable Subscriptions
- Same as topic subscriptions
- Subscriber offline - Messages get queued
- Subscriber back online - Messages get delivered
- Unsubscription needed to remove queuing
50. Fundamentals of WSO2 Message Broker
● Transactional
- Send/Receive multiple messages in a transactions.
- ( send/consume -> rollback, reject, commit)
● Guaranteed Delivery/Acknowledgments , QOS ( MQTT, JMS).
● Persistence
- Messages kept in memory or in reliable storage.
51. Fundamentals of WSO2 Message Broker
● Dead letter channel
- Broker keeps invalid/rejected messages in this channel.
- Users can inspect/reroute/delete these messages.
● Hierarchical topics
- Map relationships between data being published onto different
topics.
- Can Subscribe to part of the hierarchy.
Games.*
- receives messages published to ‘Games.FootBall’
and ‘Games.Cricket’
Games.Cricket.#
- Receives messages published to
‘Games.Cricket.SriLanka’ and ‘Games.Cricket.UK’
52. Fundamentals of WSO2 Message Broker
Distributed Queues
● Provides strict or best effort
support for inorder delivery
● There are no guarantee
about the global order seen
across subscribers
53. Fundamentals of WSO2 Message Broker
Distributed Queues with MB
● Provides strict or best effort
support for inorder delivery
● There are no guarantee
about the global order seen
across subscribers
● Supported Protocols
AMQP/JMS, MQTT
54. MB Roadmap
• Support for AMQP 1.0 and JMS 2.0
• Improvements to Storage Scheme, Performance improvements
• Analytics for MB
• C5 migration
• Improved GUI
• MQTT + Websockets
56. Introducing WSO2 Data Services Server
Painpoints:
● Application Silos / Different data
stores
● Cumbersome data access/
transformation logic
● Business logic vs Data access logic
● Repetitive Code
DSS:
● Well defined interfaces (standard based)
● Encapsulated data logic
● Configuration driven
● Loose Coupling between App & Data stores
● Scale as a separate architectural layer.
57. WSO2 Data Services Server : Features
• Multiple Data Sources
• Nested Queries
• Batch Processing
• Distributed Transactions
• OData (www.odata.org)
– Quickly expose data as REST APIs
– Standardized [URL conventions, Request/Response Headers,
Status Codes ,Payload formats]
58. Demonstration - Use Case
• As part of an effort to improve traffic monitoring process, City
transport authorities are making buses to send useful
information while it's in operation such as speed, location data
and direction.
• To ensure safety of passengers, officials would like to detect bus
drivers who violate speed limits. Supervisors will investigate
these incidents case-by-case basis.
• If a supervisor determines a particular incident is undue, bus
driver will be placed under further investigation/review.
69. Next generation Integration Platform
• WSO2 Gateway Framework
– An ultra high performance, lightweight and reusable message
Gateway framework that encapsulates the messaging between
source and target systems
– HTTP/s message gateway leveraging Netty, LMAX Disruptor and
WSO2 Pass-Thru messaging architecture.
71. WSO2 Process Center
Process owner /
analyst
Process
participant
Developer
Create / improve
/ standardize
Search / browse
/ follow
View
Develop executable processes
Executable
process is
associated with
Process Center