W3C home > Mailing lists > Public > www-ws-arch@w3.org > May 2003

Re: Separate concepts for "service" and "targetResource?" (was RE: /service/@targetResource ?)

From: Walden Mathews <waldenm@optonline.net>
Date: Thu, 22 May 2003 02:50:02 -0400
To: Assaf Arkin <arkin@intalio.com>
Cc: Ugo Corda <UCorda@SeeBeyond.com>, "Champion, Mike" <Mike.Champion@softwareag-usa.com>, www-ws-arch@w3.org
Message-id: <011201c3202e$5fef2b40$1702a8c0@WorkGroup>

> Yes, but that's a different resource than the targetResource discussed
> so far.

You're right.

> If I don't care which ATM I'm using then the ATM I use today and the ATM
> you use today may be the same ATM, the same service. But you can't
> switch the targetResource based on who is accessing the ATM. So my
> account is not the targetResource, but "the ATM network" could be the
> resource that links all these services together.

There's a reason why procedural programming was kinda dropped
a few decades ago in favor of the object model.  I have a feeling we
are going to see that metamorphosis again soon.  This is like taking
one object method, promoting it to global scope, and then trying to
bind it back to only a single instance.

> If my bank account would be the service-resource then I would run into
> three problems:
> 1. The ATM would be multiple services, one for each account it can
> manage, so you end up with ATMxAccount service definitions.

Ugh.  See above.

> 2. I would need to use one ATM to withdraw money from my checking
> account, another to withdraw money from my credit card, another to get a
> balance of my savings account

Hah.  Did I once hear of something called "functor object"?  Is that
what we'd have here?  (Just curious)

> 3. The ATM could only handle one account at a time, which would prevent
> me from using it to move money from one account to another.

Unless the accounts know each other when no one's looking
and do strange things, like exchange funds.  Actually, maybe only
one account would have to know about the other.  But okay, I see
your point.

> So tying the service definition to the actual resource behind that
> service creates a complexity problem for me, and quite frankly doesn't
> give me anything since I can already identify individual services by
> their QName.


> On the other hand, tying multiple services to some global, non-specific
> resource to say they are all equivalent in some way, works for me, and
> that's not something I can do given just the service QName. (Though, one
> could say that I could use the service targetNamespace to the same effect)

Or do you mean tying multiple resources to some global, non-specific
implementation, so that they can all behave the same?  Otherwise, all
you have is a bunch of equivalent services, which means you have one
service, and you still can't multiplex it over all the objects you want to.

Received on Thursday, 22 May 2003 02:45:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:52 UTC