(WMB) How to fix broker instance after password change ?

1. Fix DB2 services – The easiest way to do this is switch to services view in Windows and spot the services that are failing to start. Next right click these services and from the context menu select properties. Select the Log On tab and change the password used for these services. 

2. Next you need to fix the service password for your configuration manager. For this you need to issue mqsichangeconfigmgr <config_mgr_name> -a <password>. Start your configuration manager by issuing a mqsistart command following this.

3. The last piece you need to fix is your broker instance. For this you need to fix both service password and data source password. Issue a mqsichangebroker <broker> -a <Broker_Password> -p <DataSource_Password>. Start your broker instance by issuing a mqsistart command.

Calling any service using WebService

A Service can be called in different ways, for example using SCA , Webservice or Messaging models.
In some specific requirement we can call it using standalone java program, input for this program would be the endpoint & message (input) to be passed.


import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.net.URL;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.soap.MessageFactory;
import javax.xml.soap.SOAPBody;
import javax.xml.soap.SOAPConnection;
import javax.xml.soap.SOAPConnectionFactory;
import javax.xml.soap.SOAPException;
import javax.xml.soap.SOAPFactory;
import javax.xml.soap.SOAPMessage;
import javax.xml.soap.SOAPPart;
import javax.xml.transform.stream.StreamSource;
import org.w3c.dom.Document;
import org.xml.sax.SAXException;


public class SendSoapMessage {
public static String sendMessage (String message) {
String response = "";


try {
SOAPMessage soapMessage = convertSoapStringMsgToSoapMessage(message);
soapMessage.saveChanges();
SOAPConnectionFactory connectionFactory = SOAPConnectionFactory.newInstance();
SOAPConnection soapConnection = connectionFactory.createConnection();
URL endpoint = new URL ("http://localhost:9081/TestWeb/sca/SampleExport1?wsdl"); //endpoint address 
SOAPMessage resp = soapConnection.call(soapMessage, endpoint);
resp.writeTo( System.out );
soapConnection.close();
ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
resp.writeTo(byteArrayOutputStream);
response = new String(byteArrayOutputStream.toByteArray());
}


catch (java.io.IOException ioe) {
ioe.printStackTrace();
}
catch (SOAPException soape) {
soape.printStackTrace();
}
return response;
}


public static void main (String args[]) {
String response=sendMessage(" <soapenv:Envelope xmlns:soapenv=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:q0=\"http://Test/Sample\" xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"> <soapenv:Body> <q0:operation1>  <input1>87</input1>   </q0:operation1>  </soapenv:Body>  </soapenv:Envelope>"); // fill your input to be posted.
//in above example name of the operation is operation1 & input is input1
}


public static SOAPMessage convertSoapStringMsgToSoapMessage (String soapText) {
try {
MessageFactory msgFactory  = MessageFactory.newInstance();  
SOAPMessage message = msgFactory.createMessage();  
SOAPPart soapPart = message.getSOAPPart();  
byte[] buffer  = soapText.getBytes();  
ByteArrayInputStream stream  = new ByteArrayInputStream(buffer);  
StreamSource source = new StreamSource(stream);  
soapPart.setContent(source);  
message.writeTo(System.out); 
return message;
}
catch(Exception e)
{return null;}

}
}

(WMB) Publisher Subscriber in WMB 7.0

Publish/Subscribe architecture is useful in scenarios where P2P might not be suitable, reasons are obvious :

• Problems with large numbers of senders & receivers.
• Problems when senders & receivers change frequently; (Becomes unmanageable)

How it works in WMB 7.0

• MQ based subscription messages registered using a special queue SYSTEM.BROKER.CONTROL.QUEUE.
• Do not need to define a queue to handle subscription requests.
• Publication messages handled within the flow.
• Publication node receives publication messages and distributes to the subscribers matching the topic within the publication message.

Subscriber Flow

MQINPUT ->>  COMPUTE ->> MQOUTPUT (SYSTEM.BROKER.CONTROL.QUEUE)

Code for Compute Node :

