Software Integration and High Performance

Below is the introduction to a paper I recently authored regarding Tuning.  These are mostly commonly known things. No major revelation here.

I've observed a behavior about Cascade Delete in DB2 7 for OS390. Suppose that I am deleting some rows from a database with this command:

DELETE FROM TS.MYTABLE
       WHERE TS.MYTABLE.MYKEY = ?                 

Usually after I insert or delete rows, I like to get the number of rows affected using the "GET DIAGNOSTICS iRows = ROW_COUNT".  

However, if Cascade Delete is turned on and MYTABLE has child rows in another table, then the GET DIAGNOSTICS instruction only returns the number of rows deleted in MYTABLE. The ROW_COUNT parameter does not return the total number of rows deleted in MYTABLE and the child table.

Jeff Hojnacki
jhojnacki@arisinsoftware.com
http://www.arisinsoftware.com

Posted by OlmstedJeff at 02:31 PM | Permalink

High Performance SOA

I submitted a paper to the Global Integration Consortium, and I intend to attend the conference in May. I am also participating as a paper reviewer. Below are a few excerpts from my paper:

Your competitor may be a click away. It is critical that your application respond to your customers at the fastest possible speed to prevent them from leaving your web site, but achieving this objective in many layered applications is not accidental. It requires an engineered design with rigorous testing and verification. Many layered applications under stress encounter forces that impact performance and are difficult to diagnose. Furthermore, beyond your local environment in the global environment, there are variables, which are way out of your control. It builds a case for standards to be adopted in each industry to ensure that business-to-business transactions perform at an acceptable level.

Successful SOA embodies messaging, transport, reliability, performance, and security. There are other attributes too, but I think these cover the minimum requirements.

Regardless how perfectly implemented, performance issues will eventually affect your SOA implementation.

My suggestion is to predict load projections based on any available information, but also forecast the hypothetical worst possible scenario.

Don’t wait. Be pro-active and accomplish rigorous testing in a lab environment before unleashing your web application to the global marketplace.

Before you jump into load testing, you should have a thorough understanding of the integration points between your application and all the other entities it touches.

SOA is not a single event or project.  It is a journey of ongoing infrastructure augmentation which must be weaved into the fabric of your systems and organization. It requires continuing evolution and periodic tuning. Change is here to stay.

Please consider getting plugged into the Global Integration Consortium and read my full paper, as well as many others.

Jeff Hojnacki
jhojnacki@arisinsoftware.com
http://www.arisinsoftware.com

Posted by OlmstedJeff at 09:56 PM | Permalink

SOA

It is my opinion that part of the SOA puzzle is the paradigm shift from traditional development to component based development. There is much to say about SOA, and much has been written. I plan to write much more about SOA, but now is not the time. Instead, I want to write in this blog entry about poor SOA solutions.

What is a poor SOA solution?  

A poor SOA solution does not provide common communication (transport) protocols which can easily be reused across hetergenous platforms.

A poor SOA solution does not provide a common messaging protocol which can be used across heterogenous platforms.

A poor SOA solution does not provide the capability to develop composite applications.

A poor SOA solution does not provide the capability to define a new application using orchestration.

There is much more than I can write about, but if you use the guidelines above, then it should be pretty easy to eliminate poor SOA solutions.

Jeff Hojnacki
jhojnacki@arisinsoftware.com
http://www.arisinsoftware.com

Posted by OlmstedJeff at 10:02 PM | Permalink

For those who have not heard about this, there is a consortium of companies and people who formed an Integration Consortium. This professional community of people are working towards a variety of objectives which you can read about on their website at http://www.integrationconsortium.org/.

One of the benefits of joining their organization is to network with peers throughout the integration industry.  There is a summit meeting in Boston on May 22-25. You can read more about it at http://www.globalintegrationsummit.com/.

I plan to attend the summit, and hope to see you there!

Jeff Hojnacki
jhojnacki@arisinsoftware.com
http://www.arisinsoftware.com

Posted by OlmstedJeff at 06:41 PM | Permalink

If you in the process of developing a J2EE application under Websphere, and you require interfaces to Websphere MQ based applications, then IBM provides you with the option to implement the communication layer two different ways.  You can use JMS or you can use the raw MQ Series Java classes. As a developer, I may prefer to have more control and lean towards using the raw MQ classes, but as an administrator, I may prefer to avoid re-inventing the wheel and use the capabilities built into Websphere JMS.

Which way is better?
The answer is that both ways work, and there is not a black and white answer saying which is better, so instead, I will offer these considerations:
 

JMS
1. JMS is the standard J2EE way to access messaging providers. Its existence is for the purpose of messaging, and it is designed to abstract you one step away from specific underlying messaging providers.
2. JMS provides support for multiple messaging providers, enabling you to switch providers without re-coding.
3. JMS provides connection pooling.
4. Under WAS 6.0, the default messaging provider is the IBM Messaging engine, and it does not require MQ Client.  JMS allows you to implement the IBM Messaging engine.
5. JMS adds RFH2 headers. If you don't want these, then you need to suppress them.
6. JMS positions you better for SOA, and it is an important piece of IBM's strategy. However, the trade off is that using JMS may not give you all the features of the underlying Messaging Engine.

MQ Series Java Classes
1. The raw Java classes give you full access to all the features of Websphere MQ.
2. With the raw MQ classes, you can install Websphere MQ Server or Client on your app server.  I prefer to implement the Client to keep it as lightweight as possible.
3. If you use the Client, then make sure you fully understand how MQI channels work.
4. The raw MQ classes do not automatically provide connection pooling, but you can implement other IBM classes to get connection pooling.
5. Beginning with version 5.3, MQ Series will cache your MQ connection information and helps improve the speed of the connection.