Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

Q&A: Ask OpenMRS »
Discussion: OpenMRS Talk »
Real-Time: IRC Chat

Resources

Skip to end of metadata
Go to start of metadata

Date

23/12/2010

In Attendance

  • You

Agenda

  • Quickly review previous meeting minutes (5 min)
  • 1.8 Update (20 min)
  • Webservices 1.0 discussion meeting (60 min)
  • After-action review & next week's agenda (5 min)

Minutes

Real-time notes: http://notes.openmrs.org/devcall20101223

Web services 1.0 talking points

  1. End goal?
    1. How many services, how many objects, etc
  2. Soap vs REST
    1. both?
    2. Is there a framework that will help us combine them?
  3. Baked into API, or separate module?
  4. Any good examples of object+transaction based APIs out there?
    1. Atlassian JIRA API
    2. Atlassian Confluence Remote API
  5. Authentication methods?
    1. Session-capable (OAuth 2.0 , OpenID)
    2. (REST module uses stateless basic auth through request now)
  6. Publish a WSDL /WADL (Why Contract First?) - (Interesting Debate on Contract First Vs Code First )

Outcomes

0%

TODO's

Transcripts

  • Backchannel IRC transcript
  • Audio recording of the call: Listen online or download - available after the meeting

Notes

Last Week's TODOs:

  • Need a ticket to test new 1.8 widgets in FormEntry (Burke is creating)
  • Figure out how to mavenize modules

1.8 Update

  • Beta release will be Jan 6 2011
  • Darius has a few tickets left that should be done by then
  • Speed difference for location search is a red flag, but it is due to a built-in 400ms delay on all searches
    • For the sake of performance testing, set the delay to zero
    • Argument against that: trying to mimic a realistic environment, not optimal
  • TODO: reassign TRUNK-1707 (jQuery UI themerolling)
  • TODO: increase resources for OpenMRS servers (test and apps), get OSU involved
  • TODO: Wyclif will email Zabil and cc: Darius re: 1.8 installer

Web Services

  • End goal?
    • 0.1
    • Requirements
    • Within a module (not built into core)
    • Must allow API methods to be easily exposed to web services
    • Must allow modules to easily expose methods through web services (or at least head down this path)
    • Should limit/avoid business rules in web service layer – i.e., thin layer exposing API methods
    • Must support secure connections
    • Methods are documented on the wiki
    • Strategy
    • Not covering full API
    • Not 100% final – will need to allow for us to fail and iterate
    • Not part of core
    • Not necessarily using the same objects as the API – i.e., introduce DTOs
    • How many services, how many objects, etc?
    • Authentication
    • R (get & search) methods (concept, person, user, locations, cohorts, ...)
    • CRUD methods (patient, encounter, obs)
    • Export "patient" (with their encounters, obs, etc.)
    • 0.2
    • HL7
    • CRUD for metadata
    • Run rule(s)
    • Get reports for a time period
  • Strategy and road map?
    • Web service-a-thon? If so, when?
    • What's the plan to move Web Services forward? Who is going to do what?
  • Soap vs REST vs. both?
    • Is there a framework that will help us combine them?
    • Burke: SOAP++ for heavy work, ReST++ for quick & dirty
    • Darius: wants ReST and SOAP requests to have the same underlying method returning the same data
    • Sunny: SOAP = WSDL, ReST = WADL (Spring supports ... ReST?)
    • Summary: would like both (i.e., pseudo-REST by exposing methods as simple HTTP calls)
  • JSON vs XML vs. both?
    • SDMX-HD = XML
    • Summary: would like both
  • Baked into API, or separate module?
  • Any good examples of object+transaction based APIs out there?
    • Atlassian JIRA API
    • Atlassian Confluence API (http://confluence.atlassian.com/x/3QI)
    • Facebook API
    • Twitter API
    • Google Health
    • GDATA for Google Health exposes a subset of CCR
    • Microsoft Healthvault
  • How is authentication handled?
    • Authentication methods?
    • REST module uses stateless basic auth through request now
    • Session-capable – i.e., token-based
    • Authenticate to get token
    • Token sent to all subsequent calls
    • Authenticate as user
  • Publish a WSDL (Why Contract First?? )
  • No labels