RM-ODP defines five viewpoints. A viewpoint (on a system) is an abstraction that yields a specification of the whole system related to a particular set of concerns. The five viewpoints defined by RM-ODP have been chosen to be both simple and complete, covering all the domains of architectural design. They are, the enterprise, information, computational, engineering and technology viewpoints.
RM-ODP also provides a framework for assessing system conformance. The basic characteristics of heterogeneity and evolution imply that different parts of a distributed system can be purchased separately, from different vendors. It is therefore very important that the behaviours of the different parts of a system are clearly defined, and that it is possible to assign responsibility for any failure to meet the system's specifications. RM-ODP goes further and defines where these conformance points would sit.
What is interesting here is to match up what we are trying to do at the Pi4 Technologies Foundation with WS-CDL-based tooling. Of the RM-ODP's five viewpoints the view that is of interest here is the "computational viewpoint". It is defined as:
"the computational viewpoint, which is concerned with the functional decomposition of the system into a set of objects that interact at interfaces - enabling system distribution; "
The key phrase is "a set of objects that interact at interfaces" because this is exactly what WS-CDL can express and it does so in both an architecturally and service neutral way from a global perspective. Thus WS-CDL would appear to be a really good fit as a language to support the "computational viewpoint".
The other area of interest lies in the notion of conformance and essentially service substitutability, the ability to "purchase separately" different parts of the system whilst maintaining overall behavioral correctness - the system as a whole continues to do what it is supposed to do from a computational viewpoint. Again this is very much where the pi4soa tool suite and the work in the Pi4 Technologies Foundation is heading.
The ability to test a computational viewpoint against higher order viewpoints is the basis of ensuring that the computation viewpoint is correct. In the pi4soa tool suite this is done using example messages from the information viewpoint (as information types) and scenarios (sequence diagrams) that represent flows. The model is checked for conformance. Conformance in this case means the model meets the requirements used to check it. Once this is done we can ensure that the expected the behavior of the services that participate are correct by monitoring them if they already exist and by generating their state behaviors if they do not exist.
In short the pi4soa tool suite provides a sound basis for a computational viewpoint language, and provides much in the way of automated conformance checking both at design time and at runtime. Thus the tool suite supports RM-ODP.
Comments please .....
The other area of interest lies in the notion of conformance and essentially service substitutability, the ability to "purchase separately" different parts of the system whilst maintaining overall behavioral correctness - the system as a whole continues to do what it is supposed to do from a computational viewpoint. Again this is very much where the pi4soa tool suite and the work in the Pi4 Technologies Foundation is heading.
The ability to test a computational viewpoint against higher order viewpoints is the basis of ensuring that the computation viewpoint is correct. In the pi4soa tool suite this is done using example messages from the information viewpoint (as information types) and scenarios (sequence diagrams) that represent flows. The model is checked for conformance. Conformance in this case means the model meets the requirements used to check it. Once this is done we can ensure that the expected the behavior of the services that participate are correct by monitoring them if they already exist and by generating their state behaviors if they do not exist.
In short the pi4soa tool suite provides a sound basis for a computational viewpoint language, and provides much in the way of automated conformance checking both at design time and at runtime. Thus the tool suite supports RM-ODP.
Comments please .....
2 comments:
Steve, Great post.
I would only add two notions. The first is that RM-ODP is an ISO Standard (RM – ODP, ISO/IEC IS 10746 | ITU-T X.900 ), which is to say to those not familiar that it hasn't simply appeared out of thin air. ODP not only allows system specification from each viewpoint, but also defines an ontology for each viewpoint. To me it is a clarifying idea that allows different parties involved in system description to talk between and among the viewpoints, and still be specific.
Second, we were pleased with how CDL captured the intersections with most of the other viewpoints. So even though the actual choreography captures the computational viewpoint as you note, the package level elements also capture enterprise elements (roles, relationships, higher level behaviors), information elements, and even Engineering items (channels, tokens).
Thank you very much, for the information Fırsat
Post a Comment