As far as i understood the whole concept of having ESOA/WOSA was to have the ability to define the endpoints seamlessly and flexibly to provide for varied connectivity and design options.
Unfortunately the world found out theoretically this was good, but when IT projects and corporations started to implement the ideal way, they had to many hang-ups of the people who shipped ‘Predefined’ endpoints.
These architectures make sense to have multiple endpoints for multiple usages and not single end points for multiple usage. Though the Business layer could/should mostly be single implementation but the end-point definitions should definitely never be the same.
The notion of a single end-point is completely wrong from my point of view,and i strongly feel against shipping predefined end-points in enterprise apps, unless you have peripheral software using them.
Why to ever spend the time and effort to deliver endpoints in a way that you “think”-> “Assume” should be defined? the whole problem why the ESOA theory was broken in real world is just that these is not easy way, unlike the .Net world to define usable endpoints.
I believe large organizations are still trying to misuse SOA by restricting the SOA development, and instead they should focus on reducing the TCD (Total Cost of Development) on the customer side.
I have seen to many products being innovated and failing in my short span of 4 years and i am still amazed that the hardliners still refuse to see the truth.
Bottom line: there should be no restrictions on End point definitions and no interlinking of Business to end point definition.
Until this is fixed by the bigger corporations, the customers to adapt to their needs will continue to opt in for cheaper, alternatives of custom developments, and soon the smaller enterprises will over through the tight sales grip of the bigger corporations.
The answer should be simple having 3 basic business layers:
1. Customer/Product Specific End point definition (REST/SOAP/XML)
2. Customer / Product specific, coding and customization options
3. Standard Business Logic/Intelligence.
I really do not see the need to design any visual modlling tools or any of this, writing code is anyways the eases and the unavoidable choice.
currently this is how i feel, i see this as a simple approach rather than a bigger more “imaginative approach” which companies are taking nowadays and just not helping on the final result of
1. Low TCD
2. Low TCO
3. High ROI
What should be provided for low TCD is good Caching frameworks/ good Business objects layer, and standard flexibility to achieve Reliable and state full messaging.
Where do Automated code generation and visual modeling fit in then?
It its in the business layer, where you will model the, business process because that is the only complex part of the entire application.