WebSphere ESB Interview Question and Answers

WebSphere ESB Interview Question and Answers

What is ESB?

               An enterprise service bus (ESB) is software architecture for middleware that provides fundamental services for more complex architectures. For example, an ESB incorporates the features required to implement a service-oriented architecture (SOA). In a general sense, an ESB can be thought of as a mechanism that manages access to applications and services (especially legacy versions) to present a single, simple, and consistent interface to end-users via Web- or forms-based client-side front ends.

2. What are all the Primitives used in Mediation?

     We have different types of primitives in mediation.

1.      Message Filter

2.      Type Filter

3.      Endpoint Lookup

4.      Service Invoke

5.      Fan-out

6.      Fan-in

7.      XSLT

8.      BO Map

9.      Message Element Setter

10.  DB lookup

11.  Data Handler

12.  Custom Mediation

13.  Header Setters

14.  Message Logger

15.  Even Emitter

16.  Stop

17.  Fail

18.  Sub Flow

3. Difference between BO Map and XSLT?

     Both are used for manipulate and transfer the message.

Use XSLT when	Use BO Maps when
You have an existing stylesheet or want to use custom XSLT in the map.	You have an existing BO Map or submap.
You want to use XPath expressions inside the map.	You want to use the relationship service (particularly dynamic relationships).
You want to use Java snippets that use the DOM API to access or update data.	You want to use Java snippets that use the BO API (SDO API) to access or update data.
You want to use built-in XPath or EXSLT functions to access or modify data.	You want to order the completion sequence for the transforms.
You want to combine contents from more than one array (repeating element).	BO Maps can be faster when used with WebSphere® Adapters, because the BO Maps work directly with the SDO API.

Performance with XSLT or BO Maps depends on a number of factors including:

• An XSLT map is fastest when processing web services messages and the incoming data is unmodified between the entrance to the mediation flow and the XSLT primitive.
• A BO map can be faster when the message content has already been accessed in the mediation flow.

4. What is SMO? And wt it contains?

     The SMO model is a pattern for using SDO Data Objects to represent messages. The SMO contains a representation of the following groups of data:

• The business payload of the message. The payload is the application data exchanged between service endpoints.
• Header information associated with the message. For example, Java Message Service (JMS) headers if a message have been conveyed using the JMS API.
• Context information (data other than the message payload).

5. What are Shared, Transient and Correlation Context?

      Shared Context: Context is a temporary area which is created along with                Service Message Object (SMO) in the Mediation Flows. Shared Context is a     type of context which is present in the SMO. Shared Context is mainly used   when we are using Aggregation process where we need to Iterate the BO for          Certain times. Shared Context maintains Aggregation data between      Aggregation (FanOut and FanIn) primitives. The Content (data) which is present in the shared context BO does not persist across Request and        Response flows i.e The Data in the Shared Context which is used in Request    flow can not be used again in Response flow.

      Transient Context: Used for passing values between Mediation primitives      within the current flow — either the request flow or the responses flow. The     transient context cannot link requests and responses and hence cannot be      used across.

      Used when you want to save an input message before a service invokes call    (within a request or response flow). After the services invoke call, the next        primitive can create another message by combining the service invoke     response and the original message stored in the transient context.

     Correlation Context: Used when Mediation primitives want to pass values      from the request flow to the response flow.

     Used to pass values from the request message onto the response.

6. Difference between Callout and Service Invoke?

     Service Invoke: The Service Invoke primitive is used to make a service         request in either a request or response mediation flow. The service may be      Request/Response or One-Way. Multiple instances of the Service Invoke           primitive are permitted in a flow, allowing a series of service invocations to be performed. 

     Callout: The Callout receives the message and calls the requested        service          and operation. There is a Callout node for each connected     target operation in the mediation flow.

o        If the call is successful, the Callout Response node in the response flow receives the response message.

o        If the call is unsuccessful, the Callout can be set to retry service invocations depending on the type of fault received.

7. How can you implement loop in mediation?

     By using Fan-in and Fan-out primitive.

