I've been talking to some friends who are proponents of WS-RF and
embedding ReferenceProperties/ReferenceParameters into an EPR. By now we all know that RefProps have gone from the latest version of WS-Addressing, but the principle that they want is the same: an EPR points to a specific (stateful) resource instance of "within" a service.
I've mentioned before why I think this is a bad idea for SOA and so have others. However, the arguments I'm hearing now are based on the supposition that regardless of the merits of context and sessions via that route, you always need a way to refer to some specific instance of a service/state outside of a session. Hence the "object key" approach that WS-Addressing epitomises (and WS-RF uses).
However, I'm still not convinced. Afterall sessions are time dependant
entities: the information that you manipulate within a session is
inherently temporal in nature, even if the period associated with it
is arbitrarily large. So why not just say that there are such things
as sessions that have a lifetime as long as the age of the universe?
Seems to me that you then keep a single uniform model for accessing
and manipulating *back-end implementation specific information* that
is in line with the loosely-coupled nature of SOA we want to
maintain. Or am I missing something?
Here's an easy real-world example, based on the ubiquitous bank
account. I've had an account with my friendly bank since 1984 (nothing
ominous in that date!) and I've kept the same account number
throughout. When I go into any branch in the country I just give them
my account number and Hey Presto, I've got access to my
account. (Imagine if the account number was hard-coded into the branch
address, so I could only got to a specific branch!) If you think about
it, that's a pretty long running session, which we could model
trivially with WS-Context.
No comments:
Post a Comment