Re: [service-orientated-architecture] What is SOA?
- 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.
SteveOn 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.)
AnneOn 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.
SteveOn 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:
>>- 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;
>> Yahoo! Groups Links
- 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
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
have to go. Will be back later.
--- Michael Poulin <m3poulin@...> wrote:
> Ann, I have to points:=== message truncated ===
> 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.
> On 10/20/06, Michael Poulin <m3poulin@...>
> 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
> - 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
> dozen hours to do this.
> Services are activities and processes shared
> They have owners as entities (service providers)
> are used by other entities (consumers). Entity is
> of three dimensions defined by Davenport. I think
> 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
> us to see more but also to understand rich
> in the interactions between levels.
> --- 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
> > 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
> > not consider a business services as an entity,
> > which can be adequately described with OO
> > only but rather within a combination of OO and
> > functional model. That is why SOA to me is not
> > model but this is, probably, a different
> > thread (running now).
> > Anyway, I am truly thankful to you for the
> > reference and, probably, I will contact Mr.
> > 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
> > 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
> > the
> > problem. You have presented a conceptual
> > what business processes/services are. Good
> > I
> > think you are doing the right thing that needs
> > be
> > understood first and foremost if we want to
> > an
> > enterprise information systems that are low
> > effective, and adaptive. Without high quality
> > business process theory, we can not build a
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around