Welcome Welcome to our blog about all kind of topics that are related to software development. We blog about:
SOA, BPM, EDA, ECM and all the other buzz words. Beware some post might not be so common as you think. We are not scared to go against main stream thoughts.
Technologies like java, maven, springframework, OSGi and front end technologies and frameworks like jQuery, DWR, Flex.
Finally to make this happen we need tools and of course a Mac (well some of us do). So we blog about that as well.
Linked in We now have a linked in group, join the group if you are a regular reader and want to see who else reads this blog.
 |
By Ben, on July 26th, 2008
When designing components for a SOA landscape (or any multiprocess system), the primary concern is with the communication behavior of the component: how messages are passed to and from the component and in what order, what those messages are and what constitutes a valid message and what doesn’t. When the time comes to implement the component, related concerns come into play: how are messages projected from the communication language into the domain model and into the implementation language, how are communication patterns met and ensured, et cetera. In addition the project technical architect has to consider how to implement the component’s domain without hardlinking it to any other components whose domains are known or to the communication medium du jour (unless the component’s purpose is linked to that medium).
Now here’s the strange thing: with all the concerns that go into design of components at all levels (from the enterprise architect down to the developers of the different components), one of the most overlooked things in SOA component building is the handling of cross-component error handling.
Continue reading SOA component design: thinking about error handling
By Ben, on April 15th, 2008
Over the past few days my thoughts have been drawn to what I think is a common problem (in addition to the ones identified by Freddie van Rijswijk in his recent blog) in establishing and participating in a SOA architecture: Won’t Let Go Syndrome (WLGS).
WLGS is a problem akin to the Not Invented Here Syndrome (NIHS), which is itself a specific form of Reinventing the wheel. However, where NIHS is an a-posteriori problem (an unwillingness to use the inventions and work of others), WLGS is an a-priori problem: an unwillingness to let anybody else solve your problems for you.
When working within a SOA, the idea is that you create one or more components, each of which is good at solving a certain problem really well and doing nothing else but that (don’t confuse that with the idea that a single SOA component must offer only one operation). Other problems must be solved by other, specialised components. And for larger problems it is often a good idea to have subproblems solved by other components as well. Back in the good old days of “simple” OOP, this was called delegating. However, as I continue to work in my work environment and am involved in more and more projects that create different components within what will become the companies SOA, I come across a weird phenomenon more and more often. For some reason people working on any given component are unwilling to entrust the care for their subproblems to any other component.
Continue reading Letting go: yet another traditional problem in the SOA world
By freddie, on April 12th, 2008
How is SOA and BPM going to improving the ability to serve and exceed quality while cut in the 30% cost of IT MOOSE? I´m convinced that SOA and BPM is NOT the answer. The discussion on ROI of SOA caused by my Blog-item SOS voor SOA andmultiple discussions with Max J. Pucher and reading his blogs, but also the posting of Ben Tels and others blogs and several papers have strengthen me in my thoughts that SOA althoug a great Architectural concept has lost its meaning. But I´m open for other insights and discussions, so feel free to react after reading this post.
MOOSE?
The term MOOSE comes from Forrester. Executives often look at IT spend as a black box and compare it as a percent to overall revenue. Maintenance and operating the IT organization, systems, and equipment (MOOSE) takes approximately 70% of IT budgets (Forrester: the October 18, 2005, “Defining The MOOSE In The IT Room” report.). The remaining 30% comprises investments to support business growth, to cut business cost, and to cut the cost of IT MOOSE.
Macro-economics conditions shaping the CIO´s job currenlty. The reality is that any business at any time may need to shift its executive focus toward running lean.
The question is how will SOA and BPM help the CIO Invest more in New and Improved Capabilities to support business growth and therefore to Reduce the Cost of Business and above all Cost of IT MOOSE. Seriously, I doubt that we can hold our claim that SOA and BPM are bringing the CIO those benefits. Besides the argument of Cost saving, we also hear the arguments for Business Agility and Compliancy. I will not go into Compliancy and connected to it Security, it´s to broad for this blog but Agility is also something to think somewhat more on.
Continue reading Will SOA and BPM bring the MOOSE Savings and Business Agility?
By Ben, on April 2nd, 2008
A couple of things happened to me over the past few days as I was taking on a new role within a new project that caused me to ponder a bit about the role of domains and domain driven development (DDD) within the drive towards service oriented architectures (SOA). The result of these ponderings was, as it often is in my case, that the more we think things change, the more they stay the same. And the more we think we learn, the more we find we already knew what we have learned.
Continue reading SOA and the domain: how new technology should not blind you to old wisdom
By Allard, on March 21st, 2008
Many IT projects at large companies aim to make the company “SOA-proof”. What really concerns me is that time after time software architects tend to treat “XML Web Services” as a synonym for “Service”. In this article, I want to show that SOA may also exist within a single application.
Continue reading Service orientation within applications
By Allard, on February 13th, 2008
jQuery(document).ready(function($) { window.setTimeout(‘loadFBShareMe_50()’,5000); }); function loadFBShareMe_50(){ jQuery(document).ready(function($) { $(‘.dd-fbshareme-50′).remove();$(‘.DD_FBSHAREME_AJAX_50′).attr(‘width’,’53′);$(‘.DD_FBSHAREME_AJAX_50′).attr(‘height’,’69′);$(‘.DD_FBSHAREME_AJAX_50′).attr(‘src’,'http://widgets.fbshare.me/files/fbshare.php?url=http://www.gridshore.nl/2008/02/13/why-are-web-services-so-different-from-an-html-user-interface/&size=large’); }); }
We all know how a typical web application is usually built up. The image at the side rougly displays the different layers that are to be found in an application. Typically, the user interface layer receives HTTP requests, calls one or more methods in [...]
By freddie, on February 13th, 2008
jQuery(document).ready(function($) { window.setTimeout(‘loadFBShareMe_43()’,5000); }); function loadFBShareMe_43(){ jQuery(document).ready(function($) { $(‘.dd-fbshareme-43′).remove();$(‘.DD_FBSHAREME_AJAX_43′).attr(‘width’,’53′);$(‘.DD_FBSHAREME_AJAX_43′).attr(‘height’,’69′);$(‘.DD_FBSHAREME_AJAX_43′).attr(‘src’,'http://widgets.fbshare.me/files/fbshare.php?url=http://www.gridshore.nl/2008/02/13/should-we-send-out-a-sos-for-soa/&size=large’); }); }
This Post is all about laughing and not to worry to much about SOA, BPM, ROI, CEP. I came across “Greg the Architect” and his small movies underpin a lot of what i have written about lately.
If you do not see the youtube [...]
|
|
Popular