                    CALL CopyEntireMessage();

                         SET OutputRoot.MQRFH2.psc.Command = 'RegSub'; --RegSub is a keyword

                         SET OutputRoot.MQRFH2.psc.Topic = 'SPORTS';  --TopicName

                         SET OutputRoot.MQRFH2.psc.QName = 'DATA';  -- QueueName

                         SET OutputRoot.MQRFH2.psc.QMgrName = 'QM';  -- QueueManagerName

                         Declare PTR REFERENCE to OutputRoot.MQRFH2;

                         Detach PTR;

                         attach PTR TO OutputRoot.MQMD AS NEXTSIBLING ;

 Publisher Flow

MQINPUT ->> COMPUTE ->> PUBLICATION NODE

Code for Compute Node :

                    CALL CopyEntireMessage();

                         SET OutputRoot.MQRFH2.psc.Command = 'Publish'; -- Publish is a keyword

                         SET OutputRoot.MQRFH2.psc.Topic = 'SPORTS'; --TopicName

                         Declare PTR REFERENCE to OutputRoot.MQRFH2;

                         Detach PTR;

                         attach PTR TO OutputRoot.MQMD AS NEXTSIBLING ;

                         RETURN TRUE;
OR

Exception Scenario :

While subscribing, we may get following warning :

And no subscription happens. I solved this issue by having the logged user name less then 12 chars, we can also see : http://www.mqseries.net/phpBB2/viewtopic.php?t=1056&highlight=2035+sid

(WMB) Working with Remote DB

In Message Broker, database can be accessed through predefined database nodes like Database, DatabaseDelete, DatabaseInsert, DatabaseUpdate etc.

Database can also be accessed through Compute and JavaCompute nodes.

Compute nodes are written by using ESQL code. Compute nodes are comparatively faster in performance compared to JavaCompute nodes.

Connecting to DB through compute node :

• A Compute node gets access to a database through System DSN.
• System DSN can be configured through ODBC Data Sources.
• In order to connect to a DB it is mandatory that to have DB specific driver available in the machine.
• We need to give 'DataSourceName' & 'Database Alias'.
• Click on Add next to Database Alias option, a new window opens up, fill the necessary details like database name, hostname, port etc.
• Click Ok.

Story is not over yet, broker still does not know what you have done so far , so the next step would be to update broker configuration by following commands :

mqsistop <<BrokerName>>  {Stop the Broker}

mqsisetdbparms <<BrokerName>> -n <<DataSourceName>> -u <<UserName>> -p <<Password>>

mqsireload <<BrokerName>> -e <<ExecutionGroupName>>

mqsistart <<BrokerName>>  {Start the Broker}

Excel as DB in Java

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;


public class Test {
public static void main(String[] args) throws SQLException {
Statement stmt = null;
ResultSet rs = null;
Connection con = null;
String serialNo ="";
try {
Class.forName("com.hxtt.sql.excel.ExcelDriver");
con = DriverManager.getConnection("jdbc:excel:/c:/temp/Layout.xls?WRITE=true","", "");
stmt = con.createStatement();
String excelQuery = "select * from [Sheet1$]";
rs = stmt.executeQuery(excelQuery);
while (rs.next()) {
serialNo = String.valueOf(rs.getInt(1));
System.out.println(serialNo);
}
}
catch (Exception e) {
e.printStackTrace();

} 
finally {
try {
rs.close();
stmt.close();
con.close();
} catch (SQLException e) {
e.printStackTrace();
}

}
}
}

//Note : Jar required : Excel_JDBC30.jar

Reading from Queue using Java

import com.ibm.mq.MQC;
import com.ibm.mq.MQEnvironment;
import com.ibm.mq.MQException;
import com.ibm.mq.MQGetMessageOptions;
import com.ibm.mq.MQMessage;
import com.ibm.mq.MQQueue;
import com.ibm.mq.MQQueueManager;


public class MQMessageReader {
private MQQueueManager qMgr; 
private int openOptions;
private MQQueue replyQueue; 
MQMessage replyMsg = new MQMessage();
public MQMessageReader()
{}

public MQMessageReader(String qManager, String aRequestQueue) {
try {
MQEnvironment.hostname = "localhost";
MQEnvironment.port = 1414;
MQEnvironment.channel = "SYSTEM.ADMIN.SVRCONN";   
//MQEnvironment.enableTracing(1, System.out);           //  Set MQ tracing on

try{
qMgr = new MQQueueManager(qManager);
}catch(MQException e){
Object o = e.exceptionSource;
}
openOptions = MQC.MQOO_OUTPUT;
// Now specify the queue that we wish to open, and the open options...
replyQueue = qMgr.accessQueue(aRequestQueue, openOptions,null,null,null);             
}catch (MQException ex){
//System.exit(1);
}
catch (Exception e){
//System.exit(1);
}
}
public static void main(String arg[])
{
MQMessageReader messageReader = new MQMessageReader("QM","SEND");
messageReader.receive("AMQ QM          MÈñN à ", "SEND", 18000); // should be messageID,queueName & waitTime
}
public String receive(String messageId, String receiveFromQueue, int waitTime) {
String ssoResponse = null;
try {
int openOptions = MQC.MQOO_INPUT_AS_Q_DEF | MQC.MQOO_OUTPUT
| MQC.MQOO_INQUIRE | MQC.MQOO_BROWSE;
MQQueue queue = qMgr.accessQueue(
receiveFromQueue, openOptions, null, null,
null);
MQException.log = null;
MQGetMessageOptions gmo = new MQGetMessageOptions();
gmo.options = MQC.MQGMO_WAIT | MQC.MQGMO_CONVERT;
gmo.waitInterval = waitTime;
byte byteArray[] = messageId.getBytes();
queue.get(replyMsg, gmo);
ssoResponse = replyMsg.readStringOfByteLength(replyMsg.getTotalMessageLength());
System.out.println(ssoResponse);
} catch (Exception e) {
e.printStackTrace();
}
return ssoResponse;
}
}

Writing to Queue using Java

import com.ibm.mq.MQC;
import com.ibm.mq.MQEnvironment;
import com.ibm.mq.MQException;
import com.ibm.mq.MQMessage;
import com.ibm.mq.MQPutMessageOptions;
import com.ibm.mq.MQQueue;
import com.ibm.mq.MQQueueManager;


public class MQMessageSender {
private MQQueueManager qMgr;
public MQMessageSender() {
MQEnvironment.hostname = "localhost";
MQEnvironment.port = 1414;
MQEnvironment.channel = "SYSTEM.ADMIN.SVRCONN";
MQEnvironment.properties.put(MQC.TRANSPORT_PROPERTY,MQC.TRANSPORT_MQSERIES);
}
public void sendMQMessage(String qName,String messageToPost) {
MQQueue queue = null;
try {
qMgr = new MQQueueManager("QM");
int openOptions = MQC.MQOO_INPUT_AS_Q_DEF | MQC.MQOO_OUTPUT;
queue = qMgr.accessQueue(qName, openOptions, null, null, null);
MQMessage msg = new MQMessage();
msg.format = MQC.MQFMT_STRING;
msg.writeBytes(messageToPost);
MQPutMessageOptions pmo = new MQPutMessageOptions();
queue.put(msg, pmo);
} catch (MQException ex) {//...//}
                   catch (java.io.IOException ex) {//..//}
 finally {
try {
queue.close();
qMgr.disconnect();
} catch (MQException e) {
}
}
}
public static void main(String arg[])
{
MQMessageSender messageSender = new MQMessageSender();
messageSender.sendMQMessage("SEND","Hi Blog");
}
}

(WID/WPS) JMSCustomDataBinding

This post is related to a specific requirement where client sends message (Business Object format) to a Queue based system & receive response again from a queue based system (String format)


Now the requirement is :
In Request flow : To convert message (BO Format) to message (String Format) before sending it to queue.
In Response flow : To convert message (String Format) to message (BO Format) before sending it to caller (may be a business process) for further processing.
We have to make use of custom data binding which would intercept the communication between service provider & consumer.


We have to set the binding property of MQ import with 'Default data format' value which is "JMSCustomDataBindingStrImpl" in this case (Shown in diagram below)

This binding class JMSCustomDataBindingStrImpl extends JMSDataBindingImplXML class & override write() (Used when writing to the queue : Request part) & read() (Used when reading from the queue : Response part) methods.


Here is the code :
public class JMSCustomDataBindingStrImpl extends JMSDataBindingImplXML

{
/*
* write method is overwritten here to post the string data into Queue as text message.
* message variable get the value from the string process variable form the BPEL.
* @see com.ibm.websphere.sca.jms.data.impl.JMSDataBindingImplXML#write(javax.jms.Message)
*/
public void write(Message message) throws JMSException
{
String strMessagea = null;
commonj.sdo.DataObject dataObject = this.convertStrToDataObject(); 
strMessagea =  dataObject.getString(0);
System.out.println(" Message To Post in the Queue :" + strMessagea );
((TextMessage)message).setText(strMessagea);
System.out.println(" Message posted successfully.....");
}
private DataObject convertStrToDataObject() 
{
// TODO Auto-generated method stub
String bo = getAsString();
commonj.sdo.DataObject dataObject = null;
try {
// create BO from XML string
byte[] C_START = new byte[] {'<', '!', '[', 'C', 'D', 'A', 'T', 'A', '['};
byte[] C_END = new byte[] {']', ']', '>'};
String encoding = "UTF-8";
String Cstart = new String(C_START, encoding);
String Cend = new String(C_END, encoding);
if (bo.startsWith(Cstart)) {
bo = bo.substring(Cstart.length(), bo.length()-Cend.length());
}
com.ibm.websphere.bo.BOXMLSerializer boXMLSerializer = (com.ibm.websphere.bo.BOXMLSerializer) com.ibm.websphere.sca.ServiceManager.INSTANCE.locateService("com/ibm/websphere/bo/BOXMLSerializer");
com.ibm.websphere.bo.BOXMLDocument boDoc = boXMLSerializer.readXMLDocument(new java.io.ByteArrayInputStream(bo.getBytes(encoding)));
dataObject = boDoc.getDataObject();
}
catch(java.io.IOException ex){
}
return dataObject;
}
public void read(Message responseMessage) throws JMSException {
JMSTextMessage txt= (JMSTextMessage)responseMessage;
String responseXMLString = txt.getText();
System.out.println("The response string is : " + responseXMLString);
com.ibm.websphere.sca.ServiceManager serviceManager = new com.ibm.websphere.sca.ServiceManager();
com.ibm.websphere.bo.BOFactory factory = (com.ibm.websphere.bo.BOFactory) serviceManager
.locateService("com/ibm/websphere/bo/BOFactory");
DataObject responseBO = factory.create("http://Test","InputBO");
responseBO.setString("field1", responseXMLString);
setDataObject(responseBO);

}
}

Orchestration Vs Choreography

These words are like a googly in SOA field, There is no clear separation of definitions for these 2 terms, Debates & discussions are still going on to clarify the differences. In mid of all these discussions, we should have some knowledge about these terms; So here I am with some information about these terms. First I will give few examples & then jump into the definition.


Ex 1 : (Music & Dance)
In Orchestration (Orchestra), there’s someone the conductor (Director/Instructor/Manager) — who tells everybody in the orchestra what to do and makes sure they all play in sync.
In Choreography (Dance), every dancer follows a pre-defined plan — everyone independently of the others.


Ex 2 : (Our workplace : Office)
As in real organisation, we employ both these techniques – orchestration by means of formal hierarchy and choreography within small teams for effective team work. Using both these techniques, real organisations can achieve their goal.


Definition :
Suppose a WS(P) (Central Process) is calling another WS(C), WS(C) do not "know" (and do not need to know) that they are involved in a composition process to achieve a higher goal.Only the central coordinator {WS(P)} of the orchestration is aware of this goal;
So the orchestration is centralized with explicit definitions of operations and the order of invocation of WS(C1),WS(C2)..
Choreography, in contrast, does not rely on a central coordinator. Rather, each WS(C) involved in the choreography knows exactly when to execute its operations and with whom to interact. 
Choreography is a collaborative effort focusing on the exchange of messages in public business processes. 
All participants in the choreography need to be aware of the business process, operations to execute, messages to exchange, and the timing of message exchanges. 


Orchestration
• Has a central conductor 
• Each performer performs tasks independently 
• Tasks produce real world effect 
• Performer is not aware of the orchestrating conductor(s) using it.


Choreography
• Entities interact with each other to produce real world effect 
• No central conductor, no overall responsibility 
• Each entity carry part of responsibility 


Note : WS(P) -> Parent Webservice & WS(C) -> Child Webservice

(WID/WPS) CEI & CBE ?

The common event infrastructure or CEI is one of the SOA core components that are a part of WPS. 
CEI is available to all the supporting services and service components that are running in the process server environment.All of these supporting services and service components have the ability to generate events that can be handled by CEI and then handled by various clients such as those provided by Tivoli® and WebSphere Business Monitor. 


The event definition is being standardized through the OASIS standards body  so that other companies as well as customers can use the same infrastructure to monitor through-out their environments.                                                                                                                                                                                                                                                                                                                                                                  
It provides facilities for the runtime environment to persistently store and retrieve events from different programming environments. This post briefly introduces the basic event-related concepts:

• Common Event Infrastructure (CEI)
• Common Base Events (CBE)

Common Event Infrastructure

In WESB, the CEI is used to provide basic event management services, such as event generation, transmission, persistence, and consumption. CEI was developed to address industry-wide problems in exchanging events between incompatible systems, many of which employed different event infrastructures, event formats, and data stores.

Common Base Event

Although CEI provides an infrastructure for event management, it does not define the format of events. This is defined by the Common Base Event specification, which provides a standard XML-based format for business events, system events, and performance information. Application developers and administrators can use the Common Base Event specification for structuring and developing event types.

(WID/WPS) Data Handler

What ?
It is a reusable transformation logic independent of a specific transport protocol like JMS or HTTP. 


How to use ?
It can be invoked from data bindings or Java components.


Why ?
In our SOA implementation, business data flows between service providers and service consumers over a variety of protocols (HTTP, JMS, MQ, EIS and so on) in a variety of data formats such as CSV (comma separated value), delimited, fixed width, COBOL and so on. Mechanism of carrying this data is different in different protocols, means the same business data is being carried by JMS & HTTP protocol differently.


The format in which business data flows on the wire between service provider and service consumer is referred to as the native format. Business process components running on WPS or WESB understand business data as business objects but they do not understand the native format (in which the data is flowing over wire). 


Business Object Serializes to Native Format
Native format De-serializes to BO


WPS data bindings can be developed to serialize and de-serialize business data. For these scenarios WPS introduces the concept of data handlers.
Data handlers can be configured on some bindings and can be used in flow components. Unlike data binding interfaces,the data handler interface is protocol neutral, which enables data handlers to be usable across the bindings.


For ex : If service consumer sends request in xml format & if provider understands only CSV format then a data handler can be used to convert data from xml to CSV format and this can be called either from Java or Binding.


For more info: http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.wbit.620.help.config.doc/topics/createdh.html


Creating a data format transformation resource configuration : http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.wbit.620.help.config.doc/topics/tconfigeisdh.html

Custom DataHandler :
http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r5m1/index.jsp?topic=%2Fcom.ibm.wbpm.wid.integ.doc%2Ftopics%2Fr_customdatahandler.html

(WID/WPS) Service Binding Types

Imports and exports require binding information, which specifies the means of transporting the data from the modules.
An import binding describes the specific way an external service is bound to an import component.
An export binding describes the specific way a module's services are made available to clients.


The SCA or default binding lets your service communicate with other services in other modules.
An import with an SCA binding lets you access a service in another module.
An export with an SCA binding lets you offer a service to other modules.
A Web service import binding allows you to bind an external Web service to an import.
A Web service export binding provides a service to external clients as a Web service.


The Web service binding can use a transport protocol of either SOAP/HTTP (SOAP over HTTP) or SOAP/JMS (SOAP over JMS).Note that WebSphere Integration Developer supports several types of JMS data bindings: JMS, MQ JMS and generic JMS.
The only JMS data binding type that is supported with the Web services binding is JMS. Therefore, the only transport protocol that is supported is SOAP/JMS.SOAP/MQ JMS,SOAP/generic JMS & SOAP/MQ (native) transport protocol is also not supported.


The Hypertext Transfer Protocol (HTTP) binding, in contrast to the preceding Web service binding, assumes the binding is working with native HTTP applications and exposes a model more familiar to this audience.


The external service wizard creates imports and exports representing a service on an EIS system. The bindings created are of an EIS type. An EIS binding provides synchronous communication with the service on the EIS system. Java™ Message Service (JMS), generic JMS, WebSphere® MQSeries® (MQ) and WebSphere MQSeries JMS (MQ JMS) bindings are used for interactions with messaging systems, where asynchronous communication through message queues are critical for reliability. An import (though not an export) may also have a stateless session EJB binding.


For more info : http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.wbit.620.help.prodovr.doc/topics/cwebservbindings.html

WMB Migration From V6.1 to 7.0

Following is the migration done on V7.0 from V6.1 :


Message Broker Version 7 will not contain a Configuration Manager

• Brokers become responsible for deployment, management and enforcement of administrative security.
• Existing tools administer each broker directly.

Significant simplification of the broker operational model

• Fewer installed and configured components.
• Single view of the broker environment - No synchronization required.

The Configuration Manager really has gone -  It has not “moved inside the broker”.


Long-standing niggles have been eliminated

• One-step broker creation (no Configuration Manager association step)
•  No service user ID requirement on non-Windows platforms.
• No “Deployment already in progress” messages.
• No Configuration Manager / Broker synchronization problems
• Cancel deployment.
• Performance.

ConfigManagerProxy (CMP) API changes

• Administration API simplified
• Removal of Configuration Manager.
• Removal of publish / subscribe component (now in WebSphere MQ)
• Package names, class names and method signatures unaffected
• Support for version 6.0 / 6.1 applications.
• Applications will compile without change
• Applications that do operations that are relevant in version 7 should continue to work.

Summary

• The Configuration Manager has been removed in Message Broker version 7.
• This significantly simplifies operational management
•  No domains.
• Single deployment type.
• The Message Broker Toolkit, Message Broker Explorer, command line interface, and user application connect directly to brokers.
• The broker environment is easier to manage.
• One view of all broker components.
• More information returned to tools.
• Improved connect and deployment times.

Additional information can be read from http://webspheremb.blogspot.in/2011/07/message-broker-faq-25.html

WMB V7.0.0.1 Administration API

In real time we may deploy/undeploy message flows based on some business logic/condition, Also we may set certain properties like debug port, configurable service properties etc of the broker/execution group/message flows at runtime.

All above mentioned flexibility can be achieved through this API.

Scenario : Before running any message flow(MQ based) we should have all queues created (which are used by the flow), We can use this API to list all the queues used by any execution group/message flow & then create these queues either manually or programmatically. This is very useful when we just have the BAR file & don’t have access to the message flows.

For more info follow the below doc link

https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0ByotHxAO08TDY2Y5NGJjMjEtMzk0OS00ZDgxLTlkNTYtNDljZjA0NTEzYzEz&hl=en_US

This doc lists few of the features provided by API.

I have given sample Java programs to deploy/undeploy BARs.

WMB 6.1 Administration Basics

This particular post includes run time broker configurations to run a sample broker application.


Configuration manager & brokers are supported by queue manager.Communication happens between broker & Configuration manager using queue manager.


Following steps are required for broker before we start development : 


Open Command Console.
1) Create a queue manager (For ex queue manager name is BRQM)
    crtmqm BRQM


2) Create a broker (For ex broker name is BROK, username/password is user/pwd, queue manager is BRQM, database name is         MY_DB with dbuser/dbpwd as credential)
     mqsicreatebroker BROK -i user -a pwd -q BRQM -n MY_DB -u dbuser -p dbpwd


3) Create a Configuration manager (For ex configuration manager is CONFIGMGR, username/password is user/pwd) 
     mqsicreateconfigmgr CONFIGMGR -i user -a pwd -q BRQM

