Rob Eamon wrote:
> --- In [email protected] 
> <mailto:service-orientated-architecture%40yahoogroups.com>, Gregg
> Wonderly <[EMAIL PROTECTED]> wrote:
...
>  > A web browser is the most common form of client.
> 
> 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.

Perhaps we use a different set of web services, but I know I use more than one 
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, the
> 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.

It is the client of that service, but it still provides a service to the web 
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,
> 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.

You are pushing "layers" into the picture, which are "not" part of the detail 
of 
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.

Gregg Wonderly

Reply via email to