[OSLC] Root Services vs Service Provider Catalog
ryman at ca.ibm.com
Tue Jan 5 10:33:55 EST 2010
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
Ferran Rodenas <frodenas at gmail.com>
community <community at open-services.net>
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.
Steve Speicher | IBM Rational Software | (919) 254-0645
Community mailing list
Community at open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Community