The EdgeX community has and will continue to explore issues of design and architecture of EdgeX Foundry, its many micro services, deployment mechanisms, testing apparatus, build process and more.

This page contains the list of design/architecture items currently under review by the various working groups and committees.  It also contains a list of the issues reviewed and now considered closed pending any new evidence or material in order to reopen the issue.

Readers are encouraged to review the EdgeX mailing list (in particular the edgex-devel@lists.edgexfoundry.org list) and working group meeting minutes (https://wiki.edgexfoundry.org/display/FA/Working+Groups) for more information and background on the issues.

Open Discussion Items

Messaging technology

• Immediate needs between Core and Export services:  what are the appropriate options to avoid Java/Go issuses
• Longer term, what should be considered the leading service to service communications protocols (outside of REST) and why?
• Our RAML documents reference draft-03 of json-schema.org.  Some questions:
  • draft-06 is the latest, should we move?
  • Do the current Java microservices use the specified schema for validating JSON?
  • Should we be using the schema for automated testing validation?
  • Should be be using the "enum" construct (supported by draft-03)?

Domain Identifiers

• How should concepts like Device or Addressable be uniquely identified?  Currently using unique name strings
• How should persistent store identifiers be related/not related to these identifiers.

Service Identifiers

• How should micro services be identified uniquely and how should that relate to the address or host of the address?

Closed Discussion Items

• Copyright header – stays the same until LF has an alternative header and tool to provide
• Enums & JSON – use strings in place of any language specific enums or Iota in JSON messages and serialize/deserialize as necessary in your language of choice.

Go Lang Discussion Items

• Go Lang version supported will be 1.9
• Repos names will be in the form of <service>-<language>.  For example core-domain-go
• Work group leads can make the determination about repositories for their services.  The applications work group, for example, has decided that all Go export code/micro services will go in one repository (export-go).  The decisions are passed to work group leads (working with their development leads) and on a language by language basis that best suits the needs of development and community.
• Glide will be our vendoring tool of choice