The roles of Service Component Architecture (SCA) and Service Data Objects (SDOs)
Some standards emerge from experiential pain, some from mere imagination, some from overly disciplined military minds and some from conventional wisdom. The above ones might have emerged from a mix of experiential pain and convention wisdom. Because ….
#1: ‘Services’ are not just Web Services; there is more to it. Especially, the concept of services is not enough to sufficiently represent and implement the functional building blocks living in the (existing) IT systems; even though, the concept of service may be enough to represent the IT requirement developed in a business mind.
#2: Not everybody talks the same language, so do IT systems; teaching all of them one language might take a time of a generation. So interpreters and cross language experts might need to depend on some meta-language terms and terminologies. Additionally, conversation has a time aspect associated with it; as an example, somebody might start with an opinion; he/she might change his/her stance midway, may be agreeing with somebody else’s opinion.
SCA provides more constructs to realistically represent the wide range of componentization needs in a Service Oriented World. Even though, it might only heat up never ending debate of the definition of a component, still it is much more an accurate definition of real world integration needs.
SDO provides an opportunity to define the business vocabulary at one more level of abstraction over XSDs. It accepts the conventional wisdom of multiple data representations in an IT environment. More than anything else, it brings the time axis of the data life cycle into the forefront so that asynchronous and disconnected communications are much more mainstream in SOA design ideas.
