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 <[email protected]> Sent by: [email protected] 01/04/2010 09:58 AM To Ferran Rodenas <[email protected]> cc community <[email protected]> Subject Re: [OSLC] Root Services vs Service Provider Catalog Ferran Rodenas <[email protected]> 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 [email protected] http://open-services.net/mailman/listinfo/community_open-services.net
