I am personally a bit sick of that, it seems that Oslo is taking the same path as WCF/WF and it will take years to undo quick "pragmatic" decisions made in the early days of the project. Considering that WCF was announced in 2003, shipped 2007 and being rewritten (one more time...) in 2009 for a release in 2010-2011, it looks like we should expect Oslo to do anything useful in 2014-2015 timeframe. I wish a lot more people would have the luxury to work with these kinds of time frames.¿Será Oslo solo aplicable para la plataforma Windows? Tan pronto se desenvuelve cualquier discusión sobre el tema, éste se encauza por ese camino. En ese caso, el valor que se discute sobre la capa superior (meta-metamodelo) tendría escaso alcance.
Dubray puntualiza lo que Charles Young piensa al respecto. Todo lo dicho por Young es de mucho interés, pero particularmente sobre los objetivos de Oslo:
In this thought exercise, we are capturing models which are specific to a given technology. We need to be able to specify the metamodel very precisely in order to ensure that our models are valid and well-formed in respect to BizTalk Server. However, we will probably be less interested, in this scenario, in ensuring that our metamodels conform to some meta-metamodel. One reason for this is that we probably won’t have a compelling need to exchange BizTalk-specific metadata with other systems and applications. This could change over time, however. For example, as BizTalk Server evolves further, future versions may exhibit much closer integration with platform-level technologies such as WCF and WF, or standards such as BPEL4WS and BPMN. They may be more deeply integrated into platform-level host environments (this is already the case with regard to IIS-based ‘isolated’ hosts in BizTlk Server). In this case, the ability to exchange and transform metadata on the basis of some meta-metamodel could become an important consideration. Even here, though, we might wish to our meta-metamodelling to address a specific technology platform.Charles Young historia las relaciones entre Microsoft y la OMG (UML, metamodels, MOF and MDA), hasta desembocar en las Software Factories y Oslo. Pero eso podría verse por separado. Curiosamente, esta historia de interrelaciones es prácticamente inhallable hoy.
A major theme in Oslo is the reduction of the bar that ISVs and development teams face when seeking to support rich modelling approaches to software development and runtime configuration. Oslo is agnostic with regards to the number of metalayers that are required in any given scenario and makes no assumptions with regard to how platform/technology-specific or independent a particular model needs to be. It avoids forcing conformance to any abstract M3 specification and provides a general-purpose metamodelling language that minimises the learning curve for developers. To all this, Microsoft adds pre-defined mappings to T-SQL and is building additional tooling for generalised visualisation of models and parser generation tools for creating domain-specific modelling languages. They also provide many pre-defined models (e.g., for WF workflows) out of the box.
In our BizTalk Server example, the bar is now set very low. MSchema is a natural choice for defining model specifications whose conformance to the models in the BizTalk management database can be verified, but which can reduce the amount of detail to an appropriate level. The Oslo tooling can be used to create tables in the repository which correspond directly to the tables in the Management database. Access to models in the repository can be via any appropriate and familiar data access technology that can connect to SQL Server. There is no need for developers to engage in a steep learning curve in respect to meta-metamodelling, no need to conform to unfamiliar APIs and no need to inject an unnecessary level of platform independence in the way models are specified.
3 comentarios:
Jorge:
thank you for your comments. Meta-Meta-Models are not just about metadata exchanges. There are a lot more fundamental implications when it comes to weaving aspects in different parts of the metamodel or implementation of the runtime that consumes the metadata.
The M3 layer is also a key enabler of MOP as you cannot derive a programming model without explicitly tagging the metamodel. In other words, when there is an "implementation" element, the meta-type of a metamodel element will define precisely how this particular element behaves in an implementation.
Thanks you, Jean-Jacques, the merit if yours.
I agree with the vision of Jean Bezivin on meta-metamodels. Besides, given the case that having different standards for models, a M3 layer is required. Of course, if you belive that there are another world outside.
Yes, Jean has done a fantastic job to open our thinking, I always keep this quote in mind:
■ Model engineering is the future of object technology.
■ Model engineering subsumes object technology (goes beyond but does not invalidate)
■ Many general principles learnt during the development of object technology may be applied to the development of model engineering
Publicar un comentario