8. What is the functionality of Fan-in and Fan-out?

     Fan-out:We can use the Fan Out primitive to fire the output terminal once     (with the  input message) or to fire the output terminal multiple times. You       can use Fan Out in isolation or as part of a Fan Out and Fan In combination.

      Fan-In: Fan In is always partnered with a Fan Out in the same flow and acts   as a decision point for when to continue flow execution. It receives a number         of messages until a decision point is reached, at which point the last message           to be received is propagated to the output terminal. The Fan In primitive may      only be used in combination with Fan Out. 

9. How can you change the runtime changes using mediation primitive?

     We have future called Promotable properties in ESB. We can configure this      future while development. Then we can make it changed at runtime without       restarting      the server it can be published.

10. What are all the configurations required for JDBC Adapter implementation?

     Data Source need to be created and need to configure with DB. If we have     security, then need to created security authentication.

11. Different between SDO and SMO?

     SDO: Service Data Object is the representation of the variable or Object.

     SMO: The SMO model is a pattern for using SDO Data Objects to represent     messages

12. Difference between Stop and fail?

     Stop: Stops a particular path in the flow, without generating an exception.

            Fail: Generates a failure in the flow.

Websphere IIB on Cloud

Why Choose IBM Integration?

Provider of Integration technology*

§Over 1,500 clients achieve flexible integration with IBM Integration Bus

§Proven robust and scalable across many industries worldwide for the last 12 years

§Deployed across high volume mission critical scenarios

§Market leading global support policy

§No vendor lock in with standards leadership for integration across both IBM and non-IBM environments

§Regular enhancements from R&D labs across US, Europe and Asia

§Global skills base of over 1,300 partners**, and more than 2000 developers certified each year

Report:  IBM Named Marketshare Leader in Middleware Software

Announcement confirms 12th Consecutive Year of Software Leadership

  April, 2013

* Source: “IBM Named Marketshare Leader in Middleware Software”

  http://www-03.ibm.com/press/us/en/pressrelease/40807.wss

** https://www.ibm.com/partnerworld/wps/bplocator

About IBM Integration Bus

A high performing, robust enterprise service bus (ESB) to integrate data across heterogeneous IT systems and applications.

 IIB on the cloud

WMQ Concepts

Please click the link

EAI patterns

Please click on the link

http://www.enterpriseintegrationpatterns.com/patterns/messaging/

EAI – enterprise application integration

Please click the link

EAI, ESB, SOA

INTRODUCTION This paper aims to bring clarity to terms EAI, ESB, SOA and provide a clear distinction. Also this paper would discuss architecture options available for enterprise integration and what these options are most suitable for. Finally this paper would address the discussions we have seen in various forums about whether EAI is going to be replaced by SOA or ESB.

SOA-  Service oriented architecture is approach to have software resources in an enterprise available and discoverable on network as well defined services. Each service would achieve a predefined business objective and perform discrete units of work. The services are independent and do not depend on the context or state of the other services. They work within distributed systems architecture. Earlier SOA used COM or ORB based on CORBA specifications and recent SOA stress on web services using standard description (WSDL), discovery (UDDI) and messaging (SOAP). Service oriented architecture may or may not use web services but yes web services provide a simple way towards service oriented architecture albeit with the age old security and reliability limitations.

EAI -Enterprise application integration is a business need to make diverse applications in an enterprise including partner systems to communicate to each other to achieve a business objective in a seamless reliable fashion irrespective of platform and geographical location of these applications. It is a business need and business never dies it only evolves. I have seen people saying that EAI is a thing of past now SOA is here, it is just like saying “transportation is a thing of past now road is here”. EAI comprises of message acceptance, transformation, translation, routing, message delivery and business process management. Usually messages transportation is asynchronous but for a business need it can be synchronous as well. There are two basic architectures to achieve this, bus and hub/spoke architecture. Both of these can be used to develop services and then it also becomes service orientated architecture.

