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: "[email protected]" <[email protected]>
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 
<m3pou...@...> 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     


      

Reply via email to