Modeling Services (Deployments)

[elf-pavlik]

In current draft of v3 we see (excerpt)

shape :ServiceShape -> ex:Service ;
	ex:serviceBackend IRI %
		sh:name "service backend"@en ;
		sh:description "name of server software (e.g. ESS for inrupt.com)"
	% .
	ex:serviceFrontend IRI %
		sh:name "service frontend"@en ;
		sh:description "name of server frontend (e.g. SolidOS or Penny)"
	% .
}

In #18 (comment) I pointed out:

I would also keep in mind, that CSS can be deployed with only storage enabled, only IdP enabled or both enabled. So we may want to distinguish which products classes as implemented by a specific software bundle, and for specific deployment which of those implemented product classes are actually used.
There can be also deployments which for example combine storage running on php-solid-server and IdP running on Keycloak or CSS IdP. For end user such hybrid stack deployment would be a service equivalent to homogeneous stack like CSS with both storage and IdP enabled.

Since service can provide combination of different classes of products, each one running a different implementation, I consider the shape above oversimplified. I created a video for TPAC 2024 giving an overview of different classes of products and how they can be implemented separately, sometimes service would need some custom glue since interop between many classes of products is currently left out of scope and left up to implementations / deployments.

EDIT For example https://sai.js.org/ has implementation of SAI Authorization Agent, which comes with a frontend but that frontend uses bespoke RPC API and someone could write their own fronted. This implementation already uses components.js and I'm working on possible configuration where two product classes: SAI Authorization Agent and Solid-OIDC Provider are combined into single service to improve UX. I might also add to that frontend CSS pod management using CSS bespoke REST API https://communitysolidserver.github.io/CommunitySolidServer/latest/usage/account/json-api/ and disable any HTML templates from CSS all together.

I would prefer to prioritize simpler things like #18 and #19 before we dive too deep into describing more complex deployments. We can still use this issue to keep track of relevant things for when start crossing this bridge.

[jeff-zucker]

I would prefer to prioritize simpler things like #18 and #19 before we dive too deep into describing more complex deployments. We can still use this issue to keep track of relevant things for when start crossing this bridge.

Agree, I used serviceFrontEnd and serviceBackend because they are less complex and more directly relevant to users. Selecting them for v2 was not an indication I think they are the only connections between Services and other software. So yes, let's leave this as a place marker and come back to it.

Since service can provide combination of different classes of products,

While not an adequate handling, that is partially addressed in this part of the current SHACL: https://github.com/solid/catalog/blob/main/v3/catalog-shacl.shce#L101 which reads

shape :ProductShape -> ex:Product ;
...
	ex:subType [1..1] in=[con:ServerPlugin ...] %
		sh:name "subtype"
	% .
	ex:partOf xsd:string %
		sh:name "part of" ;
		sh:description "for ServerPlugin/Component, name of server; for other product, name of software product is part of"
	% .

SAI Authorization Agent and Solid-OIDC Provider are combined into single service

Cool. Using the current SHACL, would this true?

ElfService serviceBackend ElfOIDCServer.
ElfAuthAgent partOf ElfOIDCServer.

[elf-pavlik]

Agree, I used serviceFrontEnd and serviceBackend because they are less complex and more directly relevant to users.

I think CSS (and possibly most other implementations of storage and/or IdP) has another interesting aspect. Currently Solid Protocol says nothing about account management so storage servers and/or IdP provide their own frontend for that functionality. So any deployments could add them as both front and backend.

Cool. Using the current SHACL, would this true?

ex:partOf can come useful, let's keep it in mind once we try to model various types of deployments.

There's also topic of how WebIDs are hosted, could be handled by storage server, by IdP server or something completely separate from those two.

---

I just noticed that with sloppy case IdP (Identity Provider) could be easily confused with LDP (Linked Data Platform) 🤦

[jeff-zucker]

Since service can provide combination of different classes of products,

But if this is what is going on :

ElfService serviceBackend ElfOIDCServer.
ElfAuthAgent partOf ElfOIDCServer.

Then your comments relate to Servers, not Services. Also, the Product Class Sai Agent attaches to the Product ElgAuthAgent, not to either the Server or Service. Right?

[jeff-zucker]

To flesh out the above question a bit, ignoring for now serviceFrontend. Where would you put the ProductClass triples? And would there be any inference? Forexample if ElfAuthAgent conformsTo AA ProductClass, can we infer that ElfServer does also and what about ElfService, do we infer that too? Or does each of the three records need to explictly say they confromTo AA?

ElfService
  a Service ; 
  subType IdentityProvider ; 
  serviceBackend ElfServer .

ElfServer
  a Product ;
  subType IdentityServer ; 
  dependency ElfAuthAgent ;
  serviceBackendOf ElfService . # inferred from ElfService record

ElfAuthAgent
  a Product ;
  subType SoftwareLibrary ;
  dependencyOf ElfServer . # inferred from ElfServer record .

[jeff-zucker]

Or would the conformsTo AA only apply to ElfAuthAgent and it would be invalid to say that ElfService conforms to AA?

[elf-pavlik]

I think better example would be a service based on php-solid-server, Keycloak and possibly more fully distinct software.
Your approach seems to try to define a software bundle/stack and link the service to that bundle/stack.

