[OSLC] Root Services vs Service Provider Catalog
Scott Bosworth
bosworth at us.ibm.com
Wed Jan 6 09:43:40 EST 2010
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 | bosworth at us.ibm.com | 919.486.2197
(w) | 919.244.3387(m) | 919.254.5271(f)
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Ferran Rodenas <frodenas at gmail.com> |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Arthur Ryman <ryman at ca.ibm.com>, Steve K Speicher/Raleigh/IBM at IBMUS, community <community at open-services.net> |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| 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 <ryman at ca.ibm.com>
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. To
net Ferran Rodenas <?,
frodenas at gmail.com>
cc
01/04/2010 09:58 AM 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.
_______________________________________________
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/20100106/1d16d250/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100106/1d16d250/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100106/1d16d250/attachment-0001.gif>
More information about the Community
mailing list