ESB- Enterprise service bus is an infrastructure to facilitate SOA. It gives API which can be used to develop services and makes services interact with each other reliably. Technically ESB is a messaging backbone which does protocol conversion, message format transformation, routing, accept and deliver messages from various services and application which are linked to ESB. Current EAI landscape is seeing many vendors who offer enterprise service bus and claim it to be a brand new concept. This brings a question on what exactly is the difference between ESB and the bus based implementations which have been there in market for quite a long time now. Actually there is not much difference between ESB and proprietary buses except for a few subtle ones. Main difference between ESB and proprietary bus implementation is of cost which is significantly low for ESB. Reason for this cost difference is two fold, first proprietary bus offers lot of built in functionalities as a suit of product which need to be developed for ESB implementations based on business requirement, second most proprietary buses use some proprietary formats to enhance the performance and that increases the cost. ESB on the other hand is usually standard based, so it is a tradeoff between performance and cost between proprietary bus and ESB. Main advantage of ESB is that it costs much less then hub/spoke or bus based product suits and that it is standard based.

Please visit the link for more information

Performance Testing Framework for Websphere Message Broker

Tools used to do the performance testing of ESB interfaces:

• Jmeter
• SupportPac IS03

The following section will brief the tools that are used in the ESB Performance test plans.

Jmeter:

Jmeter is an open source Apache Software used for load testing the applications. It’s a 100% pure java application for load and performance testing. It requires JDK 1.6 or higher. This is a Java desktop application with a graphical interface using the Swing graphical API, can therefore run on any environment / workstation accepting a Java virtual machine, for example: Windows, Linux, Mac, etc.

Protocols supported:

• Web: HTTP, HTTPS sites ‘web 1.0’ web 2.0 (ajax, flex and flex-ws-amf)
• Web Services: SOAP / XML-RPC
• Database via JDBC drivers
• Directory: LDAP
• Messaging Oriented service via JMS
• Service: POP3, IMAP, SMTP
• FTP Service.

Features:

• It’s free. It’s open source software.
• It has simple and intuitive GUI.
• JMeter can load and performance test many different server types: Web – HTTP, HTTPS, SOAP, Database via JDBC, LDAP, JMS, Mail – POP3.
• It is platform-independent tool. On Linux/Unix, JMeter can be invoked by clicking on JMeter shell script. On Windows it can be invoked by starting the jmeter.bat file.
• It has full Swing and lightweight component support (precompiled JAR uses packages javax.swing.* ).
• JMeter store its test plans in XML format. This means you can generate a test plan using a text editor.
• Its full multi-threading framework allows concurrent sampling by many threads and simultaneous sampling of different functions by separate thread groups.
• It is highly extensible.
• Can also be used to perform automated and functional testing of your application.

Setting up Jmeter:

• JMeter is a framework for Java, so the very first requirement is to have JDK installed in your machine. JDK 1.6 or above must be installed.
• Set the JAVA_HOME environment variable to point to the base directory location, where Java is installed on your machine.
• Append Java compiler location to System Path.
• Please download the Jmeter tool (link:http://jmeter.apache.org/download_jmeter.cgi).
• And unzip it and execute C:\apache-jmeter-2.9\apache-jmeter-2.9\bin\jmeter.bat.

IMPORTANT NOTE: JMeter currently knows to look for jars/classes in two places only:

• lib/ext, where the ApacheJMeter_*.jar files live
• lib, where the 3rd party jar files live

Due to the above limitations Additional jars should normally be placed in the lib directory. For example to establish the connectivity with Websphere MQ queues, All MQ jars (websphereMQ installationpath\java\lib) have to be copied to Jmeter lib directory.

Definitions: This sections Defines the terminologies that are going to be used most often in the further discussion of test plans.

Test Plan: TestPlan is where we create the real test plan for testing the performance. A test plan describes a series of steps JMeter will execute when run. A complete test plan will consist of one or more Thread Groups, logic controllers, sample generating controllers, listeners, timers, assertions, and configuration elements. Although test plan can have multiple thread groups but at least one thread group is mandatory.

Elements: Elements are the building blocks of a test plan. Elements of a test plan can be added by right clicking on the Test Plan node and choosing a new element from the “add” list.

Thread Groups:  Thread Group elements are the beginning points of your test plan. As the name suggests, the thread group elements control the number of threads JMeter will use during the test.

Samplers:  Samplers allow JMeter to send specific types of requests to a server. They simulate a user’s request to the target server. For example, you can add a HTTP Request sampler if you need to perform a POST, GET, DELETE on a HTTP service. Some other examples of samplers are: FTP Request, SOAP/XML Request, and JMS Request.

Listeners: Listeners let you view the results of Samplers in the form of tables, graphs, trees or simple text in some log files. They provide visual access to the data gathered by JMeter about the test cases as a Sampler component of JMeter is executed.

Listeners can be added anywhere in the test, including directly under the test plan. They will collect data only from elements at or below their level.

Message Flow Statistics Visualiser(IS03 SupportPac):

IS03 SupportPac runs as a java standalone application and uses MQ Client connection to connect Message Broker Queue Manager. It relies on the accounting and statistics facility of Message broker. So it has the ability to capture real-time and historic statistics data in tables, along with the capability to export all recorded data to CSV to enable custom user processing.

Setting up IS03 SupportPac:

There are a number of set up steps which must be carried out before IS03 will correctly function. These should be performed in the sequence listed in this document:

1) Ensure the Message Broker Queue Manager will accept client connections

