[OSLC] Root Services vs Service Provider Catalog

[Arthur Ryman]

Steve/Ferran,

Ditto. My workgroup (Estimation and Measurement) will also not define 
anything in this space, i.e. we will assume that whatever app server a 
service is deployed on will have a mechanism for publishing the services 
deployed on it. 

IMHO, I think this is a valid requirement but a lower priority for OSLC 
since we have several other common specs to define that affect the 
detailed design of services, e.g. query, resource representations. 

Arthur Ryman, IBM DE
Chief Architect, Rational Project and Portfolio Management
Office: 905-413-3077, Cell: 416-939-5063
Assistant: Nancy Barnes, 905-413-4182 



Steve K Speicher <sspeiche at us.ibm.com> 
Sent by: community-bounces at open-services.net
01/04/2010 09:58 AM

To
Ferran Rodenas <frodenas at gmail.com>
cc
community <community at open-services.net>
Subject
Re: [OSLC] Root Services vs Service Provider Catalog







Ferran Rodenas <frodenas at gmail.com> wrote on 12/23/2009 06:35:14 PM:
> Some questions about discovery services and security:
> 
> 1) Are there any plans to create an OSLC specification similar to 
> the JF Root Services specification (https://jazz.net/wiki/bin/view/
> Main/RootServicesSpec)? If not, which is the standard mechanism to 
> discover services offered by a tool? Clients MUST point directly to 
> the desired Service Provider Catalog (CM, QM, RM, ...)?

As more topics have come on line and producing 1.0 versions of 
specifications, there is a growing need for this at OSLC.  We have started 
to collect some of these common requirements but we have no firm plans of 
yet to provide such a mechanism. 

So the current standard mechanism is the consumer most some how know the 
URL for the service provider catalog or document: email, chat, additional 
wrapper spec (JF root services), etc. 

> 2) In this scenario, how consumers deal with security? The Service 
> Provider Catalog Specification 1.0 says that access to a service 
> provider catalog resource MAY be protected, and the CM Rest API 1.0 
> says that service providers SHOULD support HTTP basic authentication
> and/or OAuth. But, how consumers knows which authentication methods 
> are supported by the service provider? In the JF Root Services, at 
> least, there are some Oauth properties. 

In CM v1.0 we decided (as you noticed) is leave it open.  You have to rely 
on some external mechanism like the JF Root Services model to discover or 
you can rely on HTTP 401 challenges or other established model that the 
consumer knows about (eg vendor-specific form-based auth). 

As we keep pulling in more topic areas, vendors and experience from these 
integrations, we'll work towards driving these issues forward. 

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645
_______________________________________________
Community mailing list
Community at open-services.net
http://open-services.net/mailman/listinfo/community_open-services.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100105/ebf88cec/attachment-0003.html>