Wednesday, May 17, 2006

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

Thursday, May 11, 2006

SOA and Middleware

Iam interested to know how SOA and middleware are coupled.
where can i find more and good info to start learning about SOA.


Monday, May 08, 2006

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...


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,

Thursday, May 04, 2006


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