- From: Toni Ruokolainen <Toni.Ruokolainen@cs.Helsinki.FI>
- Date: Tue, 15 Mar 2011 22:06:15 +0200
- To: "public-xg-usdl@w3.org" <public-xg-usdl@w3.org>
- Message-ID: <4D7FC6B7.1010502@cs.Helsinki.FI>
Hi all,
Here are some thoughts provoked by the presentation Kay gave us last week..
First of all, variability management can not be achieved with purely
conceptual or linguistic
approaches. Variability can be supported by modelling languages, but
managing
variability requires methodological support in form methods, tools, and / or
processes. From this perspective, I consider the presentation Kay gave
us very
relevant for our work, if we want to create a mechanism for managing
USDL variants.
In the following a selection of ideas are briefly introduced that could
be considered
for enabling variability management in the context of the USDL
framework. I numbered
the approaches 0-3, the first one being the approach we were presented
with, and the last
one being my personal favourite (while it is the most complicated in a
sense).
0) "Integration Knowledge Library" -approach
Proceed as suggested by Kay in the teleconference and utilize CCTS and the
corresponding Integration Knowledge Library for providing a
technology-based
support for designing and maintaining domain specific variants of USDL.
+ existing work and tools can be utilized to get a "flying start"
- technology dependent approach
- does not support service engineering (rejection of the existing
Ecore-based
USDL metamodels)
- disruptive approach, as discussed in Kay's presentation
1) "CCTS and Ecore in concert" -approach
Utilize both approaches: use the CCTS for variant parts of USDL and
Ecore for
specifying the common parts of USDL (M5). Provide an Ecore metamodel
for the
CCTS such that model transformations can be utilized between CCTS and
USDL
representations of domain specific business vocabulary.
+ does not reject the Ecore / EMF facilities and existing Ecore-based
USDL metamodels
--> enhanced engineering support when compared to the previous
approach
- heavy semantic burden on model transformations: how to map CCTS
concepts to
USDL concepts
- does not provide any support for designing the mappings / model
transformations
- it can be difficult to define consistency rules, constraints and best
practices for the mappings in a general level between two such
different
conceptual frameworks (CCTS vs. USDL)
2) "BPMN extension" -approach
I actually do not know, if this is anything similar that some of you
meant when
introducing the BPMN 2.0 extension mechanism as a possible solution. What
follows is my interpretation for the applicability of an extension
mechanism
similar to the BPMN 2.0.
Incorporate the CCTS variability support in the USDL metamodel. Use a
metamodel
extension approach similar to BPMN 2.0 to provide USDL with an extension
mechanism. The extension mechanism could also reflect the CCTS approach,
i.e. the USDL metamodel is provided with constructs that align with
the CCTS
approach and is "implemented" using type-object -pattern such as
applied in the
BPMN 2.0.
+ makes the variability less dependent on technology, as the mechanism
for variability
management is somewhat made visible in the metamodel
- "pollutes" the current USDL metamodel with CCTS concepts
- possibly requires large refactoring of the USDL metamodel
- the preceding pollution and refactoring may create severe backward
compatibility problems (is this an issue anyway?)
3) "Domain specific metamodelling" -approach
Create a CCTS -based metamodel for supporting definition of variants
in the
context of business vocabularies (similarily to approach 1) in the
context of a
conceptual framework similar to USDL. So this CCTS -based metamodel is
kind of
a conceptual union between CCTS and USDL metamodels. Using model
transformations, generate domain specific USDL metamodels for each variant
described with the CCTS -based metamodel.
This approach is a kind of mixture between approaches 1 and 2: it
utilizes a CCTS-based metamodel
for defining business vocabulary variants, and creates domain specific
USDL variants from them
with model transformations.
+ USDL metamodel is utilized as such, no extensions needed
+ new USDL variants can be generated efficiently with model
transformations
+ the CCTS-based metamodel can be used for enabling efficient
development of
"Integration Knowledge Libraries" by utilizing the EMF framework
+ the original CCTS approach with IKL can be utilized for bootstrapping a
variant management infrastructure: only an additional mapping from CCTS
information model to the CCTS-based metamodel is needed
Model extension mechanism[1] can be utilized in approaches 1 and 3 for
formalizing the relationships
between "core" USDL and "extended" USDL metamodels (variants).
Best regards,
-Toni
[1] Barbero, Mikael and Jouault, Frederic and Gray, Jeff and Bezivin,
Jean. A Practical Approach to Model Extension.
In Akehurst, David and Vogel, Regis and Paige, Richard (eds.) Model
Driven Architecture- Foundations and Applications,
Lecture Notes in Computer Science, volume 4530, Springer Berlin /
Heidelberg, 2007.
http://dx.doi.org/10.1007/978-3-540-72901-3\_3
--
Toni Ruokolainen (toni.ruokolainen(at)cs.helsinki.fi)
Doctoral student (Ph.Lic)
Department of Computer Science (http://www.cs.helsinki.fi/u/thruokol)
University of Helsinki, FINLAND
On 11/03/11 12:57, Weissenberg, Norbert wrote:
>
> Hello Daniel,hello all,
>
> the protocol for my feedback is okay, the alternative BPMN 2.0
> extension mechanism is already mentioned.
>
> One thought mentioned in the session might be added: is the USDL-v2
> the language visible in all contexts,
>
> and is there an inverse process of reducing the kernel visible in all
> contexts.
>
> The path can be followed iff
>
> - W3C (or another std org) can be conviced to run the central schema
> registry
>
> - the processes are defined in an acceptable way, i.e. there is a good
> probability to get needed attributes accepted quickly, e.g. in a test
> stage.
>
> - and there is no licence cost.
>
> The pro is that the schema is centrally controlled and parties can
> profit by extensions of others.
>
> The con is that this control might be a long-lasting process not agile
> enoth for the industry. That might kill the approach.
>
> We should then evaluate if BPMN extension mechanism is enough.
>
> -Norbert-
>
> *Von:*public-xg-usdl-request@w3.org
> [mailto:public-xg-usdl-request@w3.org] *Im Auftrag von *Oberle, Daniel
> *Gesendet:* Freitag, 11. März 2011 10:52
> *An:* Public XG USDL (public-xg-usdl@w3.org); Member XG USDL
> *Cc:* Stuhec, Gunther
> *Betreff:* RE: Approach to USDL variant management
>
> Dear all,
>
> since there is no audio and we did not take separate notes of your
> feedback could you please:
>
> -Recap the feedback you gave
>
> -Let us know if there are alternate approaches which we might have missed
>
> -Give us your general thoughts whether we should follow this path
>
> Would be nice if you could do so until our next regular call on 21^st
> of March.
>
> Sorry for the inconvenience
>
> Daniel
>
> PS: Please reply to the mailinglist, if possible
>
> *From:*member-xg-usdl-request@w3.org
> [mailto:member-xg-usdl-request@w3.org] *On Behalf Of *Kadner, Kay
> *Sent:* Donnerstag, 10. März 2011 15:46
> *To:* Public XG USDL (public-xg-usdl@w3.org); Member XG USDL
> *Subject:* RE: Approach to USDL variant management
>
> Dear USDL interested colleagues,
>
> Thanks again for that lively discussion and feedback in yesterday's
> call about USDL Variant management. Please find the minutes in our
> Wiki at
> http://www.w3.org/2005/Incubator/usdl/wiki/2011-03-09_Approach_to_USDL_variant_management.
> You can also review the slides there. Unfortunately, the recording did
> not work as expected. We'll give it another try when we present this
> to Mr. Jaffe.
>
> Best Regards,
>
> Kay Kadner
>
> -----Original Appointment-----
> *From:* Kadner, Kay
> *Sent:* Dienstag, 19. Mai 2009 12:20
> *To:* Public XG USDL (public-xg-usdl@w3.org); Member XG USDL; Fluegge,
> Barbara; Holger Last; 'matthias.dabisch@attensity.com'; 'Massimo
> Romanelli'; Oberle, Daniel
> *Cc:* Fasse, Axel; 'Stewart Welbourne'; 'Peltz, Christopher'; Leidig,
> Torsten; 'Schulte, Stefan'; Hellinger, Christian (external);
> 'Blackwell, Ken'; 'Weissenberg, Norbert'; Stuhec, Gunther; Frenzel,
> Petra; Neidecker-Lutz, Burkhard; 'K. Kutsikos'; Markus Radmayr; 'Nils
> Meyer'; Greguletz, Nicole; Schaeffler, Martin
> *Subject:* Approach to USDL variant management
> *When:* Mittwoch, 9. März 2011 15:30-16:30 (UTC+01:00) Amsterdam,
> Berlin, Bern, Rome, Stockholm, Vienna.
> *Where:* phone conference
>
> Dear Members and potential users of USDL,
>
> One important issue for a language like USDL is the management of
> variants and deviations from the original specification. In other
> words, we expect that various versions will be derived from the
> original USDL, where each of these versions will be dedicated to some
> specific domain, like car repair, financing, health, or simply
> countries. In this call, we present an approach to handle these
> variations. Of course, we like to discuss that with you and get
> feedback and opinions about that approach.
>
> Please find the dial-in details below. We are looking forward to a
> lively discussion.
>
> Best Regards,
>
> Kay Kadner
>
> https://sap.emea.pgiconnect.com/D044576
>
> Participant Passcode: 6533560918
>
> Dial in numbers:
>
> Germany, Frankfurt: +49 69 71044 5497
>
> Australia, Sydney +61 2 8223 9948
>
> USA, New York: +1 212 999 6675
>
> Canada, Montreal: +1 514 315 7878
>
> France, Paris: +33 (0)1 70 99 43 40
>
> Greece, Athens: +30 210 969 6487
>
> UK, London: +44 20 7153 9921
>
> Finland, Helsinki: +358 9 2319 3954
>
> Austria, Vienna +43 2 68220 59207
>
> Sweden, Stockholm +46 8 5051 3640
>
> Dr. Kay Kadner
>
> Senior Researcher I Chair of W3C USDL XG I SAP Research Dresden
>
> SAP AG I SAP Research I Chemnitzer Str. 48 I 01187
> Dresden I Germany
>
> T +49 351 4811-6127 I F +49 6227 78-44576 I M +49 172
> 4639220 I mailto:kay.kadner@sap.com
>
> www.sap.com/research <http://www.sap.com/research>
>
> Please consider the impact on the environment before printing this e-mail.
>
> Pflichtangaben/Mandatory Disclosure Statements:
>
> http://www.sap.com/company/legal/impressum.epx
>
> Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige
> vertrauliche Informationen enthalten.
>
> Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine
> Kenntnisnahme des Inhalts, eine Vervielfältigung
>
> oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte
> benachrichtigen Sie uns und vernichten Sie die
>
> empfangene E-Mail. Vielen Dank.
>
> This e-mail may contain trade secrets or privileged, undisclosed, or
> otherwise confidential information. If you have
>
> received this e-mail in error, you are hereby notifi ed that any
> review, copying, or distribution of it is strictly prohibited.
>
> Please inform us immediately and destroy the original transmittal.
> Thank you for your cooperation.
>
Received on Wednesday, 16 March 2011 10:36:46 UTC