This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Eclipse Architecture discussion"

From HL7Wiki
Jump to navigation Jump to search
 
(One intermediate revision by the same user not shown)
Line 84: Line 84:
 
* Roll Call & Agenda Review
 
* Roll Call & Agenda Review
 
* Eclipse Architecture Discussion
 
* Eclipse Architecture Discussion
 +
**discuss how HL7 has used the Eclipse platform to date,
 +
**what HL7 Tooling WG intended to achieve using the Eclipse platform
 +
**seek advice from a senior Eclipse architect.
 +
*Identify next steps
  
  
Line 105: Line 109:
  
 
* Roll Call & Agenda Review
 
* Roll Call & Agenda Review
 +
**Introductions made.
 
* Eclipse Architecture Discussion
 
* Eclipse Architecture Discussion
−
**Jane refers to earlier document circa 2006 on why we recommend Eclipse as new platform for integrated set of tooling. Andy recalls open source and vendor neutrality were part of the rationale. Jane asks if those are still our objectives and is Eclipse still the right platform to meet those objectives. Woody suggests that "right" might be considered the "best opportunity" compared to other platforms.  
+
**discuss how HL7 has used the Eclipse platform to date,
−
**Jane notes we have two experienced Eclipse architects on the call so the opportunity is now to learn what we need
+
***Last version of tooling strategy and capability shows why we recommend Eclipse as new platform for integrated set of tooling. Andy recalls open source and vendor neutrality were part of the rationale. Jane asks if those are still our objectives and is Eclipse still the right platform to meet those objectives. Woody suggests that "right" might be considered the "best opportunity" compared to other platforms. Emerging strategy includes broader scope in work with OHT as well as tools to support implementers. This will likewise add scope to the interdependency between and among tools.
−
**Introductions made.
+
***Jane describes the complexity of the environment in which we are trying to manage a tooling strategy. Static Model Designer replacement intended in Eclipse.
−
**Jane describes the complexity of the environment in which we are trying to manage a tooling strategy. Static Model Designer replacement intended in Eclipse.  
+
***Registration of concept domains in our vocabulary data store, currently in MIF. Ongoing evolution of terminologies is also a significant challenge. Support of publishing is also an important commitment. Artifacts can have their own change management lifecycle and versioning is an important part of the function.
−
**AMS asks how commercial products fit into the Tooling strategy? Interchange between formats like CSV, etc to take components of model content into other tools?
+
**what HL7 Tooling WG intended to achieve using the Eclipse platform
−
** Woody describes the current environment and its interaction with Eclipse. EMF is used to demonstrate core models.
+
***objectives for new, integrated Tooling Platform:
−
**Registration of concept domains in our vocabulary data store, currently in MIF. Ongoing evolution of terminologies is also a significant challenge. Support of publishing is also an important commitment. Artifacts can have their own change management lifecycle and versioning is an important part of the function.
+
****cross platforms including non-proprietary solutions
 +
****Designed to be extensible and interoperable with other tools, capabilities like APIs and extension points
 +
****open source, vendor-neutral
 +
****build on existing open source capability rather than develop tools from scratch
 +
****adaptability
 +
****a new tooling design principle is to design and manage for change as the environment is dynamic and multiple sources of change exist
 +
****able to re-generate existing models as the underlying reference models are changed
 +
***AMS asks how commercial products fit into the Tooling strategy? Interchange between formats like CSV, etc to take components of model content into other tools? Past strategy was to use existing tools if they were fit for purpose. We also have people using artifacts produced for publishing purposes that are used downstream for implementation purposes (software development and integration implementation). From that point of view the CTS2 terminology services is "in scope" but there may be other tools coming that meet that purpose.
 +
**seek advice from a senior Eclipse architect.
 +
***Jane notes we have two experienced Eclipse architects on the call so the opportunity is now to learn what we need
 +
 +
 +
 
 +
*Discussion
 +
** Woody describes an experiment he conducted taking the current environment developing interaction with Eclipse. EMF is used to demonstrate core models.  
 
**Woody asks about integration; Ed cautions against combinatorial complexity explosion using EMF with multiple input models. Modeling is happening more in eCore. Woody described work importing MIF ballot material into eCore EMF. Jane notes that we also interact with other tools from other sources and maintain semantic information, whether an XMI import or export. She mentions the OWL approach to ontology management and the vocabulary data maintenance and semantics management that is part of the larger picture.
 
