Comments on: Why I Love SOA: Design Business-Related Services http://johannesbrodwall.com/2006/07/26/why-i-love-soa-design-business-related-services/ 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: Investment Opportunities http://johannesbrodwall.com/2006/07/26/why-i-love-soa-design-business-related-services/comment-page-1/#comment-127606 Investment Opportunities Mon, 29 Jun 2009 11:53:51 +0000 http://www.brodwall.com/johannes/blog/?p=109#comment-127606 The evolution of SOA Introduce the concepts of services and SOA Design principles of SOA ... The benefits of employing SOA Review of common business goals ... Related articles. Web Application Vulnerability Assessment Essentials ... Cancel. We'd love to hear what you think! Submit ideas or give us feedback ... The evolution of SOA Introduce the concepts of services and SOA Design principles of SOA … The benefits of employing SOA Review of common business goals … Related articles. Web Application Vulnerability Assessment Essentials … Cancel. We'd love to hear what you think! Submit ideas or give us feedback …

]]> By: Investment Opportunities http://johannesbrodwall.com/2006/07/26/why-i-love-soa-design-business-related-services/comment-page-1/#comment-126645 Investment Opportunities Mon, 29 Jun 2009 04:53:51 +0000 http://www.brodwall.com/johannes/blog/?p=109#comment-126645 The evolution of SOA Introduce the concepts of services and SOA Design principles of SOA ... The benefits of employing SOA Review of common business goals ... Related articles. Web Application Vulnerability Assessment Essentials ... Cancel. We'd love to hear what you think! Submit ideas or give us feedback ... The evolution of SOA Introduce the concepts of services and SOA Design principles of SOA … The benefits of employing SOA Review of common business goals … Related articles. Web Application Vulnerability Assessment Essentials … Cancel. We'd love to hear what you think! Submit ideas or give us feedback …

]]> By: jhannes http://johannesbrodwall.com/2006/07/26/why-i-love-soa-design-business-related-services/comment-page-1/#comment-98694 jhannes Tue, 18 Nov 2008 04:50:48 +0000 http://www.brodwall.com/johannes/blog/?p=109#comment-98694 Thanks for your comment. I've encountered people who talk about non-distributed SOA. I think that is an idea that is totally boring, as it says nothing that hasn't been said for twenty years. The idea escapes my concerns, but at the cost of being vacuous. Thanks for your comment. I've encountered people who talk about non-distributed SOA. I think that is an idea that is totally boring, as it says nothing that hasn't been said for twenty years. The idea escapes my concerns, but at the cost of being vacuous.

]]> By: Chat http://johannesbrodwall.com/2006/07/26/why-i-love-soa-design-business-related-services/comment-page-1/#comment-98652 Chat Mon, 17 Nov 2008 22:37:35 +0000 http://www.brodwall.com/johannes/blog/?p=109#comment-98652 In the text you, like most I think, define services to be distributed. I do not understand why everybody i In the text you, like most I think, define services to be distributed. I do not understand why everybody i

]]> By: Johannes Brodwall http://johannesbrodwall.com/2006/07/26/why-i-love-soa-design-business-related-services/comment-page-1/#comment-132 Johannes Brodwall Thu, 14 Sep 2006 17:24:49 +0000 http://www.brodwall.com/johannes/blog/?p=109#comment-132 Hi, Daniel Thank you for you comment. I recommend that you post it again on TheServerSide reprinting of this blog article at http://www.theserverside.com/discussions/thread.tss?thread_id=41836 If you do, I will respond to your reservations. ~Johannes Hi, Daniel

Thank you for you comment. I recommend that you post it again on TheServerSide reprinting of this blog article at http://www.theserverside.com/discussions/thread.tss?thread_id=41836

If you do, I will respond to your reservations.

