Service Component Architecture (SCA) brings the formality of SOA contracts and end point separation into the implementation layer. For the many organizations undertaking modernization efforts the standardization of componentization and SOA enablement is an important issue. Whilst its usage may not be widespread, it is likely that growing demand for rationalization of the implementation layer will lead to increased adoption.
In a new report I look at SCA and consider how it relates and maps to SoaML and provide guidance for integration into the broader SAE/SoaML picture.
My conclusion is that in some respects the SCA and SoaML initiatives represent something of a missed opportunity. Though the respective groups will claim they address different requirements or audience, the reality is that it is hard to see why they couldn’t have been based on common concepts where they overlap. One could have extended the other instead of re-inventing. Then the inevitable additional effort and loss of integrity through the mapping and transformations from one to the other discussed in this report could have been avoided. More so given that some organizations participated in both initiatives.
On the positive side, SoaML to SCA transformation tools do exist, and the mapping provided between SCA, SoaML, and CBDI-SAE in the report is at least at a high level relatively straightforward.
SCA is an elegant solution, but somewhat limited by lifecycle scope, and dependence on the SCA runtime, in comparison SoaML. However, it does offer portability across SCA compliant platforms and that is of significant benefit.
SCA does seem to have reached a bit of an impasse. It is there, it works, but it isn’t clear whether adoption is growing, either by end-users or support by more vendors. If you are using or planning on using SCA, please let us know in our CBDI LinkedIn where we have created a discussion topic
Showing posts with label SoaML. Show all posts
Showing posts with label SoaML. Show all posts
Tuesday, 3 November 2009
Friday, 2 October 2009
CBDI-SAE Meta Model for SOA Version 3
The September 2009 CBDI Journal contains a “draft” publication of Version 3 of the SAE Meta Model. It incorporates some changes based on our continued work with customers and standards organizations and provides a mapping to SoaML so that end users can reap the benefits of both the breadth and depth of the SAE Meta Model as well as the capabilities that tool vendors will develop based on SoaML. Everware-CBDI plans to publish mappings to other ontologies shortly and other meta models as they mature.
It’s been some time since the last major revision of the CBD-Service Architecture and Engineering™ (SAE) Meta Model for SOA. Since then Everware-CBDI has published a UML Profile for SAE1 that has received quite broad acceptance and has been downloaded by thousands of members worldwide.
Everware-CBDI is committed to aligning with standards where appropriate and to that end we have contributed to, and worked extensively on SoaML, the service modeling language developed within the Object Management Group (OMG). What we’ve found in the course of our involvement in these efforts is that while there is some convergence in terminology, significant differences remain in the details between the various standards bodies working in this area, ranging from overall purpose of model/ontology of each organization to the exact definitions.
Our intent in the SAE Meta Model is to provide support for these various standards to our membership while not sacrificing the value built into our existing meta model. To that end, we will provide mappings of SAE terminology to these various meta models, profile and ontologies and guidance regarding their use within SAE.
Background
The SOA marketplace continues to mature and at Everware-CBDI we feel a measure of satisfaction in knowing that we’ve had a hand in that evolution through the guidance we’ve been giving over the years. The SAE Meta Model is one of many contributions and was a key input to the Object Management Group’s SoaML specification.
The SAE Meta Model was first released in October of 2006 and updated to Version 2 in 2007 as a result of feedback from our membership and the broader industry. Everware-CBDI created a UML profile based on V2 in 2008 that has since been downloaded thousands of times all over the world. Obviously industry was ready for more mature support for modeling services and the feedback we got was very positive.
In parallel with our efforts the Object Management Group (OMG) issued a Request For Proposal (RFP) for a UML Profile and Meta Model (UPMS) in September of 2006. A submission team formed that included Everware-CBDI, IBM, EDS, HP, Model Driven Solutions, SINTEF and several others. SoaML was finally adopted as a specification in November of 2008 and is currently in the finalization process.
Introduction to V3
Any model remains a work in progress if it is to continue to be relevant over time. The SAE Meta Model is no different. As mentioned above the meta model has been downloaded thousands of times and has provided a practical mechanism for using SAE with existing toolsets. Feedback from that broad membership usage along with our own involvement in standards organizations and client engagements has pointed out some areas that needed improvement and some holes that needed to be filled. Equally, we have continued to refine and extend our SAE guidance. Hence, we saw requirements to address the following:
We shall shortly be launching a review process and will make an updated specification and UML Profile available to those who would like to participate in the process.
If you are interested in doing so, drop us a note on our CBDI Contact Page
To view the full report
It’s been some time since the last major revision of the CBD-Service Architecture and Engineering™ (SAE) Meta Model for SOA. Since then Everware-CBDI has published a UML Profile for SAE1 that has received quite broad acceptance and has been downloaded by thousands of members worldwide.
Everware-CBDI is committed to aligning with standards where appropriate and to that end we have contributed to, and worked extensively on SoaML, the service modeling language developed within the Object Management Group (OMG). What we’ve found in the course of our involvement in these efforts is that while there is some convergence in terminology, significant differences remain in the details between the various standards bodies working in this area, ranging from overall purpose of model/ontology of each organization to the exact definitions.
Our intent in the SAE Meta Model is to provide support for these various standards to our membership while not sacrificing the value built into our existing meta model. To that end, we will provide mappings of SAE terminology to these various meta models, profile and ontologies and guidance regarding their use within SAE.
Background
The SOA marketplace continues to mature and at Everware-CBDI we feel a measure of satisfaction in knowing that we’ve had a hand in that evolution through the guidance we’ve been giving over the years. The SAE Meta Model is one of many contributions and was a key input to the Object Management Group’s SoaML specification.
The SAE Meta Model was first released in October of 2006 and updated to Version 2 in 2007 as a result of feedback from our membership and the broader industry. Everware-CBDI created a UML profile based on V2 in 2008 that has since been downloaded thousands of times all over the world. Obviously industry was ready for more mature support for modeling services and the feedback we got was very positive.
In parallel with our efforts the Object Management Group (OMG) issued a Request For Proposal (RFP) for a UML Profile and Meta Model (UPMS) in September of 2006. A submission team formed that included Everware-CBDI, IBM, EDS, HP, Model Driven Solutions, SINTEF and several others. SoaML was finally adopted as a specification in November of 2008 and is currently in the finalization process.
Introduction to V3
Any model remains a work in progress if it is to continue to be relevant over time. The SAE Meta Model is no different. As mentioned above the meta model has been downloaded thousands of times and has provided a practical mechanism for using SAE with existing toolsets. Feedback from that broad membership usage along with our own involvement in standards organizations and client engagements has pointed out some areas that needed improvement and some holes that needed to be filled. Equally, we have continued to refine and extend our SAE guidance. Hence, we saw requirements to address the following:
- Incorrect or cyclical dependencies between meta model packages,
- Only a very loose notion of who or what is providing a service,
- The need for a more consistent concept of Service for both business and software contexts,
- Separation of a concept (or “thing”) from the specification (i.e., the artifact) of the concept,
- The need for refinement of the relationships between Service, Automation Unit, and Deployable Artifact, and
- The need for inclusion of the concept of Internal Architecture.
We shall shortly be launching a review process and will make an updated specification and UML Profile available to those who would like to participate in the process.
If you are interested in doing so, drop us a note on our CBDI Contact Page
To view the full report
A Unified SOA?
My Colleague David Sprott blogs this week on the Failure of SOA Standards
There is no need for me to repeat his comments.
In his blog, David comments on Navigating the SOA Standards Landscape Around Architecture, a paper recently published by OASIS and The Open Group. It seems to us and many others that this is an attempt on the part of the authors to gloss over the fact they have managed to produce three alternative SOA standards when the world really only needs one. Saying that OASIS SOA RA is ‘similar’ to the Open Group SOA Ontology is a bit like saying Cricket is similar to Baseball. Because they both involve similar concepts of bat and ball presumably this means a cricket team could play a baseball team?
It is only with a more detailed level of mapping of more precise meta models that anything useful can be done in the real world. Even then, the reality is it is difficult to mix two frameworks and meta models.
One of the intriguing things for me is the involvement of common participants in all three SOA standards efforts at OASIS, The Open Group and also at OMG. IBM in particular stands out as a vendor who appears to have put significant effort into them all, and with minimal visible consistency resulting. Why? How does it help IBM customers to provide them with a choice of three alternative SOA standards? Surely that only works to slow adoption of SOA, not to encourage it.
This was one of the major successes of Web Service Protocols – that there is only one standard for each requirement in the protocol ‘stack’. Even though the various protocols are administered by different bodies, they have managed to avoid competing. Well eventually anyway after some initial vendor-based alternatives fell by the wayside. And since then take up has been widespread. Partly this was achieved because vendors such as IBM together with Microsoft participated in only one activity per protocol and not three. Hence others were forced to make decisions to go one way or the other rather than sit on the fence and be endlessly compromised by choice.
And this is what the same groups now need to do with SOA standards. Combine their energies, put aside their differences and produce a set of unified standards – even if different elements within it are administered by different bodies, as with Web Service Protocols, so they can each retain some ownership. We only need one SOA Reference Model, one SOA meta model, one set of principles and so on. But once you have the common foundation, just like the Web services efforts, there can be parallelism. From our work on the CBDI SAE meta model we know that there are multiple views which can be modelled concurrently such as business, specification, implementation, deployment, testing etc.
That said, perhaps more of the competitive approach taken with Web Services would be apt. That is, I would rather see IBM back one SOA Meta Model standard for example, and not three. I am sure the competitive nature of early Web Service protocol standards activity really helped to force the pace – a sort of SOA ‘Space Race’. Now, rather like the pace of the space race today, I get the impression it will now be decades before we land on the SOA moon. Of course, if OASIS, The Open Group and OMG cut the stack up as I suggest and avoid overlap so much the better.
But why is this important? At runtime, clearly the vision of SOA wasn’t going to work without consensus on the interoperability standards. But I believe it would be a mistake to assume a similar consensus isn’t required at earlier stages in the life cycle. Time after time we see that the lack of a common SOA framework is hindering SOA adoption in organizations. Sure different projects can all agree to use Web Services at runtime, but the lack of any common standards before they even get to that point means that much of the SOA vision remains elusive when viewed from an enterprise perspective. It is pretty hard to have full life cycle asset management and governance over SOA deliverables if the concepts change for each phase. In most organizations, users have little choice but to pick a single vendor's proprietary solution to such requirements that complies with no relevant SOA standards.
I am reminded of object orientation pre UML. What is needed now is a Unified SOA.
SoaML, in which we have participated might be one step in that direction, at least at the modelling language level. Even so, TOGAF 9 has its own meta model, but so does Archimate, and there is one implied by the OASIS SOA RA, and so on. Then there are the differences even between The Open Group’s TOGAF 9’s coverage of SOA, and their own SOA Source Book. Do you know for example when you see a concept mentioned in one document it has the same meaning as in another? Often no definition of the concept or reference is even given so it is difficult to be sure. Clearly there is still a long way to go.
And let’s not forget that there is a large government and defence sector who are extending their own frameworks such as FEA, DODAF, and MODAF with yet more unique perspectives on SOA.
It is at least welcome though that OASIS, The Open Group and the OMG have seen the need to cooperate on Navigating the SOA Standards Landscape Around Architecture. Perhaps now they can move forward as I suggest and ensure greater collaboration and consistency between their efforts with a single purpose in mind.
We would be happy to participate in such a unified process. What we can’t afford to do unlike IBM is participate in three (even though they have all invited us to), and more to the point it would be counter productive! In the meantime we will continue to participate in SoaML and refine our own CBDI-SAE Meta model for SOA. To that end we have just published a draft V3 of our model which includes SoaML adoption.
Users shouldn't need to be shown how to navigate their way around multiple SOA standards. They just want to know "are we there yet?"
There is no need for me to repeat his comments.
In his blog, David comments on Navigating the SOA Standards Landscape Around Architecture, a paper recently published by OASIS and The Open Group. It seems to us and many others that this is an attempt on the part of the authors to gloss over the fact they have managed to produce three alternative SOA standards when the world really only needs one. Saying that OASIS SOA RA is ‘similar’ to the Open Group SOA Ontology is a bit like saying Cricket is similar to Baseball. Because they both involve similar concepts of bat and ball presumably this means a cricket team could play a baseball team?
It is only with a more detailed level of mapping of more precise meta models that anything useful can be done in the real world. Even then, the reality is it is difficult to mix two frameworks and meta models.
One of the intriguing things for me is the involvement of common participants in all three SOA standards efforts at OASIS, The Open Group and also at OMG. IBM in particular stands out as a vendor who appears to have put significant effort into them all, and with minimal visible consistency resulting. Why? How does it help IBM customers to provide them with a choice of three alternative SOA standards? Surely that only works to slow adoption of SOA, not to encourage it.
This was one of the major successes of Web Service Protocols – that there is only one standard for each requirement in the protocol ‘stack’. Even though the various protocols are administered by different bodies, they have managed to avoid competing. Well eventually anyway after some initial vendor-based alternatives fell by the wayside. And since then take up has been widespread. Partly this was achieved because vendors such as IBM together with Microsoft participated in only one activity per protocol and not three. Hence others were forced to make decisions to go one way or the other rather than sit on the fence and be endlessly compromised by choice.
And this is what the same groups now need to do with SOA standards. Combine their energies, put aside their differences and produce a set of unified standards – even if different elements within it are administered by different bodies, as with Web Service Protocols, so they can each retain some ownership. We only need one SOA Reference Model, one SOA meta model, one set of principles and so on. But once you have the common foundation, just like the Web services efforts, there can be parallelism. From our work on the CBDI SAE meta model we know that there are multiple views which can be modelled concurrently such as business, specification, implementation, deployment, testing etc.
That said, perhaps more of the competitive approach taken with Web Services would be apt. That is, I would rather see IBM back one SOA Meta Model standard for example, and not three. I am sure the competitive nature of early Web Service protocol standards activity really helped to force the pace – a sort of SOA ‘Space Race’. Now, rather like the pace of the space race today, I get the impression it will now be decades before we land on the SOA moon. Of course, if OASIS, The Open Group and OMG cut the stack up as I suggest and avoid overlap so much the better.
But why is this important? At runtime, clearly the vision of SOA wasn’t going to work without consensus on the interoperability standards. But I believe it would be a mistake to assume a similar consensus isn’t required at earlier stages in the life cycle. Time after time we see that the lack of a common SOA framework is hindering SOA adoption in organizations. Sure different projects can all agree to use Web Services at runtime, but the lack of any common standards before they even get to that point means that much of the SOA vision remains elusive when viewed from an enterprise perspective. It is pretty hard to have full life cycle asset management and governance over SOA deliverables if the concepts change for each phase. In most organizations, users have little choice but to pick a single vendor's proprietary solution to such requirements that complies with no relevant SOA standards.
I am reminded of object orientation pre UML. What is needed now is a Unified SOA.
SoaML, in which we have participated might be one step in that direction, at least at the modelling language level. Even so, TOGAF 9 has its own meta model, but so does Archimate, and there is one implied by the OASIS SOA RA, and so on. Then there are the differences even between The Open Group’s TOGAF 9’s coverage of SOA, and their own SOA Source Book. Do you know for example when you see a concept mentioned in one document it has the same meaning as in another? Often no definition of the concept or reference is even given so it is difficult to be sure. Clearly there is still a long way to go.
And let’s not forget that there is a large government and defence sector who are extending their own frameworks such as FEA, DODAF, and MODAF with yet more unique perspectives on SOA.
It is at least welcome though that OASIS, The Open Group and the OMG have seen the need to cooperate on Navigating the SOA Standards Landscape Around Architecture. Perhaps now they can move forward as I suggest and ensure greater collaboration and consistency between their efforts with a single purpose in mind.
We would be happy to participate in such a unified process. What we can’t afford to do unlike IBM is participate in three (even though they have all invited us to), and more to the point it would be counter productive! In the meantime we will continue to participate in SoaML and refine our own CBDI-SAE Meta model for SOA. To that end we have just published a draft V3 of our model which includes SoaML adoption.
Users shouldn't need to be shown how to navigate their way around multiple SOA standards. They just want to know "are we there yet?"
Subscribe to:
Posts (Atom)