cCard?
jamesurquhart
pCard that has been referenced here as a "cCard". I spent a couple of
days thinking about this, and I'm not sure I see the need. Here's why:
1. I see the need for pCard as driven by the need for a customer to
shop a market. This means (to me) that the customer wants to request
"bids" for service based on need.
2. The other side of the market "coin" is the desire of the provider
to advertise their capabilities. To me, that's the role of traditional
forms of advertising (web and otherwise), as well as service catalogs,
both from the provider and potentially as a shared infrastructure.
3. To the extent that a descriptive format for service catalog
contents is needed, there is a standards effort, SPACL (http://
spacl.info/), that seems to be directly addressing this. Rodrigo
Flores of NewScale even suggests that it could serve as a basis for
pCard: http://www.servicecatalogs.com/2010/01/reading-payload-descriptor-for-cloud-computing-a-great-use-case-for-spacl.html
4. In the end, however, I don't want to be flooded with "spam"
describing every vendors capabilities. I want more of a "search and
assemble" experience in locating the components I need to host and
operate my payloads.
In the end, I think the need for cCard is limited in the use cases I
was considering when I proposed pCard, so I'm not sure I'd combine the
efforts. That said, the response to a pCard request still hasn't been
mapped out at even a macro level--anyone want to take a stab?--and I
could be missing an obvious use case.
So how about it. Does anyone want to make a case for the need for
cCard and whether or not SPACL seems to fit the bill?
James
Rodrigo
my suggestion for using SPACL is based on some of the use cases you
outlined. But your proposal goes further and I see it as more of an
integrative framework that leverages other efforts.
For example, SPACL can describe a service offering (the brochure), a
requestable service and the actual service request so that fits with
what you are looking for. But we left off (on purpose), the actual
protocol by which a service request goes from a customer to a
provider. We may tackle spec in a part 2 of SPACL.
This was based on several factors:
1) We felt something fast was better than something complex.
2) There are a number of developments in the cloudAPI space that we
may mature faster and we could leverage those.
3) There are established protocols in B2B for this type of e-commerce.
Finally, some of the build instructions for the workload that would be
part of pCard, are not in any part of SPACL. And the question of how
we use OVF has not been raised yet in SPACL.
So SPACL will help pCard quite a bit, but it's not a complete
solution.
On Feb 4, 12:31 am, jamesurquhart <jamesloves...@gmail.com> wrote:
> Several of you have indicated an interest in a provider version of
> pCard that has been referenced here as a "cCard". I spent a couple of
> days thinking about this, and I'm not sure I see the need. Here's why:
>
> 1. I see the need for pCard as driven by the need for a customer to
> shop a market. This means (to me) that the customer wants to request
> "bids" for service based on need.
>
> 2. The other side of the market "coin" is the desire of the provider
> to advertise their capabilities. To me, that's the role of traditional
> forms of advertising (web and otherwise), as well as service catalogs,
> both from the provider and potentially as a shared infrastructure.
>
> 3. To the extent that a descriptive format for service catalog
> contents is needed, there is a standards effort, SPACL (http://
> spacl.info/), that seems to be directly addressing this. Rodrigo
> Flores of NewScale even suggests that it could serve as a basis for
> pCard:http://www.servicecatalogs.com/2010/01/reading-payload-descriptor-for...