WMB 6.1 Basics

What ?


WMB is a broker engine that can perform message transforming and routing from different participants to different destinations based on user-defined rules, so that diverse applications can exchange information in dissimilar forms, with brokers handling the processing required for the information to arrive at the right place in the correct format.
WMB provides a connectivity layer for process engines that choreograph the flow of activities between services. It is WebSphere Message Broker’s responsibility to deliver service requests,rerouting or transforming them if appropriate.


Components
I) Broker : The broker is a set of application processes that host and run message flows.
When a message arrives at the broker from a business application, the broker processes the message before passing it on to one or more other business.The broker routes, transforms, and manipulates messages according to the logic defined in their message flow applications.
Each broker uses a database to keep the broker’s configuration information and the message sets together with message flows deployed to it, which will be loaded at the start time.


II) Execution group : Execution groups enable message flows within the broker to be grouped together.
Each broker contains a default execution group. Additional execution groups can be created as long as they are given unique names within the broker.
Each execution group is a separate operating system process and, therefore, the contents of an execution group remain separate from the contents of other execution groups within the same broker.


Note :

EG(execution group) is a process.
Why EG :  
a) Degree of separation( For different sections like : Banking, Mutual funds, Credit card related stuffs we create different EG) , for security purpose,high availability of bars'.
c) For High availability brokers should communicate to each other.



