> On point#1 COuld you eloborate a little bit more? I did not get the
> issue you were trying to highlight.
As most of us have probably experienced, security is often an
afterthought. If you've got services popping up from tactical
projects where the developers never thought about anyone else using
those services, they may not be passing over identity credentials on
the service request (e.g. WS-Security with Basic Username).
Even if you are using WS-Security with X.509, you may still have a
problem. This information may tell you what user initiated the
request, but it doesn't tell you what application. If my input
messages didn't change between V1 and V2, I now don't have enough
information on the message to properly route. If that application
has made changes that require V2, and I send it a V1 response,
there's a problem.
Another form of identity would be the location that this request came
from. In a company that has many retail locations, a slow-roll/pilot
strategy may be employed. I may want all users of application A in
location B to use the new version, but all other locations using
application A to use the old version. How do I determine what
location the request came from?
>
> On point#6--Are you going towards a contract mgmt infrastructure
> (under umbrella of WS Mgmt. infrastructure)?
If you want multiple versions in production, some form of
intermediary will be required no matter what. It could be a gateway/
broker, an ESB, an agent, etc.
>
> On point#4--What are some of the patterns for WS-Clients to request
> specific versions of a service? Again are you suggesting going
> towards version mgmt infrastructure which routes requests based on
> client requests?
I don't know that there are any well established patterns that are
widely accepted. Three basic ways to handle it are:
1) Each new version gets its own URI (likely required no matter what
in order to deploy multiple versions in production, whether clients
are impacted or not depends on whether you utilize an intermediary
for virtualization)
2) Use a custom SOAP header to indicate version number
3) Implicit version number through inspection of the request message
(won't work for all cases- if only the response message changed, this
does no good)
4) Pass in the version number as part of the operation (yuck)
-tb
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
