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

Re: [service-orientated-architecture] What is SOA?

Expand Messages
  • Steve Jones
    To build on this SOA is about architecture, which means its about thinking and planning, REST, SOAP, EDA et al are not architectural styles they are
    Message 1 of 51 , Jun 30 2:59 PM
      To build on this

      SOA is about architecture, which means its about thinking and planning, REST, SOAP, EDA et al are not architectural styles they are implementation styles.  You can have a consistent SOA that is implemented in any one of those implementation approaches. I blogged about this related to SOA 2.0 (http://service-architecture.blogspot.com/2006/06/soa-20-what-next.html).

      SOA has to not be about technology because I think we've pretty much proven that as an approach being focused on technology doesn't work.


      On 30/06/06, Anne Thomas Manes <atmanes@...> wrote:

      I would put REST into a slightly different category from the technologies. REST is an architectural style, not a technology. REST has a lot in common with SOA, but it is resource-oriented rather than service-oriented. Nonetheless, the two architectural styles are compatible. You can expose services as resources. REST applies additional constraints to SOA, which for some applications provide really beneficial advantages (especially scalability).

      If you start your design from a SOA perspective, then you have a choice at implementation time as to whether or not you want to expose the service as a resource (via a RESTful interface). In that regard, REST feels more like a technology than an architectural style. From the SOA perspective, I would put REST into the same category as "event driven architecture" (EDA). Both constrain and influence service design.

      (If you start your design from a REST perspective, then you have a choice as to whether you want your resource to be a service. It's a different mindset. But this is a SOA discussion list, therefore my analysis comes from the SOA perspective.)


      On 6/30/06, Steve Jones < jones.steveg@...> wrote:

      Ahhh and here is the number one thing that I think SOA is NOT about....


      REST, SOAP, WSDL, Pink Pixies, JMS, UML, BPMN, BPEL et al have NOTHING to do with Architecture they are all about the design and implementation.

      Part of the Service Oriented Delivery of IT... or SOD IT.


      On 30/06/06, Jim Alateras <jima@... > wrote:


      Since REST is an architectural style based on resource abstractions
      does it fulfill the first criteria.....I guess the resources are exposed
      as services through a uniform interface.

      What's you take


      Mark Baker wrote:
      > On 6/29/06, Anne Thomas Manes <atmanes@...> wrote:
      >> I list two fundamental principles:
      >>- service-orientation
      >>- loose coupling
      > Sweet! By these measures alone, REST is a better SOA than WS. It's
      > probably a toss-up wrt service-orientation, but REST is clearly more
      > loosely coupled than WS because it separates the concerns of interface
      > and implementation far better... as we've discussed before;
      > http://groups.yahoo.com/group/service-orientated-architecture/message/3427
      > Mark.
      > Yahoo! Groups Links

    • Jerry Zhu
      I follow Davenport s idea that business process is defined along three dimensions: entity, object, and activity. Entity can be people or computer programs and
      Message 51 of 51 , Oct 22, 2006
        I follow Davenport's idea that business process is
        defined along three dimensions: entity, object, and
        activity. Entity can be people or computer programs
        and are called actors. Objects are what are operated
        by softare such as a letter, a file, or a
        representation of something such as a billing method
        (electronic or paper) etc. Business process has start
        point as actor actions (begin by customers) and end
        points (end with customers). The three dimensions
        give us opportunity to find abstractions in each of
        the three dimension. Business process contains itself
        so we have atomic business processes and composite
        processes. Atomic business processes are composed of
        business activities that can be a hierarchy also. So
        we have atomic business activities and composite
        activities. As such we have a hierarchy business
        process model with business activities at lower level
        and business processes at higher level. Both
        activities and processes are unique so they are reused
        at all levels.

        Once we have this business process modeling in place,
        we need to define services. I define services as
        business processes but not activities. All services
        are business processes. Highest composite business
        processes are not services but may become services in
        the future.

        busincess activities and atomic business processes are
        implemented as COM(or EJBs) objects. Services will
        group relevent COM objects as executable agents. Here
        is the benefits to build SOA on component technology.

        If activities in a business process are not shared any
        where even in the future then the executable agent of
        the services don't have to be implemented in Object or
        Component technologies.

        have to go. Will be back later.


        --- Michael Poulin <m3poulin@...> wrote:

        > Ann, I have to points:
        > 1) you are absolutely right - business object is
        > not the right thing to talk business. I, actually,
        > mean a bisiness unit of work, which may have its
        > own 'capabilities' including data and operations
        > with the data.
        > 2) I have difficulties to imagine a business
        > service which includes business process because
        > both are derived from the business model. To my
        > understanding (the model I follow), an interaction
        > of business services constitute business processes.
        > - Michael
        > Anne Thomas Manes <atmanes@...> wrote:
        > I prefer
        > the term "capability" to "activity and process". A
        > service implements a shared capability -- it may be
        > an activity or a process, but it may also simply
        > provide access to data, or it may implement
        > non-business functionality, such as authentication
        > or auditing.
        > Michael said, "The business has to stop talking IT
        > language and get back to the business terms and
        > tasks." (and I heartily agree). But then he
        > contradicted himself by saying, "business processes
        > are performed by business objects." I caution
        > against this type of terminology if you intend to
        > speak to business people. If you say "business
        > object" to a business person, s/he's likely to think
        > of some sort of document, like a purchase order or
        > an insurance claim. A business object represents
        > the state of a business process, but it doesn't
        > perform it.
        > Anne
        > On 10/20/06, Michael Poulin <m3poulin@...>
        > wrote:
        > Jerry wrote:" Services are activities and processes
        > shared accross." I guess, it is the statement from
        > the Davenport's work.
        > Actually, this is the crucial point to me. In such
        > definition, almost any activities in an enterprise
        > may be considered as business service because
        > "shared across" is a quite fuzzy definition. I think
        > (based on to date IT practice in its variety, which
        > is different from 15 years old IT practice
        > described by Davenport), it was and it is very
        > convenient definition for an IT because it covers
        > modern state of applications and related
        > operations. The problem is only in that this state
        > is not sufficient to handle fast and frequent
        > changes required by the business to agile to the
        > market trends. As it's appeared, inflexibility of
        > applications is caused by the fact they implement
        > only elements of business operations some of which
        > are frequently based on the previous generation of
        > applications; the applications reflect patched
        > business needs, not real business model of the
        > enterprise. It works OK until market demands quick
        > changes and en enterprise cannot meet this
        > demand because of misdirected IT resources.
        > In my proposal, business services and business
        > processes are derived from the enterprise business
        > model irrespective to current IT (applications)
        > state. The business has to stop talking IT language
        > and get back to the business terms and tasks. Each
        > business model has its scope it can evolve in. This
        > evolvement is the subject for SOA, not more. SO,
        > the IT has finite spectrum of business activities
        > to support.
        > I do distinct between business processes and
        > business operations inside the business services.
        > Business services comprise business objects, i.e.
        > business processes are performed by business
        > objects. The latter has its own behaviour (look, it
        > is almost OO model) expressed in business
        > operations. The operations performed by entities
        > and deal with things that may be irrelevant to the
        > enterprise business (like legal things in the food
        > retail business) but needed to run the business.
        > All this helps me to define what services to
        > implement and which services are SOA service and
        > which are just convenient model of application
        > implementation.
        > - Michael
        > Jerry Zhu <jerryyz@...> wrote:
        > To navigate thro business process
        > literature, just go
        > to a local university library to search for popular
        > texts and look at the index for business process.
        > Google search is also a good way. It wont take you
        > a
        > dozen hours to do this.
        > Services are activities and processes shared
        > accross.
        > They have owners as entities (service providers)
        > and
        > are used by other entities (consumers). Entity is
        > one
        > of three dimensions defined by Davenport. I think
        > the
        > debate whether SOA is OO or not is meaningless. OO
        > and SO are at different levels with SO at one level
        > above so SO include OO. OO principle is about
        > abstraction that can also be used in SO along the
        > three dimensions defined by Davenport such as
        > open/close principle and stable dependencies
        > principle. Viewing the world as levels not only
        > allow
        > us to see more but also to understand rich
        > information
        > in the interactions between levels.
        > Jerry
        > --- Michael Poulin < m3poulin@...> wrote:
        > > Jerry,
        > >
        > > I was not able to read through "all literatures
        > > related to business process" but read a few
        > > Davenport's articles for this time. Mr. Davenport
        > > defines a business process as "simply how an
        > > organization does its work" while I see more
        > > structure (business activities based on the
        > > enterprise business model that split into
        > operations
        > > and operational flows of the business objects
        > > manipulating business data) and constrains
        > > (particular business model limitations) in the
        > > business service and process definitions.
        > >
        > > The consequence of the difference is that I
        > do
        > > not consider a business services as an entity,
        > > which can be adequately described with OO
        > principles
        > > only but rather within a combination of OO and
        > > functional model. That is why SOA to me is not
        > OO
        > > model but this is, probably, a different
        > discussion
        > > thread (running now).
        > >
        > > Anyway, I am truly thankful to you for the
        > > reference and, probably, I will contact Mr.
        > Thomas
        > > H. Davenport for more discussions.
        > >
        > >
        > > Cheers,
        > > - Michael Poulin
        > >
        > >
        > >
        > > Jerry Zhu < jerryyz@...> wrote:
        > > Michael,
        > >
        > > thanks for the text. Human organizations are
        > > things
        > > you can see anything you want to see according
        > to
        > > your
        > > theory. Reality tend to reveal us based on our
        > > perspective we bring to it. A perspective
        > > consists of
        > > experience and conceptual apparatus. When we
        > > change
        > > the conceptual apparatus we change the nature
        > of
        > > the
        > > problem. You have presented a conceptual
        > apparatus
        > > what business processes/services are. Good
        > try.
        > > I
        > > think you are doing the right thing that needs
        > to
        > > be
        > > understood first and foremost if we want to
        > build
        > > an
        > > enterprise information systems that are low
        > cost,
        > > effective, and adaptive. Without high quality
        > > business process theory, we can not build a
        > good
        === message truncated ===

        Do You Yahoo!?
        Tired of spam? Yahoo! Mail has the best spam protection around
      Your message has been successfully submitted and would be delivered to recipients shortly.