**Woody asks about integration; Ed cautions against combinatorial complexity explosion using EMF with multiple input models. Modeling is happening more in eCore. Woody described work importing MIF ballot material into eCore EMF. Jane notes that we also interact with other tools from other sources and maintain semantic information, whether an XMI import or export. She mentions the OWL approach to ontology management and the vocabulary data maintenance and semantics management that is part of the larger picture.
−
**Mapping and transformation tools in the eCore space? M to M project, ATL Atlas Transformation Language, OMG has QVT spec. XMI as standard from OMG is one possible serialization but not the only one. Woody receives questions to receive RIM in XMI…
+
***Mapping and transformation tools in the eCore space? M to M project, ATL Atlas Transformation Language, OMG has QVT spec. XMI as standard from OMG is one possible serialization but not the only one. Woody receives questions to receive RIM in XMI…
−
**Tools that provide XMI provide schema on which it's based, an emof file. Need a reference implementation to demonstrate consumability for users, unlike V2.  
+
**Tools that provide XMI provide schema on which it's based, an emof file. Need a reference implementation to demonstrate consumability for users, unlike V2. Whether this is in scope for the Tooling WG is something that needs to be determined as part of the Tooling Strategy
−
**Jane notes we need to identify what the next step for what each of these tools is going to do, in addition to demonstrating that they do what they are intended to do. If we are in refactoring mode with existing tools, what will it take to do that? Also how to formalize a continuous change management process…
 
 
**They asked what is our primary way of exchanging data - XML format? Woody says yes, we represent in MIF, then XML.  
 
**They asked what is our primary way of exchanging data - XML format? Woody says yes, we represent in MIF, then XML.  
 
**Eric adds that XML serialization is okay for interchange but not for persistence in a repository. See CDO from the EMF page at http://www.eclipse.org/cdo.
 
**Eric adds that XML serialization is okay for interchange but not for persistence in a repository. See CDO from the EMF page at http://www.eclipse.org/cdo.
 
**Jane notes that consulting opportunity is being pursued to flesh out the rational way to set the strategic vision and tactical plan. AMS wants to ensure there is a knowledge transfer component as well. Jane notes that full-time staffers do not have Eclipse knowledge now. We also have templates to manage, as formalized use-case specific constraints against the balloted models that need to be artifacts in themselves, governing rules for populating instances.
 
**Jane notes that consulting opportunity is being pursued to flesh out the rational way to set the strategic vision and tactical plan. AMS wants to ensure there is a knowledge transfer component as well. Jane notes that full-time staffers do not have Eclipse knowledge now. We also have templates to manage, as formalized use-case specific constraints against the balloted models that need to be artifacts in themselves, governing rules for populating instances.
 +
 +
 +
*Conclusions:
 +
**Jane feels this discussion has validated the strategic direction to work in Eclipse from five years ago.
 +
**Ed concurs that while EMF may not be the perfect choice it's the best choice available for what we're doing.
 +
 +
 +
*Identify next steps
 +
**Jane notes we need to identify what the next step for what each of these tools is going to do, in addition to demonstrating that they do what they are intended to do. If we are in refactoring mode with existing tools, what will it take to do that? Also how to formalize a continuous change management process…
 
**AMS volunteers to act as Tooling liaison to Education if there is formal education that will be developed as a part of this effort. Jane seconds the idea as well as building our toolsmiths. AMS also suggests we offer HL7 training to any consultants that come on board to make them familiar with our space.
 
**AMS volunteers to act as Tooling liaison to Education if there is formal education that will be developed as a part of this effort. Jane seconds the idea as well as building our toolsmiths. AMS also suggests we offer HL7 training to any consultants that come on board to make them familiar with our space.
−
**Woody offers to get together with Andy to look at CDO while in Vancouver. Jane feels this discussion has validated the strategic direction to work in Eclipse from five years ago. Ed concurs that while EMF may not be the perfect choice it's the best choice available for what we're doing. Jane would like to get a list of Eclipse-respected expertise as a pool from whom we can obtain some training/consulting. Ed knows the people who work in the various areas and can help identify sources especially in some of the satellite areas. Jane will discuss with him offline and send him the set of documents he sent to Darin. Woody will also forward his exploratory discussion on translation in EMF.
+
**Woody offers to get together with Andy to look at CDO while in Vancouver.
 +
**Jane would like to get a list of Eclipse-respected expertise as a pool from whom we can obtain some training/consulting. Ed knows the people who work in the various areas and can help identify sources especially in some of the satellite areas.  
 +
***Jane will discuss with him offline and send him the set of documents he sent to Darin.  
 +
**Woody will also forward his exploratory discussion on translation in EMF.  
  
  

Latest revision as of 15:11, 3 May 2012

Tooling Meeting

Meeting Information

HL7 Tooling Meeting Agenda/Minutes

Location: Phone: +1 770-657-9270;
Participant PassCode:586935#
GoToMeeting URL:
https://www1.gotomeeting.com/join/699884034

Date: 2012-05-02
Time: 13:00 PM EDT
Facilitator: Jane Curry Note taker(s): Lynn Laakso
Attendee Name, Affiliation
. .
x Woody Beeler, Beeler Consulting
x Wilfred Bonney, HL7 HQ
x Jane Curry, Co-Chair
x Austin Kreisler
x Lynn Laakso, HL7 HQ Tooling Support
x Ed Merks
x Brian Pech
x Abdul-Malik Shakir (MAX)
x Andy Stechishin, Co-chair
x Darin Wright
Quorum Requirements Met (co-chair plus 3 counting staff): yes

Agenda

Agenda Topics

  • Roll Call & Agenda Review
  • Eclipse Architecture Discussion
    • discuss how HL7 has used the Eclipse platform to date,
    • what HL7 Tooling WG intended to achieve using the Eclipse platform
    • seek advice from a senior Eclipse architect.
  • Identify next steps


