Eclipse Community Forums: Lyo » Missing nesting capabilities of ServiceProviders

Home » Eclipse Projects » Lyo » Missing nesting capabilities of ServiceProviders(ServiceProviders are not recursive concept and this leads to non-OSLC compliant extensions)

Show: Today's Messages :: Show Polls :: Message Navigator

Missing nesting capabilities of ServiceProviders [message #1702405]

Wed, 22 July 2015 07:36

Aleksander Lodwich

Messages: 1
Registered: July 2015

Junior Member

I am looking for reasons why nesting ServiceProviders is not a good idea.
The OSLC4J framework seems not to support it. The specifications of OSLC Core 2.0 seem not to provide it but that's not a good explanation becuase ServiceProviders shall represent containers and containers are very often nested. For me ServiceProviderCatalogs are not quite the fix for missing ServiceProvider nesting capabilities because at any level of nesting I would expect various services to be available. Maybe the flat ServiceProvider architecture is enforcing certain data partitioning styles?

I know that Doors NG is using nav:folder resources in order to circumvent the problem but it is not OSLC compliant solution, I believe.

I am interested in all input on the background of this shortcoming. Did anyone extend the framework to allow ServiceProviders to nest? Did you experience any significant problems with it then? I am also interested in all other non-compliant approaches and problem reports regarding nesting of ServiceProviders and nesting of containers in general.

Thanks in advance.

Report message to a moderator

Re: Missing nesting capabilities of ServiceProviders [message #1703011 is a reply to message #1702405]

Mon, 27 July 2015 22:23

Jim Ruehlin

Messages: 73
Registered: July 2009

Member

IMO, service provider catalogs were invented to avoid enforcing a data partitioning style, not to force implementors to create a particular partitioning.

Keep in mind that OSLC does not define what an artifact container is (other than a box that contains some kind of artifacts). A container could be a development project, a database of some kind, a collection of folders, an alphabetized list of tests, etc. An artifact container is just an abstract representation of a top-level grouping element that lifecycle tools usually need to implement so the abstractions in their applications make sense.

So artifact containers might or might not contain other types of containers - OSLC doesn't define this. However, a service provider could provide a service that returns a catalog of other containers, such as folders. So OSLC allows for this type of hierarchy, but it doesn't demand it or restrict it.

This question is more oriented towards OSLC than Lyo. You might also want to pursue it on the OASIS OSLC Core TC mailing list.

- Jim Ruehlin

Report message to a moderator

Previous Topic:	OSLC Query to get requirements from a RequirementCollection on DOORS NG
Next Topic:	Update example applications to Java 8

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Jan 14 21:22:18 GMT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter