Comments for Tieu Luu's Blog

Comment on Why All SOAs Need ESBs by Tieu H Luu

Tieu H Luu — Sat, 08 Aug 2009 03:17:20 +0000

Hi Rich. Thanks for the comment, hope things are going well for you over at Progress. That's an interesting approach you describe using ServiceMix. I didn't know it was also an OSGi container.

Comment on Why All SOAs Need ESBs by Rich Newcomb

Rich Newcomb — Thu, 06 Aug 2009 12:48:08 +0000

I see a lot of teams implementing integration solutions using Apache Camel and ActiveMQ. In many cases they are choosing an OSGi version of ServiceMix to host these capabilities — but that is for the OSGi container and management capabilities instead of the ESB capabilities (JBI).

Comment on Why All SOAs Need ESBs by Tieu H Luu

Tieu H Luu — Tue, 04 Aug 2009 02:14:19 +0000

That is certainly true. If you need multiple capabilities it can be nice to have all of those coming from a single integrated suite. I can see the benefits of that from say, an interoperability or maintenance perspective. From a performance perspective, I'm not that convinced performance improves because one is using capabilities from a single suite.

Comment on Why All SOAs Need ESBs by Thomas Rischbeck

Thomas Rischbeck — Thu, 30 Jul 2009 14:42:32 +0000

Apart from the marketing slant i think one justification for this is that often you may want to combine various capabilities for your integration needs. it can make sense then to not implement every capability or "infrastructure service" (say messaging, adapters, transformation) in separation. The reason are performance and maintenance aspects.

Comment on Guard Your Data Services Carefully by Nedra

Nedra — Mon, 10 Nov 2008 17:11:00 +0000

Good post.

Comment on Service Reuse by Steve Jones

Steve Jones — Mon, 30 Jun 2008 11:03:00 +0000

I blogged about this a while ago Services aren't about reuse its about use a very different proposition.

Comment on Are You Really Building an SOA? by Tieu H Luu

Tieu H Luu — Tue, 26 Sep 2006 02:12:00 +0000

Steve,

Agree, I did notice that the key word is "may". So the part about "being under the control of different ownership domains" is certainly optional. But if that part of the definition doesn't apply, then what do you have left in the definition--"a paradigm for organizing and utilizing distributed capabilities". In this case, just about any distributed system out there can be considered an SOA and I'm sure we can all cite examples of distributed systems we've built in the past that we would not consider SOA.

I will admit that it doesn't do the document justice because I'm taking this definition out of the context of the rest of the document which does a good job of further clarifying SOA. However, I just think there are other concepts of SOA discussed in the document that are more unique to SOA that should have made it into the "one liner definition" instead of the optional part about being under different ownership domains.

For example, the concepts of visibility, interaction, and effect are used heavily throughout the rest of the document to further explain SOA. I would have preferred to see the key notions extracted out of those and put into the one liner definition.

-Tieu

Comment on Are You Really Building an SOA? by Steve Jones

Steve Jones — Mon, 25 Sep 2006 08:18:00 +0000

The key word is "may" they don't have to be under different controls. So thinking about your product example, when someone else used it then in effect they used services that were in many ways under your control.

Different organisational controls aren't mandated by the SOA RM, but what it is saying is that this is an important consideration that needs to be allowed for.

What did you think of the rest of it?

Comment on SOA Data Strategy by Anonymous

Anonymous — Fri, 26 May 2006 13:43:00 +0000

I have been working on such an approach, using the federal Data Reference Model as a framework. Would be interested in your paper, but could not find it yet.

I will check back.

CES