Supporting Documents

Minutes

Minutes/Conclusions Reached:

  • Roll Call & Agenda Review
    • Introductions made.
  • Eclipse Architecture Discussion
    • discuss how HL7 has used the Eclipse platform to date,
      • Last version of tooling strategy and capability shows why we recommend Eclipse as new platform for integrated set of tooling. Andy recalls open source and vendor neutrality were part of the rationale. Jane asks if those are still our objectives and is Eclipse still the right platform to meet those objectives. Woody suggests that "right" might be considered the "best opportunity" compared to other platforms. Emerging strategy includes broader scope in work with OHT as well as tools to support implementers. This will likewise add scope to the interdependency between and among tools.
      • Jane describes the complexity of the environment in which we are trying to manage a tooling strategy. Static Model Designer replacement intended in Eclipse.
      • Registration of concept domains in our vocabulary data store, currently in MIF. Ongoing evolution of terminologies is also a significant challenge. Support of publishing is also an important commitment. Artifacts can have their own change management lifecycle and versioning is an important part of the function.
    • what HL7 Tooling WG intended to achieve using the Eclipse platform
      • objectives for new, integrated Tooling Platform:
        • cross platforms including non-proprietary solutions
        • Designed to be extensible and interoperable with other tools, capabilities like APIs and extension points
        • open source, vendor-neutral
        • build on existing open source capability rather than develop tools from scratch
        • adaptability
        • a new tooling design principle is to design and manage for change as the environment is dynamic and multiple sources of change exist
        • able to re-generate existing models as the underlying reference models are changed
      • AMS asks how commercial products fit into the Tooling strategy? Interchange between formats like CSV, etc to take components of model content into other tools? Past strategy was to use existing tools if they were fit for purpose. We also have people using artifacts produced for publishing purposes that are used downstream for implementation purposes (software development and integration implementation). From that point of view the CTS2 terminology services is "in scope" but there may be other tools coming that meet that purpose.
    • seek advice from a senior Eclipse architect.
      • Jane notes we have two experienced Eclipse architects on the call so the opportunity is now to learn what we need


  • Discussion
    • Woody describes an experiment he conducted taking the current environment developing interaction with Eclipse. EMF is used to demonstrate core models.
    • Woody asks about integration; Ed cautions against combinatorial complexity explosion using EMF with multiple input models. Modeling is happening more in eCore. Woody described work importing MIF ballot material into eCore EMF. Jane notes that we also interact with other tools from other sources and maintain semantic information, whether an XMI import or export. She mentions the OWL approach to ontology management and the vocabulary data maintenance and semantics management that is part of the larger picture.
      • Mapping and transformation tools in the eCore space? M to M project, ATL Atlas Transformation Language, OMG has QVT spec. XMI as standard from OMG is one possible serialization but not the only one. Woody receives questions to receive RIM in XMI…
    • Tools that provide XMI provide schema on which it's based, an emof file. Need a reference implementation to demonstrate consumability for users, unlike V2. Whether this is in scope for the Tooling WG is something that needs to be determined as part of the Tooling Strategy
    • They asked what is our primary way of exchanging data - XML format? Woody says yes, we represent in MIF, then XML.
    • Eric adds that XML serialization is okay for interchange but not for persistence in a repository. See CDO from the EMF page at http://www.eclipse.org/cdo.
    • Jane notes that consulting opportunity is being pursued to flesh out the rational way to set the strategic vision and tactical plan. AMS wants to ensure there is a knowledge transfer component as well. Jane notes that full-time staffers do not have Eclipse knowledge now. We also have templates to manage, as formalized use-case specific constraints against the balloted models that need to be artifacts in themselves, governing rules for populating instances.


  • Conclusions:
    • Jane feels this discussion has validated the strategic direction to work in Eclipse from five years ago.
    • Ed concurs that while EMF may not be the perfect choice it's the best choice available for what we're doing.


  • Identify next steps
    • Jane notes we need to identify what the next step for what each of these tools is going to do, in addition to demonstrating that they do what they are intended to do. If we are in refactoring mode with existing tools, what will it take to do that? Also how to formalize a continuous change management process…
    • AMS volunteers to act as Tooling liaison to Education if there is formal education that will be developed as a part of this effort. Jane seconds the idea as well as building our toolsmiths. AMS also suggests we offer HL7 training to any consultants that come on board to make them familiar with our space.
    • Woody offers to get together with Andy to look at CDO while in Vancouver.
    • Jane would like to get a list of Eclipse-respected expertise as a pool from whom we can obtain some training/consulting. Ed knows the people who work in the various areas and can help identify sources especially in some of the satellite areas.
      • Jane will discuss with him offline and send him the set of documents he sent to Darin.
    • Woody will also forward his exploratory discussion on translation in EMF.


Adjourned 2:49 PM EDT.


Return to Tooling


© 2012 Health Level Seven® International. All rights reserved.

Retrieved from "https://wiki.hl7.org/w/index.php?title=Eclipse_Architecture_discussion&oldid=61396"