Hi Michael et. al., As the Everware-CBDI representative working on the SoaML specification with IBM and others I can say that it was not always smooth. All the members brought some notion of the service concepts to the table including IBM. Of those organizations involved, IBM and Eveware-CBDI represented the largest "installed base" - IBM with their profile in RSM/RSA and Everware-CBDI with our SAE methodology, metamodel and UML profile. In addition, we looked closely at the OASIS Reference Model and tried to be consistent where possible.
With their large installed base, IBM had a rather firm position coming in as to what the metamodel and profile should look like and it was somewhat different than most of the other members of the submission team. They tended to take a developer/assembler, bottom up approach wherein software modules were hooked together based on the need to consume and/or provide services. It centered around the "things" that provide the services. The assumption being that the services already exist and you just need to find them and use them. Others of us tended to take more of a top-down approach wherein the service provider is yet unknown and we need to be able to analyze the inter-dependencies between logical services to understand what the right "packaging" or bundling of services might be. This tends to be required earlier in the Service Capability Maturity roadmap where most organizations are. To the credit of all members, we were ultimately able to find a way to support both top-down and bottom up approaches. We agreed that a service is much more than an interface and SOA (rumors of its death are greatly exaggerated) requires a much richer set of modeling elements to capture these other aspects. The SoaML team tried to strike a balance between providing a rich set of modeling elements, simplicity, and standard usage of UML as the basis for the profile - all requirements of the submission. The result is a metamodel and UML profile that can be used to model services at any level including those offered by businesses, IT systems, or infrastructure platforms. The SoaML specification is currently in the finalization process and any comments would be greatly appreciated. Regards, - John Butler --- In [email protected], Michael Poulin <m3pou...@...> wrote: > > Hi Lawrence, > > We have exchanged a few e-mails with David recently, so, I am aware of this very good post. > > BTW, I have a short comment on "For end users the question is how these various standards should be used. The conceptual models (OASIS-RM and the Open Group Ontology) are useful in providing conceptual consistency. But they do not provide the necessary detail that informs repository and deliverable design. In contrast the SAE meta model and UML Profile are being widely used to define asset schemas and deliverables, and the SoaML will of course be used by tool vendors to develop same." > > To my knowledge about OASIS, it is a principal position of both Technical Committees - RM and RA - to concentrate on WHAT, WHO,WHY aspects of SOA leaving HOW to others (for open competition). For example, IBM (influencing OMG) is very deep in HOW trying to promote its SOMA and Professional consultancy practice because they care about their tools/products. OASIS wants to be vendor agnostic. Nonetheless, OMG/SOMA/SoaML/tools should reflect WHAT, first of all, instead of creating models convenient for the tools. For example, SOMA and related modelling products from IBM for services and processes do not recognise SOA Service deeper than its interface and explicitly say that Service=Interface. This is wrong for SOA but convenient for the tools. > > I am not against good and simple tools but even Thomas Erl has admitted that service contract is not an interface only (i.e. mentioned tools deviate developers from clear understanding what a service is about) > > Also, I would like to point CBDI on one missed fact (in David's BLOG): OASIS intensively works on SOA Reference Architecture standard (in continuation of its Reference Model) and we expect the second Public Review Draft (the first one was available in June/July, 2008) soon. I hope to see your analysis of this Draft in your postings. > > Regards, > - Michael Poulin > > > > > ________________________________ > From: "l.wil...@..." <l.wil...@...> > To: [email protected] > Sent: Wednesday, January 21, 2009 1:41:40 PM > Subject: [service-orientated-architecture] Re: CBDI-SAEª SOA KNOWLEDGEBASE > > > > --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <m3poulin@> wrote: > > > I have found a lot of right words in right order but, surprisingly, no references to the SOA standards. Even if they say that SOA is much more than Web Services, I still do not know if this is a home- > > made SOA interpretation and related 'practical ' advices or it is the standard-based view. For example, why I need the CBDI's SOA Reference Model and Reference Architecture when I have OASIS > > standards for both of them? > > You might be interested in a post my colleague David Sprott here at CBDI made in his blog this week SOA Concept Standards > In the first half of this decade there was big push on Web services standards, with a (fairly) good convergence around a core set of standards. However the state of SOA concept standards that is standards underlying the architecture and engineering concepts - is a very different matter. > There are at least four international bodies currently developing standards around SOA - OASIS, OMG, Open Group and W3C, plus some important national bodies (US Federal Government, DoD, MOD). > The key standards bodies have several relevant artefacts. > - The OASIS SOA Reference Model TC has approved an SOA reference model OASIS-RM. > - The Open Group is working on an SOA reference architecture and has published an SOA Ontology. > - The OMG has recently released a draft specification of SoaML, the SOA Modeling Language, a UML profile previously UPMS. > The DoD and MoD are looking to use UPDM (UML Profile for DoDAF and MoDAF) from OMG. This profile is relatively close to SoaML and shows that these three groups seem to be coming closer together. This is likely due to the fact that DoD/MoD needs to use standard tools to do their modelling and the OMG is the organization that develops the specs used by most of those tools. The Open Group have based their Ontology on the OASIS-RM. However beyond this it is hard to see much convergence between the bodies. > In addition to lack of convergence between the bodies, it is also obvious that there is widespread inconsistency between parallel groups within standards organizations. As ever multiple, incomplete standards is nothing new. As "users or advisors" we have to assess what value each candidate standard brings and whether it is fit for purpose. > In the context of SOA there are several considerations: > What value do (specific) standards bring? Common vocabulary, high quality, reusable concepts, standard artefacts that can be both reused and shared? > And conversely what is the cost of inconsistency? > And crucially is the standard providing the right level of detail in a manner that supports practical use? > CBDI has pioneered many aspects of SOA standards. The CBDI Frameworks, meta model and UML profile pre-date the work of the standards bodies working on defining SOA structural standards. The CBDI frameworks have been made widely available; the CBDI SAE Meta model and related UML Profile have thousands of downloads and are widely used. Some industry groups have based their work on it. (Notably HL7). Many CBDI Forum members have used the SAE meta model as a basis for their asset management schemas, and the UML Profile as a basis for SOA architecture and design deliverable formats. > For CBDI and our Forum member users the question is how do the CBDI models compare and should they move to adopt one or more emerging standards and when? > CBDI SAE is an SOA methodology which provides considerable depth in practice guidance based on the rigorous underlying meta model. The OASIS-RM is a conceptual model of SOA and there is significant alignment between the CBDI work and OASIS-RM. However CBDI has focused it's efforts differently to OASIS The CBDI Meta Model is not purely a conceptual model, rather it is a working level, detailed meta type model that provides the basis for life cycle meta data that will be managed in registries and repositories. In contrast the OASIS-RM and Open Group concept models provide either no or limited cardinality or optionality rules, and are therefore open to interpretation, leading to inconsistencies in implementation. > CBDI is monitoring the work of OASIS-RM and may a) contribute to certain areas and b) consider alignment of the CBDI meta model as appropriate. > CBDI is also monitoring the work of the Open Group and plans to assess potential for alignment when the current SOA work is published. The Open Group SOA Ontology is a derivation of the OASIS-RM, and is a similar concept level model. We have discussed with the Open Group the possibility of donating the CBDI Meta Model as a way to deliver further detail. > CBDI has supported and contributed to the UPMS work, now renamed SoaML. There is significant alignment between key areas of the CBDI meta model and UPMS. The SoaML is somewhat more comparable to the CBDI models insofar as it is fully detailed. Where it diverges is that the SoaML is a UML profile and therefore its purpose is to support tool design; the CBDI models provide richer metadata whereas SoaML simply provides a means to represent the basic elements in a model. > You may well ask the question, so what's the difference between the SAE UML Profile and the SoaML? First the SAE Profile is broader in coverage that the SoaML it spans the entire service life cycle; we would be the first to say, the leaf node detail is not necessarily fully consistent and detailed, but that's the intent, whereas SoaML is focused purely on the service modeling domain. Second the SAE Profile supports the SAE methodology. > For end users the question is how these various standards should be used. The conceptual models (OASIS-RM and the Open Group Ontology) are useful in providing conceptual consistency. But they do not provide the necessary detail that informs repository and deliverable design. In contrast the SAE meta model and UML Profile are being widely used to define asset schemas and deliverables, and the SoaML will of course be used by tool vendors to develop same. > We are currently engaged in a detailed assessment of the SoaML and SAE profile and anticipate we will report in February. Following this we will canvas our Forum members' opinion on the level of convergence that is desirable. > To summarize, it seems to us that higher level conceptual standards have their place while the industry is learning. But as the industry and its customers demand production strength support, the requirement is for standards that guide deliverable creation and tooling. This has been the objective guiding CBDI work for some years, and while we see some merit in alignment with the higher level conceptual models, we believe alignment with SoaML is a priority because of its comparable rigour. The levels of inconsistency observed in the purely conceptual models will be extremely difficult to resolve at that level. For that reason we believe the standards will evolve from the CBDI SAE and OMG SoaML models because they are at the level users will require. > The CBDI models are organized into packages because the breadth of SOA clearly indicates multiple domains. It seems likely that standards will evolve at different rates in each of the domains. Alignment around SoaML is clearly going to happen in the Modeling domain. We envisage a plug and play approach where different standards bodies will develop strengths in different domains. In this process CBDI will continue to influence events and to provide a detailed Business Type Model "view" that helps real users make sense of it all. > Finally, we can all see the Web services standards were hugely successful because IBM and Microsoft drove the process. Similarly today we note IBM is a big supporter of the OMG, and specifically SoaML, and significantly Microsoft joined the OMG last September. > > Lawrence Wilkes, Everware-CBDI > ------------ --------- --------- --------- -------- > URL: http://www.cbdiforu m.com > http://www.everware -cbdi.com >
