OSLC Discovery

OSLC utilizes Discovery to find Services available to the user.

Discovery can be static/up-front, or dynamic/incremental. Dynamic sets link headers on an OPTIONS, HEAD or GET method on a resource. Static actually GETs a ServiceProviderCatalog, or ServiceProvider resource. This oslc-service supports both OSLC 2.0 and OSLC 3.0 discovery.

The kinds of things that can be discovered are:

• Creation Factory: Service.creationFactory or Accepts: POST on an LDPC. All creation factory URIs are LDPC BasicContainers in order to unify OSLC 2.0 and OSLC 3.0 discovery
• Creation and Update constraints
• Resource preview
• Delegated Dialog
• Authentication

oslc-uses BasicContainer LDPCs to create containers for organizing its resources. These containers can be used for any purpose a client might want including:

• different projects or sub-projects that establish the unit of user and process management (e.g., jazz.net app project areas)
• folders users create for organizing resources in project areas
• containers of specific types of resources in order to provide type-specific resource factories

By using BasicContainers, LDP provides a standard way of accessing metadata about these containers through Link headers, accessing members, and creating new members. Note LDP does not define a standard way of removing members. oslc-service will need to be implemented so that deleting a resource removes it from its parent container.

This approach follows a pattern similar to OSLC 2.0 discovery:

• An oslc-service will have a root BasicContainer that contains all other containers and resources
• The root LDPC will also be a ServiceProviderCatalog resource that establishes the OSLC containers and services available from that oslc-service middleware route.
• The root LDPC/ServiceProviderCatalog will contain only BasicContainer LDPCs for the highest-level resource organizations.
• The members of the ServiceProviderCatalog LDPC will be ServiceProvider LDPCs that correspond to project areas, or the highest-level resource organizations. These LDPC may be useful containers for establishing user and process management.
• The members of the ServiceProvider resources will be Service LDPCs that specify the containers for resources in a given OSLC domain, and the services on those resources that are provided by the oslc-service. These services include creation factories (member LDPCs), creation and selection dialogs, and the QueryCapability queryBase URI (which is always the same as the Service LDPC URI).
• The members of the Service resources will be the CreationFactory LDPCs that are used to actually contain the resources supported by the creation factory.
• The default usage for a Service will be the Service LDPC itself, which can also be a CreationFactory.

For example, an oslc-service could provide OSLC services on the following route:

oslc -- ServiceProviderCatalog
  ProjectArea1Id -- ServiceProvider
    
  ProjectArea2Id
  

The reason for this particular container structure is to ensure oslc-service can support both OSLC 2.0 and 3.0 Discovery in a unified way.