Using API for Middleware......from Mark's Blog..

I worked with Mark Michelis [I call him The Microsoft Guru... :-) ] while I was providing Integration Strategy for ITRON.... based on the work that we have done together Mark blogged his experience on his blog .....

I thought it would be good to share the link of that blog....

http://mark.michaelis.net/Blog/UsingLineOfBusinessAPIsFromMiddleware.aspx

Do you need an Integration Competency Center?

Having worked on Tibco product development, and extensive solution deployment, I found that an integration governing body is needed for implementing the "right integration solution". Given the complexity of integration solutions and the amout of energies that need to be spent for connecting to various end points, without a doubt I have doubts that anyone would say no for an Integration Competency Center established to leverage and exploit the integration infrastructure. As there are number of projects that are rolled out in the enterprise the more the need for ICC.

The following picture is from one of the whitepapers that I have written during my tenure at Aalayance Inc., . This indicates what makes a good case for ICC to be established.

However this picture would not give any information as how one could determine whether an enterprise needs a competency center or not. This thought has been lingering in my mind for so long and based on the 20 odd integration deployments and strategies that I have put together all through, I tried to abstract the criteria based on which one can tell with a good amount of confidence whether an ICC is needed for an enterprise or not.....

The above depicted tool can be used to score against each of the criterion and then if the total score is >24, the enterprise definitely needs an ICC, if it is <20>

Note:----This above depicted model needs to be used with other dimensions to accurately determine the Fit-Gap analysis. Aalayance Inc., specializes in doing the same, and we used the same model that was extended multi-dimensionally and used rigoruosly during implementations by Aalayance Inc., [www.aalayance.com]

SOA and Middleware...

Middleware and SOA are very near relatives!!!! for the fact that SOA is primarily built on the principles of exploiting interop.

Historically if you look at the way the apps have changed the face, they have traditionally grown from monolithic to component based applications. Similarly interop traditionally started with Remote calls and grew to completely transparent way of executing.

With the explosion of internet and the W3C stds - it was made possible to exploit the true COMPONENT based architecture (which in my opinion has taken the shape of SOA - with service being self-executable component that can serve a business function).

Since the major problem that is solved using middleware is to transform and transport the data across applicatons, using SOA design patterns can easily leverage the middleware. However, having said that, to run a predictive business, any enterprise will have to leverage "Event Generation" and "Event Analysis" - which can be easily achieved through Event Driven architecture.

--- note: will post Part-2 of this along with some of the major differences between EDA and SOA and how they both can be exploited

8:48 PM

Capacity considerations for Integration...

A posting that I have done on the IT tool box reg. the Capacity considerations... thought will be good for sharing...

bharath.



Hi Satyendra:

First thing, for the scenarios that you are
implemeting the instrumentation needs to be developed
based on what needs to be measured. Typically every
deployment is different and metrics defintion should
be done in accordance with the CRP if has been carried
out during the design.

Now, coming the what part, as you have presented you
those are few generally used metrics, also you may
want to add the round-trip time, time taken by each
component during the process execution, through put,
you may also want to capture the waist-point for the
same so that you have the inputs on how you can scale
up the solution as such.

Coming the stress, as per your definition, the
throughput rate should give you the details of how
many messages can be queued [this again depends on
your design choices you might have made]

Coming, to TIBCO, TIBCO cannot give any metrics which
are specific to your deployment scenarios, it can
definitely give the metrics about the products - as
you have mentioned ems.. etc., As mentioned above you
need to put the instrumentation as per your need to
tap the metrics.

Hope this helps,
Cheers,
Bharath.

Welcome!!!

After working on Integration deployments and componnet based development, initiated the idea of hosting this blog to share across the various experiences that would be useful to the community from integration solutions perspective.

Open to all the integration folks