Loading ...
Sorry, an error occurred while loading the content.
 

Re: Meehan on WOA and SOA

Expand Messages
  • Rob Eamon
    ... Perhaps you ve covered this before, but what is the rationale behind using an artificial key in this context? -Rob
    Message 1 of 42 , Apr 25, 2008
      --- In service-orientated-architecture@yahoogroups.com, "Anne Thomas
      Manes" <atmanes@...> wrote:
      > Now, as Stefan recommends, both of these URIs should be redirected >
      to a single URL, e.g.:
      >
      > http://www.example.com/orders/order56789
      >
      > But I much prefer this URL to something truly opaque like:
      >
      > http://www/example.com/123453456234511111

      Perhaps you've covered this before, but what is the rationale behind
      using an artificial key in this context?

      -Rob
    • Gregg Wonderly
      ... 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,
      Message 42 of 42 , May 25, 2008
        Rob Eamon wrote:
        > --- In service-orientated-architecture@yahoogroups.com
        > <mailto:service-orientated-architecture%40yahoogroups.com>, Gregg
        > Wonderly <gergg@...> 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
      Your message has been successfully submitted and would be delivered to recipients shortly.