• Configure and start a TCP Server-connection channel on the Message Broker Queue Manager.
• Configure and start a TCP Listener on the Message Broker Queue Manager.

2) Ensure that Message Flow Statistics are enabled.

• IS03 requires XML message flow statistics to be enabled for the flows you wish to visualise. Use the

‘mqsichangeflowstats’ command to configure this e.g:

mqsichangeflowstats MB7BROKER -s -g -j -n advanced -t basic -b basic -c active -o xml

• Visit the WebSphere Message Broker infocenter for more information on using this command:

http://www-01.ibm.com/software/integration/wbimessagebroker/library.

3) Configuring the ‘General Config’ settings.

The IS03 GUI provides a ‘General Config’ area (Figure 3.1) which allows you to configure how it connects to the Message Broker Queue Manager, along other configuration parameters.

Figure 3.1

Each of the configuration parameters are explained below:

• Queue Manager Hostname – The hostname or IP address of the system where the Message Broker Queue Manager is running. This parameter is required.

• Queue Manager TCP Port: The port which the Message Broker Queue Manager has a TCP Listener configured and running on (which was set up in step 1 above). This parameter is required.

• Queue Manager Name: The name of the Message Broker Queue Manager. This parameter is required.

• Server-connection channel name – The name of the Message Broker Queue Manager Serverconnection channel which should be used to connect. This parameter is required.

• Stats Subscription Topic: The name of the topic which IS03 will subscribe to in order to receive message flow statistics data. A default of ‘$SYS/Broker/+/StatisticsAccounting/SnapShot/#’ is specified which means that IS03 will receive SnapShot statistics for all running message flows, in any execution group. This default value can generally be left, unless you wish to subscribe to Archive statistics instead of SnapShot (In which case change it to: $SYS/Broker/+/StatisticsAccounting/Archive/# ). This parameter is required unless Stats Queue is specified. If both Stats Subscription Topic and Stats Queue parameters are specified, Stats Subscription Topic will take precedence and Stats Queue will be ignored.
• Stats Queue – Instead of gathering statistics data via the topic subscription mechanism, IS03 can read statistics data off a queue. This can be useful, for example, if you use a custom subscription to store statistics on queues for archiving purposes .By default, IS03 will perform a destructive GET when reading off the queue. To instead browse the queue, check the ‘Browse?’ option. This parameter is optional. To use it ensure that the Stats Subscription Topic field is cleared.

• Accounting Origin: If your flows use accounting origin, you can enter a value here to display only data for only the specified accounting origin. If this field is left blank, it will use the ‘Anonymous’ accounting origin (which is the default value WebSphere Message Broker uses if no Accounting Origin has been manually set). Note that if you want to have graphs which show data for two different accounting origins e.g. Company1 and Company2, you will need to run two instances of IS03, one configured to use Accounting Origin: Company1, and the other configured to use Accounting Origin: Company2. This parameter is optional.

ESB Performance test plans:

As we have gone through the briefing of Performance test tools. Next task is to build a performance test plan using the tools. Please find the explanation below for building the test plan.