This could be an approach, but if such a bundle/stack is only used in a single deployment and it never defined outside of this deployment, I would be hesitant to define it as a bundle/stack outside of that deployment, I could be wrong.

So your last snippet would look more or less, with classes of product and conformsTo which has clearer semantic than generic subType

FooService
  a Service ; 
  subType PodProvider ; 
  serviceBackend BespokeServerStack .

BespokeServerStack
  a Product ;
  subType PodServer ; 
  hasParts Keycloak, PHPSolidServer, SaiJsAuthorizationAgent ;
  serviceBackendOf FooService . # inferred from FooService record

Keycloak
  a Product ;
  subType SolidOIDCProvider ;
  conformsTo: SolidOIDcProvider ;
  language: Java ;
  partOf BespokeServerStack . 

PHPSolidServer
  a Product ;
  subType SolidStorage ;
  conformsTo: SolidStorage ;
  language: PHP ;
  partOf BespokeServerStack . 

SaiJsAuthorizationAgent
  a Product ;
  subType SAIAuthorizationAgent ;
  conformsTo: SAIAuthorizationAgent ;
  language: Typescript ;
  partOf BespokeServerStack . 

Since such deployment requires implementation specific glue, there could be another bundle/stack that has the same 3 components but glues them together differently

YetAnotherBespokeServerStack
  a Product ;
  subType PodServer ; 
  hasParts Keycloak, PHPSolidServer, SaiJsAuthorizationAgent ;
  serviceBackendOf BarService .

I guess we could model software stacks/bundles even if it is only used by a single deployment. I don't fully understand the model you had in mind in your original snippet but probably my version of the snippet doesn't exactly fit into it.

if you see it a priority I'm happy to keep providing feedback but myself I would prefer to put more focus on the few other issues that we have open.

[jeff-zucker]

We don't need to go into this in depth, but I am trying to understand how you envision ProductClass working.

From your example I see that SaiAuthorizationAgent is the ProductClass of SaiJsAuthorizationAgent but is not mentioned in either the server or the service. This is what I wanted to understand. If I'm understanding you correctly, the ProductClass only belongs to the one thing that implements it, not to the things built using it. So in your example FooService has no direct relationship with SaiAuthorization ProductClass. Do I have that right?

[jeff-zucker]

clearer semantic than generic subType

Clearer to you who understands ProductClass.

I would prefer to put more focus on the few other issues that we have open

I am not going to approve PR #19 until I understand ProductClass, so this is an open issue.

[jeff-zucker]

Okay, if the thumbs up on the comment two above this one means I understand what the ProductClasses get applied to, we can move off this issue for now.

[elf-pavlik]

If I'm understanding you correctly, the ProductClass only belongs to the one thing that implements it, not to the things built using it.

Software (Product) implements one or more ProductClass (preferably in a conformant manner 😉 ). Indirectly Service, via SoftwareStack build with that Software, offers some features that are provided by that ProductClass. I don't think we need inference, simple query should be enough.

From end-user point of view they probably care about features. We probably will need some mapping between features and product classes, I would expect it to be many-to-many since combination of for product classes might be required for higher level feature (eg. FedCM IdP + Solid-OIDC Provider), and since CG is doing exploratory work, we should expect alternative product classes from different specs aiming at providing the same user facing feature.

[elf-pavlik]

I just noticed that ex:clientID should be used on Service/Deployment of an Application, not the Software/Product itself. If we take an example of an open source software app, it can have dozens, hundreds or more deployments. Each one will have its own Client ID.
Conflating Service/Deployment of an Application with Software/Product wouldn't be that much of a problem for proprietary apps which only have one deployment.

[jeff-zucker]

Can you give an example of the triples you would use to model an app, its deployment, and its clientID?

[elf-pavlik]

Fist the Software which isn't deployed

<https://dist.acme.example/vuejectron> a ex:Product ;
  doap:maintainer <https://elf.example> ;
  ex:language "Typescript" .
  # etc.

Now two different deployments

<https://vj.foo.example> a ex:Service ;
  ex:clientID <https://vj.foo.example> ;
  ex:webAppEndpoint <https://vj.foo.example> ;
  ex:provider <https://foo.example> ;
  ex:serviceFrontEnd <https://dist.acme.example/vuejectron> ;
  ex:serviceAudience "Foo gang" .
  # etc.

<https://jet.bar.example> a ex:Service ;
  ex:clientID <https://jet.bar.example> ;
  ex:webAppEndpoint <https://vj.foo.example> ;
  ex:provider <https://bar.example> ;
  ex:serviceFrontEnd <https://dist.acme.example/vuejectron> ;
  ex:serviceAudience "Bar gang" .
  # etc.

If we go step further we don't need ex:clientID since we are describing that deployed application and use it as subject/object #16 (comment)

For example Figure 3 (snippet) in https://solid.github.io/data-interoperability-panel/specification/#app

[jeff-zucker]

I'm still not sure I am understanding you. Are you talking about an Identity or Storage Service? How would they have clientIDs? Or are you talking about what I refer to as webAppEndpoint? If so, then please, as I asked above, give me an example of a set of triples with both the app and its deployment because I do not understand how you intend to differentiate them. If you are talking about something else, please explain it, because I really do not understand what you are describing.