Pull Request - updated documentation and diagrams into dev

README.md

@@ -1,55 +1,194 @@
-# RestTestbed
-Testbed for ensuring that CTS RESTful interactions are complete and correct before integrating into the [NIST Common Transactive Services Agents Project](https://github.com/EnergyMashupLab/NIST-CTS-Agents).
+<h1 align="center">
+  <br>
+  <a href="http://www.theenergymashuplab.org/"><img src="http://static1.squarespace.com/static/53dd102ae4b0474fbf8ce365/t/55da1f5de4b07faafab2518c/1440358237526/EML+Logo+20150816+No+Text.png?format=1500w" alt="Energy Mashup Lab" width="200"></a>
+  <br>
+  NIST CTS Agents
+  <br>
+</h1>
+
+<p align="center">
+  <a href="#background">Background</a> •
+  <a href="#tech-desc">Technical Description</a> •
+  <a href="docs/README.md">Documentation</a> •
+  <a href="#authors">Authors</a> •
+  <a href="#license">License</a>
+</p>
+
+We invite participation in an open source project to create Actors[<sup>1</sup>](#fn1) for
+edge-based self-optimization of power distribution systems. This project is named
+NIST-CTS-Agents because it is an implementation of an agent-based transactive energy 
+market using the Common Transactive Services defined during the NIST Transactive 
+Energy Challenge. 
+
+<a id="background"></a>Background
+----------
 
-Types and type names (Java class declarations and names) do not precisely match those in NIST-CTS-Agents as they were developed in parallel, although both are derived from the standards described below.
-The rationalizing of types is an active task in the NIST-CTS-Agents project.
+Transactive Resource Management (TRM) enables Actors representing systems that
+use or supply a resource—any commodity whose value is defined by time and
+delivery location— to coordinate behaviors without the need for central control.
+TRM-based systems engage Actors in markets to manage supply and demand of a
+resource over time. Markets enable emergent behavior—new behavior related to
+actors and relationships as actors meet their internal needs.
+
+TRM systems are highly resilient, as Actors can join or leave the system without
+additional integration. TRM applications include managing power distribution,
+smart power grids, smart water, bandwidth sharing, placement of web and social
+media ads, and wastewater management.
+
+When the resource is electric power, TRM is called Transactive Energy (TE).
+Transactive Energy is already used to manage the bulk power grid. TE is
+considered essential to developing new resilient power grids, to transform
+legacy power grids, and to build resource-constrained grids.
+
+Actor-based architectures enable hyper-scalable applications that are easy to
+design, build, and maintain. Actor Interactions are limited to defined messages,
+so they support diversity of participants and technologies. Market transaction
+messages create self-optimizing systems of suppliers, consumers, and
+distribution.
+
+This project will develop Transactive Energy User Agents (TEUA) interacting through
+Markets. We will define interfaces between an energy system and the Actor (TEUA)
+that represents it. TEUAs will interact with a Market Agent/Actor (MA) that
+encapsulates market behavior. While the project uses a Bilateral Market model,
+the Market Agent will incorporate a Market Modular Interface to support other
+market models.
+
+Bilateral Market is a classification; examples of bilateral markets include Double Auction and Order Book.
+
+To see a description of the components that make up this project, look under the 
+subfolders of the [source directory](complete/src) as well as the project wiki (in progress) and [documentation folder](complete/docs).
+
+Results
+-------
+
+We expect that this project will make it easier for communities, facility
+owners, and device makers to apply TE. For example, NIST looks to use these agents and actors in
+simulations to model TE for regulators and legislators. A complete
+implementation of the Common Transactive Services will be highly visible and
+widely used.
 
-The code can be exercised using tools such as cURL and [Postman](https://www.postman.com/). Documentation of the RESTful APIs is pending.
+Standards Used
+--------------
 
-Based On
-------------
+The project uses standards including
 
-The code skeleton for a simple Greeting RESTful service was taken from [The Spring Guides Building a RESTful Web Service](https://spring.io/guides/gs/rest-service/) and its [code repository](https://github.com/spring-guides/gs-rest-service). The code is provided under the Apache 2.0 License.
+-   The TEMIX profile of [OASIS Energy
+    Interoperation](https://docs.oasis-open.org/energyinterop/ei/v1.0/os/).
+    Energy Interoperation is the profile base of [OpenADR 2] standardized as
+    [IEC 62746-10-1] (<https://webstore.iec.ch/publication/26267>)
 
-How to Use
+-   Informative UML models for Energy Interoperation/CTS payloads as shown in
+    the EI Standard
+
+-   ISO 17800 Facility Smart Grid Information Model
+    (<https://www.iso.org/standard/71547.html> )
+
+-   Adapter methods for integrating with Independent System Operator Wholesale
+    Markets and other energy markets are based on [IEC 62746-10-3:2018]
+    (<https://webstore.iec.ch/publication/59771>)
+
+<a id="tech-desc"></a>Technical Description
+---------------------
+
+The NIST-CTS Project is a standards-based implementation of the Common
+Transactive Services using a Transactive Energy User Agenta (TEUA), a Local Market Agent (LMA) that facilitiates interaction between users
+and local markets through a Local Market Engine (LME).
+The Implementation Architecture Diagram shows terminology and relationships within the implementation.![Architecture Diagram](complete/docs/pictures/ArchitectureCts20200720.png) 
+
+The client/building/supervisory controller view is ![CLient View drawing](complete/docs/pictures/ClientViewCts20200720.png)
+
+The project has a number of components and information in a number of subfolders under [../dev](../dev ).
+
+-   **Markets** including
+
+    -   The Local Market Engine (LME), the agent that fronts the market implementation including the matching engine that matches buy and sell tenders
+
+    -   A bilateral market
+
+    -   (future) Additional plug-in markets and documentation
+
+-   **Local Market Agent** (LMA) which interacts with the local market and with Transactive
+    Energy User Agents and External Market Adapters using CTS. Functions include    
+    -   Market Position Management (see note)
+
+    -   The Ledger, the record of cleared (not pending) transactions (see note)
+
+    -   Hook points for price Adjustments, enabling market economics experiments
+
+    -   Uses CTS to connect to the LME and TEUAs
+
+    -   Links to external markets via the External Market Adapter (EMA) which specializes the TEUA
+
+-   **External Market Adapter** (EMA), a specialization of the TEUA, interacts with the Local Market Agent and a single external market. 
+Functions include
+
+    -   Price Adjustment hooks, enabling market economics experiments and presentation of markup on wholesale prices
+
+    -  Uses CTS to connect to the LMA and indirectly to other actors
+
+
+-   **Transactive Energy [User] Agent** (TEUA) which interacts with the MA and provides
+    integration capabilities for device and facility management
+
+    -   Implements CTS connections
+
+    -   Integrates with the Client/Supervisory Controller (SC)
+
+    -   With the LMA maintains the Ledger, the record of cleared (not pending) transactions (see note)
+
+    -   Provides information on committed market positions to the Client/SC (see note)
+
+-   **Utilities** include
+
+    -   Logging (traces) and input for live and simulation meter and other data
+
+    -   Programs to build configuration files for the market client and system
+
+Notes: 
+A ledger is a list in time order of committed transactions. A position is cumulative committed transactions. A trace of messages includes transactions proposed but never cleared. Ledgers are saved to a file or possibly sent over a network connection as the design matures.
+
+The Position Manager tracks completed (cleared) transactions (also contained in a ledger) to determine committed market positions.
+Market position information is typically needed by the teua (on behalf of the sc).
+
+The TEUA in turn can use market position to determine the difference between committed position and projected needs. The SC may then transact only for what is needed to align current committed position with projected needs, tendering to buy or sell as appropriate.
+
+All transactions and clearing flow through the LMA which updates the Market Position database for use by the TEUA.
+
+Built With
 ----------
-The code builds and runs in Spring Tool Suite 4; it typically would be run on the embedded Tomcat server.
 
-The files in ![URIs-and-payloads](./URIs-and-payloads) describe
+Agile programming and architecture are used.
 
-- POST operations to the actors in [NIST-CTS-Agents](https://github.com/EnergyMashupLab/NIST-CTS-Agents)
-- JSON payloads for the POST operations that exercise the services
-- URIs for the various GET operations that do not require parameters or a RequestBody. 
+Source code and builds are managed using Github, Maven, Java 8, JUnit, Apache Log4j2, Spring and Spring Boot.
 
-The random payload generating GET operations are in the RestController files **GreetingController.java** 
+Building and Running
+-------
 
-Other GET operations (.../party) and POST operations and forwarding are in the LMA, LME, and TEUA RestController Java files.
+See the [documentation](docs/README.md) directory and the project wiki (in process) for the tooling and development environment.
 
-Documentation is pending, but the comments in the LMA, LME, and TEUA RestController files give the RequestBody and ResponseBody types which are also in this repository.
+<a id="authors"></a>Authors
+-------
 
-Standards Used
---------------
+-   **William Cox** - *Architecture* - [Cox Software Architects
+    LLC](http://coxsoftwarearchitects.com/)
 
-The Common Transactive Services Project uses standards including
+-   **Toby Considine –** *Architecture* – [TC9 Inc](http://www.tc9.com/)
 
--   The [Common Transactive Services](https://github.com/EnergyMashupLab/TransactiveEnergyChallenge) - See CommonTransactiveServices
-    in that repository. These services were defined in the NIST Transactive Energy Challenge as a universal means of interacting
-    with markets, and specifically markets for energy. The Common Transactive Services are shown in that report to communicate
-    both ways with every known energy market implementation.
+See also the list of [contributors] who have contributed to this project.
 
--   The TEMIX profile of [OASIS Energy
-    Interoperation](https://docs.oasis-open.org/energyinterop/ei/v1.0/os/).
-    Energy Interoperation is the profile base of [OpenADR 2] standardized as
-    [IEC 62746-10-1] (https://webstore.iec.ch/publication/26267)
+<a id="license"></a>License
+-------
 
--   Informative UML models for Energy Interoperation/CTS payloads as shown in
-    the EI Standard
+This project is licensed under the Apache 2.0 License, and is Copyright 2019-2020 The Energy Mashup Lab.
 
--   [ISO 17800 Facility Smart Grid Information Model](https://www.iso.org/standard/71547.html)
+For incoming (contributed) licenses see https://github.com/EnergyMashupLab/EML_Licenses
 
--   Adapter methods for integrating with Independent System Operator Wholesale
-    Markets and other energy markets are based on [IEC 62746-10-3:2018](https://webstore.iec.ch/publication/59771)
+Acknowledgments
+---------------
+
+Footnotes
+---------------
+
+<a class="anchor" id="fn1">1)</a> The difference between Actors and Agents can be a fine one. The actor model of concurrent computation  treats "actor" as the universal primitive of concurrent computation. An actor is an intelligent resource that has the capacity to initiate, manage, and/or control activities of given types. In response to a message it receives, an actor can: make local decisions, create more actors, send more messages, and determine how to respond to the next message received. An Agent *may* be a particular instantiation of an Actor. Some distinguish the two by whether systems can share direct access to external data--to them, an Agent can and an Actor cannot. Perhaps the Market Matching Engine is an Actor and a component of the the Local Market which is an Agent. Similary, the TEUA may be an Actor which with the SC comprises the User Agent. 
+This project does not wish to delve into these semantics, and generally uses the terms interchangeably.
 
-License
----------
-Provided under the Apache 2.0 License; please see LICENSE in top level for details.

complete/docs/lma_pseudocode.md

@@ -1,36 +1,18 @@
 Pseudocode for LMA Main Loop
 =======================
-Synthetic via RESTful POST and GET
 
-### Logical Description 
+### Logical Description - Parallel Activities
 <pre><code>
-    1. Receive CreateTender service request (from a TEUA) <i>log in transport message list</i><br />
-    2. Respond to the TEUA with a CreatedTender <i>log</i><br />
-    3. Adapt and send a [rewritten] CreateTender to LME <i>log in transport message list</i><br />
-    4. When LME matches and clears it will send LMA back a CreateTransaction <i>log and ledger, 
-        also log in transport message list</i><br />
-    5. Send CreatedTransaction back to LME <i>log and ledger</i><br />
-    6. Send [rewritten] CreateTransaction to requestion UA <i>log and ledger for UA</i><br />
-    7. Receive CreatedTransaction from TEUA <i>log and ledger; update in ledger to note acknowledgment</i>
+    1. Receive an EiCreateTender message (from a TEUA)><br />
+    2. Respond to the TEUA with EiCreatedTender<br />
+    3. Forward a [possibly rewritten] EiCreateTender to LME <br />
+    4. When LME matches and clears aynchronously it will send EiCreateTransaction back to the LMA. Add transaction quantity and buy/sell to the positiion for both parties<br />
+    5. Respond to LME with EiCreatedTransaction<br />
+    6. Send [possibly rewritten] EiCreateTransaction to requesting TEUA (mapping PartyId and CounterPartyId to the correct TEUA id) <br />
+    7. Receive EiCreatedTransaction from TEUA and forward to LME
 </code></pre><br />
 
-### POST Methods 
-<pre><code>
-    1. Post action <i>(request from SC, CreateTender for full requirements for a time period)</i>
-      * Query position
-      * Compare, subtract, and POST remaining requirements as CreateTender to LMA. <i>log</i>
-      * RETURN/POST CreatedTender message to SC
-    2. POST action <i>(request from LMA, CreatedTender)</i>
-      * Log
-      * Inform SC <i>(callback or POST)</i>
-    3. POST action <i> (request from LMA, CreateTransaction for cleared transaction)</i>
-      * Enter in my Ledger
-      * Add to my position <i> should already be in my position stored at LMA</i>
-      * RETURN/POST CreatedTransaction to LMA 
-</code></pre><br />
-
-#### Notes 
-
-    1. Hook in LMA POST method for possible rewrite. Only the hook so can still experiment with rewrite rules 
+### Details of POST Requests
 
+See [separate URI Structure and Payloads](uri_structure.md). 
 

complete/docs/lme_pseudocode.md

@@ -1,42 +1,19 @@
 Pseudocode for LME Main Loop
 =======================
-Synthetic via RESTful POST and GET
 
-Uses only generated libraries from Parity, specifically parity.libraries.book and .market, and consumes classes from util. 
+Integration with the [ParityTrading](https://github.com/paritytrading/parity) market is done through hooks inserted in the Parity *Terminal Client*, to which the LME is connected with sockets.
 
-### Logical Description 
+### Logical Description - Parallel Actvities
 <pre><code>
-  1. Receive a CreateTender service request from LMA <i>log in transport message list</i><br />
-  2. Respond to the LMA with a CreatedTender <i>log</i><br />
-  3. Enter the Tender in the Order Book<br />
-  4. When tenders match and clear send LMA <i>a CreateTransaction log and ledger also log in 
-      transport message list</i><br />
-  5. Receive CreatedTransaction from LMA <i>log and ledger</i><br />
-  6. LMA will send CreateTransaction to requestiing UA
-</code></pre><br />
+  1. Receive  EiCreateTender service request from LMA <br />
+  2. Respond to the LMA with EiCreatedTender <br />
+  3. Send MarketCreateTender to the Parity Termina Client which converts to a Parity order and enters it in the Order Book<br />
+  4. When Parity orders match and clear the LME receives a message, and sends EiCreateTransaction to the LMA<br />
+  5. LMA will send CreateTransaction to requestiing TEUA
+  6. Receive EiCreatedTransaction from LMA<br />
 
-### POST Methods 
-<pre><code>
-  1. POST action CreateTender <i>(request from LMA, tender for UA net requirements for a time period)</i>
-    * book.market.add(orderID, details) which adds to bid/ask data structures
-      as relevant
-    * RETURN/POST CreatedTender messaged to LMA.
-  2. Spontaneous calls from internal MarketListener on match
-    * Accept callback
-    * market.execute(orderID, quantity, price) which clears from bid/ask
-      data structures as relevant
-    * POST CreateTransaction to LMA 
-  3. POST action for CancelTender <i>(request from LMA)</i>
-    * market.delete(orderID)
-    * RETURN/POST CanceledTender to LMA
-  4. POST CreatedTransaction
-    * Log
 </code></pre><br />
 
-#### Notes
-
-  1. The CTS IDs (inherited from idType in EI) should be used in the OrderBook
-     (the Parity ID is a long)
+### Details of POST Requests
 
-  2. CTS does not rewrite tenders in place, 
-     so CancelTender == market.delete (Parity Cancel adjusts quantity)
+See [separate URI Structure and Payloads](uri_structure.md). 

complete/docs/position_manager.md

@@ -1,20 +1,17 @@
 Position Manager
 ======================================
 
-## Position Manager Payload
-Stored in org.theenergymashuplab.cts.controller.payloads package, in this class all the rest call to access position manager is stored. 
+## Position Manager 
+See packages org.theenergymashuplab.cts.controller.payloads, .model, .dao, and .repository for details.
 
-Following describes all its api.
-1. createPosition : Will add position into the table.
-2. getPositionHistoryToId : Fetch position from table with respect to the sellerId.
-3. getPositionHistoryFromId : Fetch position from table with respect to the buyerId.
-4. getPositionHistory : Fetch position from table with respect to the count.
-5. getStatus : Fetch status from table given the id of respective position id.
+The Position Manager uses JPA to store its information. The REST API for the PositionManager RestController is
+
+1. POST: /position/{positionParty}/add adds a position for a particular Party and time interval, creating a database row if not present. 
+2. GET: /position/{positionParty}/getPosition retrieves the position for a specific Party and time interval
 
 ## Position Manager Model
-Stored in org.theenergymashuplab.cts.model package, it represents the database table.
+PositionManagerModel represents the database table.
 
 ## Position Repository 
-Stored in org.theenergymashuplab.cts.repository package, in this class all the native queries are stored.
-
+PositionRepository contains all the native SQL queries.
 

complete/docs/teua_pseudocode.md

@@ -1,39 +1,17 @@
 Pseudocode for TEUA Main Loop
 =======================
-Synthetic via RESTful POST and GET
 
-### Logical Description 
-<pre><code>
-    1. Receive a service request to buy/sell energy (from the SC) and net against position for that time period 
-        <i>log in transport message list for debugging</i><br />
-    2. Build net CreateTender payload <i>log with all fields of the Tender (party, counterparty, Tender, etc)</i><br />
-    3. Send net CreateTender to LMA <i>(log in transport message list)</i><br />
-    4. Wait to receive a CreatedTender <i>(log receipt)</i> and later a CreateTransaction <i>(log and ledger updates)</i><br />
-    5. Update my position <i>(in LMA)</i><br />
-    6. Respond to the CreateTransaction with a CreatedTransaction <i>(log)</i>
-</code></pre><br />
+### Logical Description - Parallel Activites - User Agent for Client/Building/SC
 
-### POST Methods 
 <pre><code>
-    1. POST action CreateTender <i>(request from SC, for full requirements for a time period)</i>
-      * Query position
-      * Compare, subtract, and POST remaining requirements as CreateTender to LMA <i>(log)</i>
-      * Return CreatedTender message or indication to SC <i>(CTS or callback/return on simple method invocation or POST)</i>
-    2. POST action CreatedTender <i>(from LMA)</i>
-      * Log
-      * Respond to SC <i>(callback or POST)</i>
-    3. POST action CreateTransaction <i>(request from LMA, CreateTransaction for cleared transaction)</i>
-      * Enter in my logical Ledger <i>(correct to place in LMA ledger for query, logically specific to this TEUA)</i>
-      * Add to my postion <i>should already be in my position as stored at LMA</i>
-      * POST CreatedTransaction to LMA
+    1. Receive a service request *ClientCreateTender* to buy/sell energy (from the Client) and optionally net against position for that time period<br />
+    2. Build *EiCreateTender* payload <br />
+    3. Send *EiCreateTender* to LMA<br />
+    4. Wait to receive *EiCreatedTender* <br />
+    5. Receive *EiCreateTransaction* from LME, construct *ClientCreateTransaction* and send to Client<br />
+    6. Respond to the *EiCreateTransaction* with *EiCreatedTransaction*
 </code></pre><br />
 
-#### Notes 
-
-    1. The SC might invoke a method OR use a RESTful web service; the latter is possible if in the 
-       same code space/JVM as the TEUA.
+### Details of POST Requests
 
-    2. Position manger is attached to LMA, not to each UA.
-
-    3. The position manager can be a seperate RESTful service. It needs to
-       e queried by other than the LMA. 
+See [separate URI Structure and Payloads](uri_structure.md). 

complete/docs/uri_structure.md

@@ -1,41 +1,55 @@
-URI Structure for REST service operations
+Common Transactive Services URI Structure and Payloads for REST service operations
 =====================================
 POST operations have a RequestBody (the message that is POSTed to the listed URI) and a ResponseBody (the message body that is returned to the actor doing the POST).
-This provides the standard Energy Interoperation messages - a POST RequestBody contains an EiCreateTender, while the POST ResponseBody contains the correlated EiCreatedTender.
+We use this to provide the standard Energy Interoperation messages - for example, for creating a tender (offer to buy or sell) the POST RequestBody contains an EiCreateTender, while the POST ResponseBody contains the correlated EiCreatedTender.
 
-For this project the principal authors of the base standards flattened the type hierarchy for only the product (energy) and information elements we use. This approach maintains standards conformance and allows for
+For this project principal authors of the base standards flattened the type hierarchy for only the product (energy) and information elements we use. This approach maintains standards conformance and allows for
 * A simpler to use and understand type system 
 * Simpler Java class definitions for standard payloads
 * A conformance statement at the end of the project
 
-NIST-CTS-Agents uses JSON rather than XML for message payloads. The project uses Jefferson serialization and deserialization between Java and JSON.
-
-### LMA 
-````/lma
-	/createTender           POST	@ResponseBody is an EiCreatedTender object
-	/createTransaction      POST	@ResponseBody is an EiCreatedTransaction object
-	/cancelTender           POST	@ResponseBody is an EiCanceledTender object
-	/party	                GET 	@ResponseBody is an ActorId containing actor’s partyId
-````
-### LME 
-````/lme
-	/createTender		POST	@ResponseBody is an EiCreatedTender object
-	/cancelTender		POST	@ResponseBody is an EiCanceledTender object
-	/party			GET 	@ResponseBody is an ActorId containing actor’s partyId
-````
-
-### TEUA and EMA
-````
-/teua — {id - sequential integer assigned on creation}
- 	/{id}/CreateTransaction	        POST	@ResponseBody is an EiCreatedTransaction object
-	/{id}/CreateTender		POST	@ResponseBody is an EiCreatedTender object. For user entity integration
-	/{id}/party			GET 	@ResponseBody is an ActorId containing actor’s partyId
-````
-#### Terminology 
-LMA - Local Market Agent
-
-LME - Local Market Engine 
-
-TEUA - Transactive Energy User Agent 
-
-Refer to the [Architecture Diagram](https://github.com/EnergyMashupLab/NIST-CTS-Agents/blob/master/Architecture.png) for more detail on the RESTcontrollers.
+We use JSON rather than XML for message payloads with Jackson serialization and deserialization between Java and JSON.\
+
+#### URI and Operation Tables
+Note that the {id} in URI determines the transport end point. ActorId is independent of {id}*.
+
+Certain payloads are created in the market integration code; in the current release they are in parity-client/CtsBridge.java and associated code files.
+
+Local Market Agent Services
+| URI	| Operation | RequestBody	| ResponseBody	|
+| ---		| ---		| ---	| --- |
+|/lma/createTender	|	POST|	EiCreateTender|	EiCreatedTender
+|/lma/createTransaction	|	POST|	EiCreateTransaction|	EiCreatedTransaction
+|/lma/cancelTender	|	POST|	EiCancelTender|	EiCanceledTender
+|/lma/party	|GET 		|  |	ActorId
+
+Local Market Engine Services
+| URI	| Operation | RequestBody	| ResponseBody	|
+| ---		| ---		| ---	| --- |
+|/lme/createTender	| POST	| EiCreateTender	|	EiCreatedTender
+|/lme/cancelTender	| POST	| EiCancelTender	|	EiCanceledTender
+|/lme/party		| GET 	|			|	ActorId
+
+Transactive Energy User Agent Services
+| URI	| Operation | RequestBody	| ResponseBody	|
+| ---		| ---		| ---	| --- |
+|/teua/{id}/createTransaction	| POST	| EiCreateTransaction	| EiCreatedTransaction
+|/teua/{id}/clientCreateTender	| POST	| ClientCreateTender	| ClientCreatedTender
+|/teua/{id}/party	| GET	|	| ActorId
+
+Client Integration Services
+| URI	| Operation | RequestBody	| ResponseBody	|
+| ---		| ---		| ---	| --- |
+|/client/{id}/clientCreateTransaction	| POST	| ClientCreateTransaction	| CientCreatedTransaction
+|/client/{id}/clientCreateTender	| POST	| ClientCreateTender	| ClientCreatedTender
+
+NOTE: */client/{id}/clientCreateTender passes through the client to /teua/{id}/clientCreateTender as a test driver convenience*
+
+Market Integration Services (Payload definition only; sockets used for send and receive)
+| URI	| Operation | RequestBody	| ResponseBody	|
+| ---		| ---		| ---	| --- |
+|Receive match/transaction from Market to LME	| Socket	| MarketCreateTransaction	| MarketCreatedTransaction
+|Send tender from LME to Market	| Socket	| MarketCreateTender	| MarketCreatedTender
+
+The [Architecture Diagram](pictures/Architecture20200115.png) shows the relationships of the Actors.
+

complete/src/main/java/org/theenergymashuplab/cts/GreetingController.java

@@ -28,7 +28,7 @@
 
 
 /*
- * Carryover from previous investigatory code. 
+ * NOT USED
  * TODO Candidate for deletion in future release
  */
 @RestController