III) Configuration manager : The Configuration Manager is the interface between the Message Brokers Toolkit and the brokers in the broker domain. The Configuration Manager stores configuration details for the broker domain in an internal repository, providing a central store for resources in the broker domain.
The Configuration Manager is responsible for deploying message flow applications to the brokers. 
The Configuration Manager also reports back on the progress of the deployment and on the status of the broker.
When the Message Brokers Toolkit connects to the Configuration Manager, the status of the brokers in the domain is derived from the configuration information stored in the Configuration Manager’s internal repository.


Note :

a) CM maintains the repository with broker's Id, Queue manager, channel, port etc as & when it comes to topology.
b) CM gives UUID (Universal unique id) to Broker.
c) CM sends the request to broker in an xml file (deployment request)
For more info : http://www.ibm.com/developerworks/websphere/library/techarticles/0706_lucas/0706_lucas.html


IV) User name server : A user name server is an optional component that is required only when publish/subscribe message flow applications are running, and where extra security is required for applications to be able to publish or subscribe to topics. 
The user name server provides authentication for topic-level security for users and groups that are performing publish/subscribe operations.


Broker domain : Brokers are grouped together in broker domains. 
A broker domain contains one or more brokers and a single Configuration Manager. It can also contain a user name server.
The components in a broker domain can exist on multiple machines and operating systems, and are connected together with WebSphere MQ channels.
A broker belongs to only one broker domain.


V) Best Practice : http://andypiper.files.wordpress.com/2007/06/messagebrokercodedeploy.pdf



Supports for Administrator

a) Control commands ( MQSI Commands : System integrator)
b) Broker Toolkit.
c) Configuration manager proxy API (CMP API)
d) Websphere broker explorer.


Supports for Developers
a) MB Toolkit
b) ESQL
c) Java APIs