- From: Oberle, Daniel <d.oberle@sap.com>
- Date: Mon, 21 Mar 2011 12:55:56 +0100
- To: "public-xg-usdl@w3.org" <public-xg-usdl@w3.org>
- CC: "Stuhec, Gunther" <gunther.stuhec@sap.com>
- Message-ID: <B253C937481B304881523B751DC69D7844CA12A8BB@DEWDFECCR02.wdf.sap.corp>
Dear Toni,
thanks a lot for pointing out your additional alternatives. Frankly, I did not understand everything, especially option 1).
In addition, it might be useful if you position each alternative to the 4 pillars of 0) as mentioned in the presentation, namely
1. Grammar
2. Context Logic
3. Tooling
4. Processes
According to our opinion, a full-fledged variant mgmt has to offer solutions for all 4. According to your description below I cannot see whether 1-3 have those features.
Many regards,
Daniel
From: public-xg-usdl-request@w3.org [mailto:public-xg-usdl-request@w3.org] On Behalf Of Toni Ruokolainen
Sent: Dienstag, 15. März 2011 21:06
To: public-xg-usdl@w3.org
Subject: Re: WG: Approach to USDL variant management
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<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> [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<mailto: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 21st 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> [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<mailto: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<mailto:public-xg-usdl@w3.org>); Member XG USDL; Fluegge, Barbara; Holger Last; 'matthias.dabisch@attensity.com<mailto: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 Monday, 21 March 2011 11:56:40 UTC