Broadly Most of the ESB Interfaces can be categorized as Synchronous flows or Asynchronous flows.So to understand the Performance framework of ESB with Jmeter and supportpac let’s consider the most commonly used Scenarios Synchronous and Asynchronous ESB Flows.

Synchronous ESB Flow:

For Synchronous Flows it does suffice to use only Jmeter for loading the messages and capturing the metrics. Said that let’s create a test plan to test the webservice (Synchronous flow) in ESB. Rename this Test Plan node as WebserviceTest.

Follow below Instructions to set the test plan for WebserviceTest.

Configure Jmeter:

Add Thread Group: Add one Thread Group, which is placeholder for all other elements like Samplers, Controllers, and Listeners. Right click on WebserviceTest(our Test Plan) > Add > Threads(Users) > Thread Group. Thread Group will get added under the Test Plan (WebserviceTest) node.

As shown below the highlighted one is the thread plan. Make the changes to the thread properties to change the number of threads and then change the Rampup period,loop count  accordingly

ADD SAMPLER: To make the webservice call from Jmeter use SOAP/XML Sampler .So, Now that we have defined Threads (Concurrent Users), it is time to define the tasks that they will be performing. We will add SOAP/XML-RPC Request element. Click your right mouse button to get the Add menu, and then select Add > Sampler > SOAP/XML-RPC Request. Then, select the SOAP/XML-RPC Request element in the tree and edit the following properties as in the image below:

The following details are entered in this element:

Name: SOAP/XML-RPC Request

URL: http://localhost:7080/URI

Soap/XML-RPC Data: Enter the Soap Request message

Add Listener: The final element you need to add to your Test Plan is a Listener. This element is responsible for storing all of the results of your HTTP requests in a file and presenting a visual model of the data.

Select the Thread group element and add a View Results Tree listener (Add > Listener > View Results Tree).

RUN THE TEST PLAN: Now save the above test plan as test_webservice.jmx. Execute this test plan using Run > Start option.

VIEW OUTPUT: The following output can be seen in the listener. This confirms the webservice call is successful.

Performance Metrics: To get the actual performance metrics we need to add one more listener called ‘Summary Report’.

Select the Thread group element and add a Summary Report listener (Add > Listener > Summary Report). As a part of Summary report you can see that Throughput, number of messages (Samples), Error percentage.

Asynchronous ESB Flow:

For Asynchronous flows to capture the Performance metrics is challenging when compared to synchronous flows. To complete the life cycle of a message sometimes asynchronous application may involve multiple message flows. So, to gather performance metrics becomes challenging. To achieve this we use SupportPac IS03(Message Flow Statistics Visualiser) along with Jmeter .IS03 SupportPac which relies on the accounting and statistics facility of Message broker  has capabilities to see the real time and historic statistics data in tables, along with the capability to export all recorded data to CSV to enable custom user processing. Before we further proceed towards the testplan for performing the performance test we need to configure the Jmeter and Message Flow Statistics Visualiser with Message Broker.

Configure Jmeter:

For Jmeter the configuration is almost same as explained in synchronous flow except the sampler which depends on the connectivity protocol of the asynchronous application. For our exercise let’s consider the MQ protocol. In Jmeter to connect to queue manager we need to use JMS Point-to-Point sampler as shown in fig.

The following property changes are made to the JMS Point-to-Point sampler element:

Property	Value	Description
QueueuConnectionFactory	ConnectionFactory	This is the JNDI entry for the Connection Factory Defined within queue manager
JNDI Name Request Queue	Q.REQ	The JNDI name for JMeter to make the connection between the connection factory and queue.
JNDI Name Receive Queue	Q.REQ	The JNDI name for JMeter to make the connection between the connection factory and queue. We are using the same queue for response.
Communication Style	Request Response	This means that you need at least a service running outside of JMeter and that will respond to the requests. This service must listen to the Request Queue and send messages to the queue referenced by the message.getJMSReplyTo()
Use Request message ID	checked	You can leave JMeter to use the message ID Request (deposit) to the correlation between the incoming message and recovered.
Use Response message ID	checked	You can leave JMeter use the message identifier Response (recovery) for the correlation between the incoming message and recovered.
Time(milliseconds)	2000	This timeout is used when the message is received by JMeter if nothing is recovered in time (here 2 sec), then the item will be marked in error.
Content	Testing point to point	This is just the content of the message.
InitialContextFactory	com.sun.jndi.fscontext . RefFSContextFactory	The standard InitialContextFactory for MQ
Provider URL	file:C:/DEV_JNDI-Directory	JNDI file location

