There has been some recent blogging about general confusion on whether or not SCA constitutes a new programming model or not; for instance Dave Chappell blogs here, Mike Rowley of BEA here, and Sanjay Patil of SAP here.
Of course SCA defines a new programming model, however, it also specifically defines an invocation model, a component model, and an SOA assembly model which embraces other, non-SCA programming models. Blur in the fact that the term "programming model" has specific language connotations (at least in my mind), while SCA and its cousin SDO were designed to be specifically language neutral.
What we need for building SOA applications is a contract to describe dependencies, policies and implementation with as little knowledge of or need to impact existing business logic. It needs to lift us out of the computer science goo and into building business logic that is meaningful to the business.
The fact that one can or cannot use SCA with or without another container, or as a client with any at all is less important in my mind as the importance of its design points of separation of concerns and insulating the business logic from specific protocol and data bindings which lead to fragile, inflexible applications.
Steve Kinder
Farewell to IBM
10 years ago
3 comments:
Please see my first ever blog post for my thoughts on this.
Simon, I enjoyed your well thought out reply; and agree we shouldn't be distracted by the "programming in the small" aspect of SCA. My blog entry was not the most coherent text I've ever written and I was also trying to convey that there is a larger purpose for the SCA story. At any rate, I thought your thoughts on compliance were very interesting, and I'm wondering if perhaps there shouldn't at least be levels of compliance. One of the very hard things about SOA is understanding if Party A can speak to Party B with all of the appropriate semantics. Standards compliance help customers understand whether two pieces of middleware or two applications will talk to each other; e.g. WS-I profiles. Perhaps most importantly, I have now added one more language I can order a beer! Thank you very much Simon for this absolutely mission critical information!
Steve, Thanks for your kind words. Levels of compliance are certainly needed. The question is whether there should be a fixed set of these, mandated by some standards body ("top down"), or whether the levels should be determined by an evolutionary approach based on what people choose to do and what actually works in practice ("bottom up"). The development of natural language follows the latter path, with dictionaries describing the language that people have chosen to speak rather than the other way round. I think SOA assembly (unlike on-the-wire protocol interoperability) can follow this path as well. Having the SCA assembly model as a well-specified overall framework within which this evolutionary process can take place will be very helpful in avoiding the confusion that would arise if different services used different models that need to be bridged in order to work together.
Post a Comment