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

Re: [service-orientated-architecture] ROA is not SOA - (was Alternatives to WS Standards)

Expand Messages
  • Jan Algermissen
    ... URIs are opaque identifiers (just like object references in any OO language). You should not infer anything from a URI. Jan
    Message 1 of 232 , Nov 29, 2006
      On Nov 28, 2006, at 11:40 PM, Steve Jones wrote:

      > o you are saying that it is _bad_ practice in REST to have sensibly
      > named URIs?


      URIs are opaque identifiers (just like object references in any OO
      language). You should
      not infer anything from a URI.

      Jan
    • Hitoshi Ozawa
      Hi Anne, Nice to see you back posting on the list again. ... I m not too sure what you mean by Wal-Mart service . What is the difference between having an
      Message 232 of 232 , Dec 17, 2006
        Hi Anne,
        Nice to see you back posting on the list again.

        Anne Thomas Manes wrote:
        > This service called "Wal-Mart" (or "WMT") is a service to a stockholder.
        > I would also content that a Wal-Mart store is a representation of the
        > Wal-Mart service, which is a service to a shopping consumer.
        >
        >
        I'm not too sure what you mean by "Wal-Mart service". What is the
        difference between having an Wal-Mart object in OO and Wal-Mart service?

        >> I meant this from a technical perspective. There is lots of
        >> functionality that is unique to a specific application. If this
        >> functionality will never be used in any other application, and the
        >> functionality is quite stable, it doesn't make sense to implement it
        >> as a service and impose the overhead of service creation, service
        >> management, and service invocation. Also, you might have application
        >> requirements that demand extremely high performance or atomic
        >> transactions, etc, that demand more tight coupling.
        >>
        >>
        Yes, thank you for restating it.
        Similarly, as there are limitations placed by the current technology and
        the cost associated with it
        in a technical perspective, there are limitations placed by people on a
        business perspective.
        It may be a "should" in the context of SOA , but that does not necessary
        translate to a "should"
        in the context of a project.


        >> SOA is a mindset -- it's your approach to designing systems. It's a
        >> set of principles that help ensure that you build flexible and
        >> adaptable systems. I recommend that you internalize these principles
        >> and apply to to every application system you're building. That does
        >> not mean that you will implement every application using any
        >> particular technology (SOA is independent of any particular
        >> technology), or that in every application system you will refactor
        >> reusable functionality into shared services, or that in every
        >> application system you will reuse an existing service rather than
        >> build the capability again, or that when you do implement a service,
        >> its interface must be completely loosely coupled. In all cases, you
        >> must let the application system requirements dictate your design and
        >> infrastructure decisions. But I reiterate, you should apply SOA
        >> principles to every system design. (Just as, I'm sure, you apply many
        >> other fundamental design principles to every project you do.)
        >>
        >>
        +1 on SOA is a mindset.
        "every" is a strong word which I'm hesitant to use. There are some
        fundamental design principles I use
        on "many" projects, but there's always some exceptions based on
        customers' requests.

        Cheers,
        H.Ozawa
      Your message has been successfully submitted and would be delivered to recipients shortly.