Hi Ferran. As Steve indicated, the way we've dealing with these common spec topics is to surface them across the WG leads and ask one of them to drive the topic. Some examples of this include the service provider catalog (Speicher), query (Ryman), and the effort by Tack Tong to find a common way for describing the shape of a resource in support of reporting needs (actually, we've come to think of reporting as a cross OSLC topic).
Other high priority topics that have come up are (1) a common way for expressing relationships between resource types (Ian Greene volunteered on this one), and (2) on dealing with resources that require a tight pairing of resource properties with a separate/physical file - e.g. in Asset Mgmt or SCM scenarios (Grant Larsen has been tackling this one). As we closed out 2009 with a number of the specs in late stages of drafting, I think we observed a need to step up the cross-OSLC efforts in 2010. Early on, the different workgroups seemed to follow a common approach -- a fairly lightweight view of the alm resources themselves and more effort spent on defining basic services like discovery, resource creation and retrieval, and query. We intentionally avoided jumping to early conclusions on the right cross-OSLC approach for these services (one , but now we're seeing common patterns that would seem to suggest flipping things a bit -- i.e. coming together on the common services with a core OSLC spec and more time spent by workgroups on the domain resources and vocabularies. Indeed, the CM 2.0 workgroup is spending much of its time on a more robust resource description for change requests. I kind of see this as focus switch between V1 and V2 specs. I think we also need to settle on some norms around namespaces, spec versioning, media types, resource representation formats, etc - we learned a lot in 2009 as well on these topics. I'm interested in any feedback on these observations. I think we need to strengthen and formalize the common OSLC spec effort, and perhaps consider driving a core OSLC common spec as a basis for V2 domain specs. Thoughts anyone? Scott p.s. Ferran, I added a section to the Common Architecture page ( http://open-services.net/bin/view/Main/OslcCommonArchitecture ) to capture a list of proposed cross-OSLC topics. Please feel free to contribute there. Based on the feedback I get on the above, I'll take a to-do to propose a more thoughtful and organized way of our community dealing with the cross-OSLC specs. Scott Bosworth | IBM Rational CTO Team | [email protected] | 919.486.2197 (w) | 919.244.3387(m) | 919.254.5271(f) |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Ferran Rodenas <[email protected]> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Arthur Ryman <[email protected]>, Steve K Speicher/Raleigh/IBM@IBMUS, community <[email protected]> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |01/05/2010 07:40 PM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Re: [OSLC] Root Services vs Service Provider Catalog | >--------------------------------------------------------------------------------------------------------------------------------------------------| Steve, Arthur, Thanks for your response. Is there any WG working in common OSLC specs? Is there any wiki page where I can add/see pending reqs and follow the overall plan/progress and priorities? - Ferran 2010/1/5 Arthur Ryman <[email protected]> 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: community-bounces@open-services. To net Ferran Rodenas <?, [email protected]> cc 01/04/2010 09:58 AM 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. _______________________________________________ Community mailing list [email protected] http://open-services.net/mailman/listinfo/community_open-services.net
