- From: Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>
- Date: Thu, 20 Jan 2005 20:25:24 -0000
- To: "Rich Salz" <rsalz@datapower.com>, "Mark Baker" <distobj@acm.org>
- Cc: "Tom Rutt" <tom@coastin.com>, <public-ws-addressing@w3.org>
>
> > Can you explain where this high price comes from?
>
> Signing them?
>
In addition to the cost of signing EPRs, I would also add the cost of
generating EPRs that include domain-specific information inside them. I
don't have a problem with assigning a logical URI/URN to each resource
(e.g. urn:myenterprise:edgeserver:1) but creating and giving away EPRs
that encode application-logic-specific information, which is subject to
change, then we are asking for trouble:
<epr>
<address>http://myenterprise.com/management</address>
<refparams>
<id>uuid:bla-bla-bla-bla</id>
<room>1</room>
<rack>2</rack>
<shelf>3</shelf>
<on-power-socket>10</on-power-socket>
<facing-the-wall>true</facing-the-wall>
</refparams>
</epr>
This is the kind of intended use for RefParams that the example in this
thread suggested. Since RefParams are opaque, the consumer of this EPR
cannot reason about the semantics of the included content. Hence, the
entire EPR is treated as an opaque reference. As soon as I turn the edge
server to face away from the wall, this EPR gets invalidated.
It would have been much better if we had an epr that only encapsulates
the address of the service (and any other pointers to metadata) while
the domain specific data is made visible to the consumer explicitly and
independently of the referencing mechanism. A domain-specific protocol
can handle the semantics of trying to refer to information that has
changed.
Regards,
.savas.
Received on Thursday, 20 January 2005 20:26:09 UTC