Comments on: The Rocky Road to SOA http://www.udidahan.com/2004/04/14/the-rocky-road-to-soa/ Enterprise Development Expert & SOA Specialist Sat, 11 Feb 2012 15:16:10 -0600 http://wordpress.org/?v=2.8.4 hourly 1 By: Mehran Nikoo http://www.udidahan.com/2004/04/14/the-rocky-road-to-soa/comment-page-1/#comment-86 Mehran Nikoo Fri, 16 Apr 2004 01:53:57 +0000 http://wp_630.weblogs.us/archives/58#comment-86 Udi, I agree with Rocky. I believe using SOA internally in an application does not make sense. Although we can argue that any layer in an application providers services to upper layers, but it is not what SOA is all about. Looking at each layer as another service provider makes the application more comples, reduces cohesion between components and potentially impacts performance and scalability. This also brings up the idea that SOA is replacing existing OO concepts. Each application has its own fiefdom. Internal components of the application know each other very well and so trust each other. That's how they can work in an efficient manner. I agree with your point "The tiered architecture can't be just wrapped up in web services and called SOA", but I don't believe that SOA necessarily means a redesign of the application. SOA does not need to use Web Services, as long as it provides well-defined services, that will do. For example a helpdesk application, which facilitates taking calls from the customers can follow SOA rules if it can notify a messaging system (could be MSMQ, BizTalk, FTP, etc) whenever a call is recorded. We don't have to redesign the application to call it SOA-compliant. Looking forward to more ideas on this :) Udi, I agree with Rocky.

I believe using SOA internally in an application does not make sense. Although we can argue that any layer in an application providers services to upper layers, but it is not what SOA is all about.

Looking at each layer as another service provider makes the application more comples, reduces cohesion between components and potentially impacts performance and scalability. This also brings up the idea that SOA is replacing existing OO concepts.

Each application has its own fiefdom. Internal components of the application know each other very well and so trust each other. That’s how they can work in an efficient manner.

I agree with your point “The tiered architecture can’t be just wrapped up in web services and called SOA”, but I don’t believe that SOA necessarily means a redesign of the application. SOA does not need to use Web Services, as long as it provides well-defined services, that will do. For example a helpdesk application, which facilitates taking calls from the customers can follow SOA rules if it can notify a messaging system (could be MSMQ, BizTalk, FTP, etc) whenever a call is recorded. We don’t have to redesign the application to call it SOA-compliant.

Looking forward to more ideas on this :)

]]> By: Alex Kazovic http://www.udidahan.com/2004/04/14/the-rocky-road-to-soa/comment-page-1/#comment-85 Alex Kazovic Thu, 15 Apr 2004 12:39:05 +0000 http://wp_630.weblogs.us/archives/58#comment-85 I've come to SOA from a different perspective. One thing that I have come to believe is that as a project increases in size, the complexity increases. But this increase in complexity is not linear; it seems to increase in an exponential manner (it might be some sort of combination explosion i.e. the more “parts” there are, the more ways they can combine with each other). This exponential increase in complexity also applies to object models i.e. as an object model gets larger the complexity increases exponentially not linearly. I now look to keep object models down to a certain size; even if it means having more than one object model per tier. I’ve come to SOA from a different perspective. One thing that I have come to believe is that as a project increases in size, the complexity increases. But this increase in complexity is not linear; it seems to increase in an exponential manner (it might be some sort of combination explosion i.e. the more “parts” there are, the more ways they can combine with each other).

This exponential increase in complexity also applies to object models i.e. as an object model gets larger the complexity increases exponentially not linearly. I now look to keep object models down to a certain size; even if it means having more than one object model per tier.

]]>