Comments on: Why I hate SOA in less than 200 words. http://johannesbrodwall.com/2006/06/11/why-i-hate-soa-in-less-than-200-words/ Johannes Brodwall's Musings on Software Architecture and Programming Thu, 29 Jul 2010 15:37:26 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Johannes Brodwall http://johannesbrodwall.com/2006/06/11/why-i-hate-soa-in-less-than-200-words/comment-page-1/#comment-313 Johannes Brodwall Wed, 01 Nov 2006 10:26:26 +0000 http://www.brodwall.com/johannes/blog/?p=93#comment-313 Good question, Scott. If you are going to be used by an external application, sooner or later you will have to publish a contractual interface. However, I find that most developers break up their systems into too many applications with external interfaces before this is necessary. As long as you have a well-defined group, it's no problem to have 20 or more people using continuous integration to stay agile for a long time. I guess my point is that: Yes, if you need to communicate with an external application, you need a contractual interface. But my experience is people overestimate the need to communicate with the rest of the world. (This is of course an observation from in-house development, I expect shrink wrap to follow different rules) Good question, Scott.

If you are going to be used by an external application, sooner or later you will have to publish a contractual interface. However, I find that most developers break up their systems into too many applications with external interfaces before this is necessary. As long as you have a well-defined group, it’s no problem to have 20 or more people using continuous integration to stay agile for a long time.

I guess my point is that: Yes, if you need to communicate with an external application, you need a contractual interface. But my experience is people overestimate the need to communicate with the rest of the world. (This is of course an observation from in-house development, I expect shrink wrap to follow different rules)

]]> By: Johannes Brodwall http://johannesbrodwall.com/2006/06/11/why-i-hate-soa-in-less-than-200-words/comment-page-1/#comment-84632 Johannes Brodwall Wed, 01 Nov 2006 07:26:26 +0000 http://www.brodwall.com/johannes/blog/?p=93#comment-84632 Good question, Scott.<br><br>If you are going to be used by an external application, sooner or later you will have to publish a contractual interface. However, I find that most developers break up their systems into too many applications with external interfaces before this is necessary. As long as you have a well-defined group, it's no problem to have 20 or more people using continuous integration to stay agile for a long time.<br><br>I guess my point is that: Yes, if you need to communicate with an external application, you need a contractual interface. But my experience is people overestimate the need to communicate with the rest of the world. (This is of course an observation from in-house development, I expect shrink wrap to follow different rules) Good question, Scott.

If you are going to be used by an external application, sooner or later you will have to publish a contractual interface. However, I find that most developers break up their systems into too many applications with external interfaces before this is necessary. As long as you have a well-defined group, it's no problem to have 20 or more people using continuous integration to stay agile for a long time.

I guess my point is that: Yes, if you need to communicate with an external application, you need a contractual interface. But my experience is people overestimate the need to communicate with the rest of the world. (This is of course an observation from in-house development, I expect shrink wrap to follow different rules)

]]> By: Scott P http://johannesbrodwall.com/2006/06/11/why-i-hate-soa-in-less-than-200-words/comment-page-1/#comment-312 Scott P Tue, 31 Oct 2006 04:54:49 +0000 http://www.brodwall.com/johannes/blog/?p=93#comment-312 Interesting article -- okay, I'll bite. First let me say that I agree, up-front analysis is always partly wrong. Responsibilities and interfaces will eventually change. Anyone who's ever created an API or shared component lives in that world. But, assuming a component has callers outside of a single application, how can you avoid defining a contractual interface? If components didn't have responsbilities and defined interfaces, developers calling those components would have to understand the internals of every single one of them. In a large system, that's just not realistic. Sure it can be taken to an extreme, but what's your alternative? Interesting article — okay, I’ll bite. First let me say that I agree, up-front analysis is always partly wrong. Responsibilities and interfaces will eventually change. Anyone who’s ever created an API or shared component lives in that world.

But, assuming a component has callers outside of a single application, how can you avoid defining a contractual interface? If components didn’t have responsbilities and defined interfaces, developers calling those components would have to understand the internals of every single one of them. In a large system, that’s just not realistic.

Sure it can be taken to an extreme, but what’s your alternative?

]]> By: Scott P http://johannesbrodwall.com/2006/06/11/why-i-hate-soa-in-less-than-200-words/comment-page-1/#comment-84631 Scott P Tue, 31 Oct 2006 01:54:49 +0000 http://www.brodwall.com/johannes/blog/?p=93#comment-84631 Interesting article -- okay, I'll bite. First let me say that I agree, up-front analysis is always partly wrong. Responsibilities and interfaces will eventually change. Anyone who's ever created an API or shared component lives in that world.<br><br>But, assuming a component has callers outside of a single application, how can you avoid defining a contractual interface? If components didn't have responsbilities and defined interfaces, developers calling those components would have to understand the internals of every single one of them. In a large system, that's just not realistic.<br><br>Sure it can be taken to an extreme, but what's your alternative? Interesting article — okay, I'll bite. First let me say that I agree, up-front analysis is always partly wrong. Responsibilities and interfaces will eventually change. Anyone who's ever created an API or shared component lives in that world.

But, assuming a component has callers outside of a single application, how can you avoid defining a contractual interface? If components didn't have responsbilities and defined interfaces, developers calling those components would have to understand the internals of every single one of them. In a large system, that's just not realistic.

Sure it can be taken to an extreme, but what's your alternative?

]]>