~Johannes

]]> By: Johannes Brodwall http://johannesbrodwall.com/2006/07/26/why-i-love-soa-design-business-related-services/comment-page-1/#comment-84597 Johannes Brodwall Thu, 14 Sep 2006 15:24:49 +0000 http://www.brodwall.com/johannes/blog/?p=109#comment-84597 Hi, Daniel<br><br>Thank you for you comment. I recommend that you post it again on TheServerSide reprinting of this blog article at <a href="http://www.theserverside.com/discussions/thread.tss?thread_id=41836">http://www.theserverside.com/discussions/thread...</a><br><br>If you do, I will respond to your reservations.<br><br><br>~Johannes Hi, Daniel

Thank you for you comment. I recommend that you post it again on TheServerSide reprinting of this blog article at http://www.theserverside.com/discussions/thread...

If you do, I will respond to your reservations.

~Johannes

]]> By: Daniel http://johannesbrodwall.com/2006/07/26/why-i-love-soa-design-business-related-services/comment-page-1/#comment-131 Daniel Thu, 14 Sep 2006 09:31:39 +0000 http://www.brodwall.com/johannes/blog/?p=109#comment-131 Hi In the text you, like most I think, define services to be distributed. I do not understand why everybody introduce that limitation. You can implement a one JVM system in that uses business oriented "services" (interface programing) that locates the service implementors at run or call time. I do not see a fundamental difference in that architecture and the distributed SOA. Equally I do not think you should consider a architecture as SOA if you have hardcoded the impleremtor of a webservice even if it is business oriented and loosely coupled otherwise... Perhaps it is sufficent to have a broker between the service requestor and implementor? That is when you truly have decoupled the system, if the implementor and requestor runns in the same JVM or not does not seem that relevant. (in theory :-) ) //Daniel Hi
In the text you, like most I think, define services to be distributed. I do not understand why everybody introduce that limitation. You can implement a one JVM system in that uses business oriented “services” (interface programing) that locates the service implementors at run or call time. I do not see a fundamental difference in that architecture and the distributed SOA.
Equally I do not think you should consider a architecture as SOA if you have hardcoded the impleremtor of a webservice even if it is business oriented and loosely coupled otherwise…

Perhaps it is sufficent to have a broker between the service requestor and implementor?
That is when you truly have decoupled the system, if the implementor and requestor runns in the same JVM or not does not seem that relevant. (in theory :-) )

//Daniel

]]> By: Daniel http://johannesbrodwall.com/2006/07/26/why-i-love-soa-design-business-related-services/comment-page-1/#comment-84596 Daniel Thu, 14 Sep 2006 07:31:39 +0000 http://www.brodwall.com/johannes/blog/?p=109#comment-84596 Hi<br>In the text you, like most I think, define services to be distributed. I do not understand why everybody introduce that limitation. You can implement a one JVM system in that uses business oriented "services" (interface programing) that locates the service implementors at run or call time. I do not see a fundamental difference in that architecture and the distributed SOA. <br>Equally I do not think you should consider a architecture as SOA if you have hardcoded the impleremtor of a webservice even if it is business oriented and loosely coupled otherwise...<br><br>Perhaps it is sufficent to have a broker between the service requestor and implementor? <br>That is when you truly have decoupled the system, if the implementor and requestor runns in the same JVM or not does not seem that relevant. (in theory :-) )<br><br>//Daniel Hi
In the text you, like most I think, define services to be distributed. I do not understand why everybody introduce that limitation. You can implement a one JVM system in that uses business oriented “services” (interface programing) that locates the service implementors at run or call time. I do not see a fundamental difference in that architecture and the distributed SOA.
Equally I do not think you should consider a architecture as SOA if you have hardcoded the impleremtor of a webservice even if it is business oriented and loosely coupled otherwise…

Perhaps it is sufficent to have a broker between the service requestor and implementor?
That is when you truly have decoupled the system, if the implementor and requestor runns in the same JVM or not does not seem that relevant. (in theory :-) )

//Daniel

]]>