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

Difference between revisions of "MnM Minutes CC 20070615"

From HL7Wiki
Jump to navigation Jump to search
 
(15 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
[[Category:2007 MnM Minutes]]
 
==Attendees==
 
==Attendees==
 
*Kathleen Connor
 
*Kathleen Connor
Line 19: Line 20:
  
 
Concerns regarding desinging system behaviors are pervasive in HL7 (from application roles to committee-specific '''complex interactions''' to functional service specifications). We have a variety of constructs (Applications Roles, SOA Services, interactions) that require dynamic views and behavioral model constructs such as interfaces, ports, and subsystems.
 
Concerns regarding desinging system behaviors are pervasive in HL7 (from application roles to committee-specific '''complex interactions''' to functional service specifications). We have a variety of constructs (Applications Roles, SOA Services, interactions) that require dynamic views and behavioral model constructs such as interfaces, ports, and subsystems.
 +
Ioana summarized the concerns expressed on the list because we don't have a generic way to deal with behavioral modeling. The following is a set of objectives voiced on the list:
 +
 +
*"All implementations I've experienced to date include both messaging and services to accomplish the application solution.  We need to begin to understand and include those requirements for dynamic model methodology for services as well as messaging."
 +
*"We need to tackle the generic modeling considerations before we can delve into any specific model. Order management is one instance of a behavioral model and I expect it to be developed by the appropriate TC not by M&M during harmonization. I think M&M has the responsibility to develop the generic methodology that can be applied by any committee to their needs to communicate how the interactions are intended to be applied to the fulfillment on business processes."
 +
*"The agenda for these two days was intended to address changes to the dynamic model methodology to meet the requirements initially identified by the LabSIG (who is seeking to address negative ballots re: the current dynamic model).  We're obviously interested in everyone's needs re: documenting the dynamic model and appropriate artifacts to support.
 +
We are intending to meet and discuss the methodology itself including diagramming, etc.  This particular group does not have the same makeup as the group working through OO on order management.  I expect that exercise will continue within OO."
 +
 +
*[[OO_Dynamic_Model|A link provided by Hans to on-going work in Orders and Observation/Lab SIG]]
 +
* MITA Project Service Specifications demonstrate the use of UML for describing behavior and service [http://www.bptrends.com/publicationfiles/03%2D05%20WP%20WS%2DCDL%20Barros%20et%20al%2Epdf choreography] (rather than [http://weblogs.java.net/blog/johnreynolds/archive/2006/01/service_orchest.html orchestration] of processes. This project produces WSDL and XSDs for runtime execution.
  
 
The agenda for next week must address the needs of a variety of stakeholders:
 
The agenda for next week must address the needs of a variety of stakeholders:
Line 29: Line 39:
  
 
===Dynamic Model Agenda (Harmonization Meeting June 21-22, 2007) ===
 
===Dynamic Model Agenda (Harmonization Meeting June 21-22, 2007) ===
 +
The agenda was created in a '''[[Dynamic_Model_Agenda_June_21_2007| separate page]].'''
  
The CBC form, as submitted is available [[Media:CBC_INFO_MNM_2007MAY-Complete 20070119.pdf|on this Wiki]] and also at [http://www.hl7.org/library/committees/mnm/minutes/CBC_INFO_MNM_2007MAY-Complete%2020070119.pdf http://www.hl7.org/library/committees/mnm/minutes/CBC_INFO_MNM_2007MAY-Complete 20070119.pdf].
+
----
 
 
 
 
====Thursday, June 21st===
 
=====Q1: 9 - 10:30 am EST =====
 
Inventory of where we are with the dynamic model
 
List of know issues
 
 
 
 
 
Q2: Services and Application roles
 
 
 
How do we relate operations (in interfaces) to
 
 
 
Q3: Identify artifacts that will affected by the changes.
 
Documenting and specifying complex interaction patterns
 
 activity diagram were deemed too complex
 
 
 
 
 
Q4: Complex interaction patterns
 
 
 
Service orchestration vs. choreography
 
We will not go into the solution for run-time representation of system (e.g. WS-CDL
 
WS-BPEL). We will focus on the design time
 
 
 
 
 
Friday AM
 
 
 
Q1: Develop approaches to make this real
 
 
 
 The  methodology will be linked back to the product lifecycle management project in the HDT
 
 Select the notation
 
 
 
Q2 : Opens session
 
 
 
 
 
  
 
Minutes by --[[User:Ioana13|Ioana Singureanu]] 14:50, 15 June 2007 (CDT)
 
Minutes by --[[User:Ioana13|Ioana Singureanu]] 14:50, 15 June 2007 (CDT)

Latest revision as of 01:59, 21 May 2010

Attendees

  • Kathleen Connor
  • Lee Coller
  • Ioana Singureanu
  • Lloyd McKenzie
  • Rick Chesnik
  • John Cooper
  • Dale Nelson


Agenda

  • (Lloyd): Administrative topic: Dynamic Model - agenda
  • (Lloyd): Hot Topics: Act Reference - postponed for next WGM because this topic requires input from INM.

Mottion to accept agenda: (No objections)

Administrative Topic: Dynamic Model Discussion

Concerns regarding desinging system behaviors are pervasive in HL7 (from application roles to committee-specific complex interactions to functional service specifications). We have a variety of constructs (Applications Roles, SOA Services, interactions) that require dynamic views and behavioral model constructs such as interfaces, ports, and subsystems. Ioana summarized the concerns expressed on the list because we don't have a generic way to deal with behavioral modeling. The following is a set of objectives voiced on the list:

  • "All implementations I've experienced to date include both messaging and services to accomplish the application solution. We need to begin to understand and include those requirements for dynamic model methodology for services as well as messaging."
  • "We need to tackle the generic modeling considerations before we can delve into any specific model. Order management is one instance of a behavioral model and I expect it to be developed by the appropriate TC not by M&M during harmonization. I think M&M has the responsibility to develop the generic methodology that can be applied by any committee to their needs to communicate how the interactions are intended to be applied to the fulfillment on business processes."
  • "The agenda for these two days was intended to address changes to the dynamic model methodology to meet the requirements initially identified by the LabSIG (who is seeking to address negative ballots re: the current dynamic model). We're obviously interested in everyone's needs re: documenting the dynamic model and appropriate artifacts to support.

We are intending to meet and discuss the methodology itself including diagramming, etc. This particular group does not have the same makeup as the group working through OO on order management. I expect that exercise will continue within OO."

The agenda for next week must address the needs of a variety of stakeholders:

  • Support for the processes specified in the HDF regarding behavioral models
  • SOA Service support and relating interfaces to Application roles
  • Ability to describe complex interactions for specific domains
  • Leverage the notation and design to describe a variety of in, in/out, output parameters and return types
  • We need to ensure that our design constructs are supported by implementation technologies (e.g. WSDL, WS-CDL, WS-BPEL)

Dynamic Model Agenda (Harmonization Meeting June 21-22, 2007)

The agenda was created in a separate page.


Minutes by --Ioana Singureanu 14:50, 15 June 2007 (CDT)