NOTE: for our test use communication style property as ‘Request only’ as we are going to use Jmeter only to load the messages for asynchronous performance testing.

The screen shot below shows above configurations:

Once Configuring sampler, create listener and save the test plan as guided in synchronous flow section.

Configure IS03 SupportPac:

Along with Jmeter we need to Configure SupportPac to retrieve metrics. Please follow below instructions to complete the IS03 Configuration setup.

1) Loading in Message Flows and Sub-flows

IS03 requires you to load in Message Flows before it is able to display them. You do this by pointing it at

their msgflow files. Perform the following steps to load in Message Flow files:

1. Select the add message flows button on the Config tab.
2. Select the parent directory where the msgflow files reside. This is likely to be the message flow project directory where Message Broker Toolkit stores the files.
3. IS03 will detect all the msgflow files within this parent directory and will prompt you with a dialogue (Figure 3.2) allowing you to load one or more of each of the flows. You will need to load in the correct number of each msgflow file. For example, if you have a simple flow which has no subflows, simply select ‘1’ next to the msgflow file. If you have a more complex flow e.g. a main flow, mainflow.msgflow , which uses two instances of the subflow tracesubflow.msgflow and one instance of the subflow errorhandler.msgflow then you would select 1 x mainflow.msgflow, 2 x tracesubflow.msgflow, 1 x

errorhandler.msgflow.

4. Select Submit and this will load each flow into a separate tab in the IS03 GUI.

Figure 3.2 – Load flows dialogue

After loading in a flow, you can view it by selecting its tab along the top of the GUI. Note that the layout of the nodes is based on the layout of the nodes in the WebSphere Message Broker Toolkit, so the nodes may need to be dragged around in the IS03 GUI for it to look correct.

2) Configuring which Statistics to graph

IS03 allows you to configure which statistics it will graph. These settings can be modified at any time.

The Config tab allows you to configure which statistics are displayed on each of the three graph types

(Message Flow Statistics, Node Statistics, Thread Statistics). To show or hide a particular statistic, simply

select or deselect the ‘selected to graph’ checkbox (Figure 3.3). The color of line a particular statistic should use can also be modified by clicking on the coloured region and selecting a new color.

Figure 3.3 – Selecting which stats to display

3) Starting statistics capture

Before you start statistics capture, ensure you have specified the ‘General config’ options correctly, as

specified in the ‘Setting Up IS03 SupportPac’ section of this document. To start statistics collection

simply click the Start stats collection button. The connection status field should go green and indicate that IS03 is successfully connected to the Queue Manager. If it goes red, indicating an error connecting, recheck your connection settings and retry.

4) Viewing statistics data

After statistics collection has successfully begun, data points will start being displayed in the node graphs. A new data point will appear each time that Message Broker publishes statistics data (i.e. every 20 seconds for Snapshot statistics). If your flow uses subflows, the statistics data for the subflow will be displayed on the subflow’s tab.

Figure 4.1 gives an overview of the GUI when a message flow tab is selected. Each of the highlighted parts of the diagram are explained in more detail below.

5) Exporting statistics data to CSV

IS03 is able to export all the statistics data which it has collected into a CSV format. This is done via the

‘Export options’ area on the Config tab (Figure 5.1). The interface gives you a configurable set of options to allow you to export exactly the statistics you are interested in.

Figure 5.1 – Export to CSV options

The CSV data is exported in a self-documenting format whereby the first row of the data defines the datafields, and the subsequent rows contain the data itself.

6) Resetting all statistics data

Select the ‘Reset all data’ button on the Config tab to clear all graphs. Note that after resetting the data, it is irretrievably lost and can no longer be exported.