Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Lyo » Missing nesting capabilities of ServiceProviders(ServiceProviders are not recursive concept and this leads to non-OSLC compliant extensions)
Missing nesting capabilities of ServiceProviders [message #1702405] Wed, 22 July 2015 07:36 Go to next message
Aleksander Lodwich is currently offline Aleksander LodwichFriend
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.
Re: Missing nesting capabilities of ServiceProviders [message #1703011 is a reply to message #1702405] Mon, 27 July 2015 22:23 Go to previous message
Jim Ruehlin is currently offline Jim RuehlinFriend
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
Previous Topic:OSLC Query to get requirements from a RequirementCollection on DOORS NG
Next Topic:Update example applications to Java 8
Goto Forum:
  


Current Time: Tue Mar 19 03:24:29 GMT 2024

Powered by FUDForum. Page generated in 0.02318 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top