Record and Replay framework with WMBEvent Monitoring

Record and Replay framework with WMB Event Monitoring

This framework can be used to Record/log the messages and Replay the messages/files using Event monitoring in Websphere message broker.

How it differs from existing common logging and Replay frameworks?

Existing common logging frameworks logs the messages for each message that gets processed by a message flow. Similarly, based on some replay flag set, the messages are replayed at the time of error handling in existing error handling frameworks.

“Record and Replay framework with WMB Event Monitoring” can do additional tasks below

 Can decide when and where logging should happen at runtime

 Can decide whether should log all messages or can choose specific messages for logging for a message
flow at runtime

 Can decide what messages should be replayed instead of replaying all the messages failed for a message
flow at runtime

How it gives advantage over WMB 8 version Record and Replay concept?

WMB 8 version also has this Record and Replay by creating the configurable services and corresponding database. It is GUI window to see the logging and can select the messages failed to replay from GUI.
Here with Record and Replay framework using Event Monitoring allows to choose the logging instead of logging all the transactions for each of the message flow/service at runtime and similarly can choose Replay also.

Technology stack required:

 This framework has a package of two WMB message flows, one for logging and another for Replay.

 A database that is compatible with Websphere Message Broker can be used
o To define rules for logging and replay which allows us to choose the logging and replay for each of
our service.
o To log the messages

 MQ for creating subscription queues for Event monitoring

How this framework works?

 Record Message Flow

It does success logging and failure logging to database using the Event monitoring message for each service based on rules defined in database/cache. Caching mechanism is used to load the rules in cache and can be refreshed when required from web browser.

 Replay Message Flow

It is triggered from web browser with Service name or Application/Message flow name to replay failures only for specific service based on rules defined in database. Caching mechanism to load the rules in cache and can be refreshed when required from web browser.

Replay is limited to no of messages as per REPLAYLIMIT in database and also based on UDP flag.

Web-Oriented Architecture (WOA)

What is Web-Oriented Architecture (WOA)?

Web-Oriented Architecture is simple way to achieve what SOA have promised such as reusability, flexibility, and complexity reduction using appropriate incorporation of the existing Web 2.0 technologies like HTTP (Hyper Text Transfer Protocol), REST (Representational State Transfer), and URI (Uniform Resource Identifier).

In a simpler way “Web Oriented Architectures came along the WEB 2.0 revolution to extend SOA”

What is Service-Oriented Architecture (SOA)?

Service-Oriented Architecture (SOA) is a mechanism for achieving the interoperability between systems and for reusing the functionality at the business level. Advantages include Cost efficiency, agility, adaptability, and leverage of legacy investments, business flexibility by dividing processes as services at the fine-grained level.

SOA also can be considered as an IT strategy reorganizing enterprise applications into basic services which can be assembled, reused and collaborated so as to find a quick solution according to business demands.

SOA defines interactions among service requester, service provider, and service registry

• SOAP (Simple Object Access Protocol) is a communication protocol to exchange information request/response messages between the servers and clients in the network.

• WSDL (Web Services Description Language) is an XML (eXtensible Markup language) technology describes the Web service and defines how SOAP and relevant messages are aggregated and exchanged.

• UDDI (Universal Description, Discovery and Integration) is a standard to disclose and explore the Web service information. It is a key component which enables the development, setting, finding and calling of the Web service.

Service provider submits WSDL to the service registry while the service requester receives WSDL by via of UDDI from service registry. Then, the service requester calls the service using SOAP to connect to the service provider.

Any Negative affects using SOA?

• Realization costs

Web service alone are defined by over 70 distinct specifications, including SOAP (Simple Object Access Protocol) for a message format, UDDI (Universal Description, Discovery, Integration) for a service discovery, WSDL (Web Service Description Language) for a service description and so on.

This Over-standardization makes SOA difficult and complex to realize.

Can WOA solve this Negative affect using SOA?

WOA use existing standards such as HTTP (Hyper Text Transfer Protocol), REST (Representational State Transfer), and URI (Uniform Resource Identifier) without defining additional standards. These existing standards have been used successfully in the current Internet.
This potentially decreases the development cost and time for WOA when compared with SOA.

• In WOA, information is represented in the form of resource on the Internet, where every resource can be located via a globally unique address using URI.

• Resources are manipulated based on the protocol specified in the URI, typically HTTP, using the technique known as REST.

Conclusion:

WOA = SOA + WWW+ REST

Above equation is not that WOA is equivalent to these. WOA is what we get when these are combined together.

SOA is not necessarily about Web services at all, but is actually much more about service-orientation concepts like loose coupling and abstraction. Using multiple tools to achieve this is really costly when compared to WOA. This can be achieved with cloud computing.

It is not just that WOA is comparatively preferred over SOA; should choose which would best suit the situation for our business

What is cloud computing?
Cloud computing is defined as using scalable computing resources provided as a service from outside our environment. We can access any of the resources that live in the “cloud” at any time and from anywhere across the Internet. Users need not have to care about how things are being maintained behind the scenes in the cloud.

Amazon: Real time Example of using cloud computing.

Amazon provides several Web services to fulfill some of the core needs of most systems: storage, computing, messaging, and datasets. These services are available to anyone who has access to the Internet. These webservices live in “cloud” outside our environment and are available. Users should pay based only on their usage, with no need for upfront expenditures and capital outlay. There are no maintenance costs for users because the hardware is maintained and serviced by Amazon.

IBM offers few Products for cloud computing

• WebSphere Cast Iron

• WebSphere DataPower Cast Iron Appliance XH40

What are the IBM ESB offerings? When to Choose them?

What are the IBM ESB offerings?

IBM offers three ESB products: IBM WebSphere ESB, IBM WebSphere Message Broker, IBM WebSphere DataPower Integration Appliance XI50.

Selecting an ESB to power your SOA depends upon your requirements.

• WebSphere ESB is a platform based ESB and optimized with WebSphere Application server for an integrated SOA platform.
• WebSphere Message Broker is a platform independent based ESB and is built for universal connectivity and transformation in heterogeneous IT environments.
• WebSphere DataPower Integration Appliance XI50 is an appliance based ESB and is built for simplified deployment and hardened security.

Customers face a wide range of ESB requirements from the simple to the complex

When do I use WebSphere ESB, WebSphere Message Broker or WebSphere DataPower?

IBM's approach to ESB solutions reflects the realities of evolving IT architectures, which are heterogeneous. One size does NOT fit all when it comes to ESB solutions. Businesses should have the freedom to select ESBs that fit their needs, rather than shoehorn a solution that is not optimal in their environment

When to Use WebSphere ESB?

• You use WebSphere Application Server and/or your team has skills with WAS Administration and Java coding
• You are now or planning on developing business process using WebSphere Process Server (WebSphere ESB and WPS have common tooling, programming model, and runtime)
• You are integrating with ISV business applications hosted on WAS or 3rd party solutions which extend and support WAS
• You are focused on standards based interactions using XML, SOAP, and WS
• You want to mediate between Web services and existing systems using JMS and WebSphere JCA Adapters
• Reliability and extensive transactional support are key requirements
• You want to minimize your server investment by cohosting WebSphere services and ESB in one application server

When to Use WebSphere Message Broker?

• You are currently using WebSphere Message Broker but not as an ESB
• You have extensive heterogeneous infrastructures, including both standard and non-standards based applications, protocols, and data formats
• You have extensive MQ skills and infrastructure
• You are using Industry formats such as SWIFT, EDI, HL7
• You are implementing a wide range of messaging and integration patterns
•  Complex event processing, message splitting and aggregation
• You need extensive prebuilt mediation support
• You have very complex transformation needs
• Reliability and extensive transactional support are key requirements
• To achieve very high performance with horizontal and vertical scaling

When To Use WebSphere DataPower?

• Ease of use is a predominant consideration
•    Simple experience of drop-in installation and admin based configuration with no or minimal development required
• You are transforming between XML and XML or XML and any other format
• Your interaction patterns are relatively simple
• Your mediation requirements are met by the existing DP mediations and minimal extensibility is needed
• You are using XMLbased or WSSecurity extensively
• You require use of advanced Web services standards
• You need to minimize message latency when adding an ESB layer
• You are doing extensive XML processing combined with high performance requirements
• Your ESB must be in production very quickly

What is an ESB??

An Enterprise Service Bus (ESB) is a flexible connectivity infrastructure for integrating applications and services. An ESB can power your Services Oriented Architecture (SOA) by reducing the number, size, and complexity of interfaces between those applications and services.

An ESB performs the following:

·         Routing messages between services
·         Converting transport protocols between requester and service
·         Transforming message formats between requester and service
·         Handling business events from disparate sources 

An ESB should allow your organization to focus on your core business needs rather that the IT Infrastructure required connecting the programs together. An ESB should allow you to add new services, or make changes to existing services, with little or no impact to the use of existing services.