In the context of the hms_sys system, the Artisan Gateway has been only loosely defined thus far – it's been described as acting as a central contact point for communication between Artisans and the Central Office, especially with respect to the Product and Order objects – what its role is, in effect. The specifics of how it works, and when, haven't really been touched upon, though at least some of the latter are probably very obvious, following a simple rule that might be stated as changes made (by whomever) need to propagate to all relevant parties as soon as is feasible. Those changes are largely dependent on who is making them. At a minimum, the following processes feel likely:

• Artisans can create new Product data
• Artisans can update current Product data
• Artisans can delete a Product outright
• Central Office staff can mark a Product as available – which is just a specialized variant of a Product update process
• Central Office staff can also make content changes to Products – also an update variant – with some constraints on what can be altered
• Customer end users can indirectly create Order objects, which need to propagate out to Artisans in some fashion
• Artisans can update Orders as part of the process of fulfilling them

All of these processes are variants of CRUD operations on the Product and/or Order objects, and will probably not need much more functionality than is already provided by the _create or _update methods of the related classes within each subsystem. They should cover most, perhaps all, of how the data changes are actually stored.

The transmission of those data changes, no matter what the timing or protocol ends up looking like, has some common factors as well, with a process that will need to handle the role-specific variations of the following steps:

• A data change (create, update, or delete) is made locally, in one of the user-level applications
• The data change is validated, to assure that the data is well formed and conforms to data-structure requirements
• The data change is stored locally (if applicable)
• The data change is serialized and transmitted to the Artisan Gateway service, where whatever actions need to be undertaken are executed

These steps do not address the possibility of conflicting changes, such as an Artisan and someone in the Central Office making different changes to the same data in the same data-change timeframe. A strategy for dealing with that possibility may not even be necessary, depending on the specific data-change business rules in play, but will have to be examined as well.

That leaves only the decision about the transmission method itself to be made. Since the individual users that will be making changes to data are not expected to be in the same physical location, we need a network-transmission protocol of some sort – a web service or message-queue-based process, as discussed in Chapter 15, Anatomy of a Service. A web service, if it were written from scratch, would probably be a significantly larger undertaking, potentially requiring code to handle authentication, authorization, and processes for handling specific HTTP methods and tying them to specific CRUD operations against individual data object types. There's enough complexity between those alone to warrant looking at an existing service-capable framework, such as Flask or Django, rather than writing (and having to test) all of the relevant code.

Given that the system only needs to be concerned with the seven actions identified earlier (Artisan: create, update, or delete Products, and so on), it feels simpler to write those seven functions, and allow messages in a queue-based protocol to simply call them when necessary. The potential concerns around authentication and authorization can be mitigated significantly by assigning each Artisan its own distinct queue, and perhaps signing each message originating with an Artisan. Between those two approaches, an Artisan's identity can be determined simply by the fact that a message is coming in from a given queue that's associated with them. Coupling that with a signature on each message, as long as it can be generated by the Artisan's application and verified by the Artisan Gateway service without transmitting any secret data with the message, provides a reasonably robust authentication mechanism. Authorization concerns in this context are nearly trivial – any given channel, given that it can be associated with a user type, or even a specific user, can simply be allowed access to (and thus execution of) the operations that are relevant to that user or type only.

At a high level, the data flows for Artisan/Product operations, no matter which transmission mechanism is selected, would look like this:

Where:

• The various messages (Create Product, Update Product, and Delete Product) with their respective {payload} data (or a {product_id} for deletion operations) are created by the local Artisan Application, transmitted to the Artisan Gateway service
• Those messages are read, validated, and used to determine which service method (artisan_create_product, and so on) should be called
• The relevant method deals with whatever data storage is needed in the Artisan Gateway Datastore during execution

Similar data flows would exist for all of the operations that Central Office users could execute against Product objects, and for Artisan and Order object interactions, at a minimum. In addition, there may well be related operations that need to be made available for more specific data-object operations in more specific Central Office roles. The Central Office staff will need to be able to manage Artisan objects, at a minimum, and maybe Order objects as well.