Re: Meehan on WOA and SOA
- --- In firstname.lastname@example.org, "Anne Thomas
Manes" <atmanes@...> wrote:
> Now, as Stefan recommends, both of these URIs should be redirected >to a single URL, e.g.:
>Perhaps you've covered this before, but what is the rationale behind
> But I much prefer this URL to something truly opaque like:
using an artificial key in this context?
- Rob Eamon wrote:
> --- In email@example.com...
> <mailto:service-orientated-architecture%40yahoogroups.com>, Gregg
> Wonderly <gergg@...> wrote:
> > A web browser is the most common form of client.Perhaps we use a different set of web services, but I know I use more than one
> I think this is where we may be at odds. Using a browser directly as
> a service client would effectively push the UI into the service
> itself. I think this is bad mojo.
web server's services directly. It gives me direct access to resources,
including HTML pages that direct my workflow, explicitly. You might not see
that as the service, and instead say that is the client of the service as you
discuss below. But, from my perspective, the first rank of access a client has,
is the "service" it is using. The fact that a service may be a client of
another service, is a secondary issue for this discussion. I am speaking
directly about the public interface that "my" client uses.
> A browser, IMO, should never be a direct service client. Instead, theIt is the client of that service, but it still provides a service to the web
> browser interacts with a client application, charged with being the
> presentation layer for the user. This presentation layer is not part
> of the service. It, not the browser, is the service client.
browser, and that, is the workflow service control that I am talking about.
> As such, the browser user never has direct access to service URIs,You are pushing "layers" into the picture, which are "not" part of the detail of
> unless the client app explicitly provides some mechanism to do so.
> There may be cases where this makes sense, but I would think in the
> majority of the cases the client app would provide access to
> capabilities via something other than URI entry. Thus, the client
> app, not the service(s), drives the workflow on behalf of its user.
the "public" interface to services that the "users" client has access to. For
me, that's a secondary issue, because such a layered system is not "designed" to
expose those interfaces (usually).
The primary, outer most layer of service, which a "users" client has access to,
is what they know as "the service". That's where they need to have the ability
to distinctly and directly apply their knowledge and needs to be most effective
at taking advantage of a service's capabilities. I contend that creating URIs
at that layer, by hand, is one of the possibilities that is valuable in many, if
not all cases.