Defining Service and Resources

[matt-beanland]

Diffo providers should be able to define their services and resources declaratively.

We can imagine that a DslAccess service could be declared using a spark DSL as follows:

defmodule Diffo.Access.DslAccess do
  use Diffo.Provider.Service

  specification do
    id: "da9b207a-26c3-451d-8abd-0640c6349979"
    name: "DSL Access Service"
    major_version: 1
  end

   features do
     feature :dynamic_line_management, is_enabled?: true do
       characteristics do
         characteristic :constraints, type: Diffo.Access.Constraints
       end
     end
   end

  characteristics do
    characteristic :dslam, type: Diffo.Access.Dslam
    characteristic :aggregate_interface, type: Diffo.Access.AggregateInterface
    characteristic :circuit, type: Diffo.Access.Circuit
    characteristic :line, type: Diffo.Access.Line
  end
end

This DSL only specifies the structure of initial service instances created using a create action. We'd probably expose an endpoint to create instances of this service specifically, the create action would upsert the specification instance and relate it to the instance, so would succeed if the specification instance didn't yet exist. The feature and characteristics instances would be created and related to the new instance.

It could be extended for other structural aspects (parties, places, relationships, states, etc) and also for behaviours.

Characteristics here are named and have their value typed, types are generally typed_struct (created with another DSL). They could also be embedded resources which are more flexible as they can support calculations. We likely would need our behaviours to derive fields within the characteristic value structs using policy/values from elsewhere.

Also we would need separate behaviours for actual and expected, since expected derives configuration from intent and actual discovers intent from configuration.

[matt-beanland]

I think the way forward here is using Spark.Dsl.Fragment. What we will do is make the existing Diffo.Provider.Instance the BaseInstance fragment. We want to be able to have the existing Diffo.Provider.Instance API and tests continue to work with Instance, which will merely use the BaseInstance and defdelgate functions needed on the module by the jason dsl.

[matt-beanland]

Each user of Diffo should be able to use the generic Provider Domain API, as well as customise their own Domain API. In their domain they will define a service/resource. Say Diffo.Access.DslAccess.Instance - ash_neo4j's default label comes from the short module name, so needs to be Instance in this case, matching the label of the BaseInstance (which wasn't defined). Interesting this allows access by either Diffo.Provider.Instance or Diffo.Access.DslAccess.Instance, with the resource retrieved from the same data using the appropriate structure.

The base instance includes the dsl extension for the Diffo.Provider.BaseInstance which includes the Diffo.Provider.Instance.Extension which can be used buy the user to customise their own services.

Ideally we'd want the service/resource to include additional labels for both the service.