Rajat, Vikrant (the latter's an outdated link) and I have been having these discussions for a while now. Our thinking is summarised in these two papers:
The first is an "astro-geological" meta-model that explains how the Domain Model relates to various internal and external Representations. It tries to unify the concepts of Domain-Driven Design (DDD) and Service-Oriented Architecture (SOA). A Domain Model is a system's own view of its Universe of Discourse. Representations are how the system allows external parties to view itself. SOA deals with representations that are decoupled from domain objects, and these representations could be noun-based (REST) or verb-based (SOAP/WS-*).
The second is a model for Representation Composition, which blends the concepts of Process Orchestration and Content Aggregation.
The analogy of the astro-geological meta-model is that the Domain Model is like the surface of the Earth (or any other planet). When these celestial orbs communicate with each other (the "astro" part of the meta-model), they exchange representations of their Domain Models rather than expose their Domain Models directly. This is classic architectural practice to avoid tight coupling between systems. The Domain Model includes State and Behaviour, so one could think of representations of State as well as Behaviour. We believe these are commonly known as REST and SOAP, though purists from both camps may take umbrage at the comparison ;-).
The Domain Model is implemented atop infrastructure (the "geo" part of the meta-model). Sometimes, it's in the form of data held in relational databases. Sometimes, it's functions coded in legacy systems. Again, these are representations of the Domain Model, some of State and some of Behaviour. O-R Mapping tools are commonly used to create representations of the State of a Domain Model built with an OO paradigm, and these representations are relational. Similarly, Behaviour in the Domain Model may be represented as procedures on a mainframe, with the appropriate loosely-coupled translation happening between the two.
The Domain Model itself does not have to be purely OO-based. Many different paradigms may be used to model a domain, - OO, AOP (aspects), Rules, Process definitions, etc. The key messages are that representations are always required whenever a Domain Model is to interface to any other entity, internal or external. These representations should be loosely coupled to the Domain Model.
Coming to Representation Composition, we believe this is where SOA really hits its stride. An enterprise consists of various Domains, each with its own model and its own external representations (SOAP or REST-based). The challenge is to weave greater meaning from these individual representations and thereby add value to the enterprise.
Process orchestration concentrates on the verb paradigm. While this is powerful and enables the composition of "sentences" that include compound verbs and conditional clauses, the relative neglect of primary nouns in this model is cause for concern. This is perhaps why content aggregation (and content management in general) occupy a separate niche. Mashups (and the older Portals) are stabs at content aggregation, but both suffer from limitations as described in the document. We don't see a rationale for this dichotomy between the composition of representations of State and the composition of representations of Behaviour. Both need to be managed using a common idiom, and true power and value-add will come from that composite model.
As mentioned before in this blog, the WSO2 Mashup Server comes close to delivering on this vision, so we don't think our model is vapourware. We're surprised that the WSO2 people are themselves rather understated about the capabilities of Mashup Server ("lightweight personal mashup server"). Hypothetically, if a JavaScript library is developed with classes corresponding to various components in a BPEL engine, and if an XSL transform is done from XPDL (the XML representation of a BPMN process diagram) to a set of JavaScript configuration statements, then we can run processes on the WSO2 Mashup Server just as we can do content aggregation today. One unified platform for "Representation Composition"! Consume SOAP or REST, compose in a noun-oriented or verb-oriented way, and expose in turn as SOAP or REST.
All of this is non-visual, and we already have a model for how the Presentation Tier should interface with a SOAP- or REST-based Service Tier. It's called SOFEA (Service-Oriented Front-End Architecture), which is described in this paper and discussed on this blog.
Comments as usual are welcome.
The first is an "astro-geological" meta-model that explains how the Domain Model relates to various internal and external Representations. It tries to unify the concepts of Domain-Driven Design (DDD) and Service-Oriented Architecture (SOA). A Domain Model is a system's own view of its Universe of Discourse. Representations are how the system allows external parties to view itself. SOA deals with representations that are decoupled from domain objects, and these representations could be noun-based (REST) or verb-based (SOAP/WS-*).
The second is a model for Representation Composition, which blends the concepts of Process Orchestration and Content Aggregation.
The analogy of the astro-geological meta-model is that the Domain Model is like the surface of the Earth (or any other planet). When these celestial orbs communicate with each other (the "astro" part of the meta-model), they exchange representations of their Domain Models rather than expose their Domain Models directly. This is classic architectural practice to avoid tight coupling between systems. The Domain Model includes State and Behaviour, so one could think of representations of State as well as Behaviour. We believe these are commonly known as REST and SOAP, though purists from both camps may take umbrage at the comparison ;-).
The Domain Model is implemented atop infrastructure (the "geo" part of the meta-model). Sometimes, it's in the form of data held in relational databases. Sometimes, it's functions coded in legacy systems. Again, these are representations of the Domain Model, some of State and some of Behaviour. O-R Mapping tools are commonly used to create representations of the State of a Domain Model built with an OO paradigm, and these representations are relational. Similarly, Behaviour in the Domain Model may be represented as procedures on a mainframe, with the appropriate loosely-coupled translation happening between the two.
The Domain Model itself does not have to be purely OO-based. Many different paradigms may be used to model a domain, - OO, AOP (aspects), Rules, Process definitions, etc. The key messages are that representations are always required whenever a Domain Model is to interface to any other entity, internal or external. These representations should be loosely coupled to the Domain Model.
Coming to Representation Composition, we believe this is where SOA really hits its stride. An enterprise consists of various Domains, each with its own model and its own external representations (SOAP or REST-based). The challenge is to weave greater meaning from these individual representations and thereby add value to the enterprise.
Process orchestration concentrates on the verb paradigm. While this is powerful and enables the composition of "sentences" that include compound verbs and conditional clauses, the relative neglect of primary nouns in this model is cause for concern. This is perhaps why content aggregation (and content management in general) occupy a separate niche. Mashups (and the older Portals) are stabs at content aggregation, but both suffer from limitations as described in the document. We don't see a rationale for this dichotomy between the composition of representations of State and the composition of representations of Behaviour. Both need to be managed using a common idiom, and true power and value-add will come from that composite model.
As mentioned before in this blog, the WSO2 Mashup Server comes close to delivering on this vision, so we don't think our model is vapourware. We're surprised that the WSO2 people are themselves rather understated about the capabilities of Mashup Server ("lightweight personal mashup server"). Hypothetically, if a JavaScript library is developed with classes corresponding to various components in a BPEL engine, and if an XSL transform is done from XPDL (the XML representation of a BPMN process diagram) to a set of JavaScript configuration statements, then we can run processes on the WSO2 Mashup Server just as we can do content aggregation today. One unified platform for "Representation Composition"! Consume SOAP or REST, compose in a noun-oriented or verb-oriented way, and expose in turn as SOAP or REST.
All of this is non-visual, and we already have a model for how the Presentation Tier should interface with a SOAP- or REST-based Service Tier. It's called SOFEA (Service-Oriented Front-End Architecture), which is described in this paper and discussed on this blog.
Comments as usual are welcome.
No comments:
Post a Comment