SOA - the biggest Hype to evver hit the IT industry!

 

1.1        What is a Service?

 

A service is an implementation of a well-defined business functionality, and such services can then be consumed by clients in different applications or business processes. [Sun]

 

ZZZ comments: This means that service is a business functionality, not technology or implementation of some technology.

 

Services are software components with well-defined interfaces that are implementation-independent. [Sun]

 

Services are self-contained (perform predetermined tasks) and loosely coupled (for independence)

[Sun]

 

A service is a unit of work done by a service provider to achieve desired end results for a service consumer.  Both provider and consumer are roles played by software agents on behalf of their owners. [XML.com]

 

A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services. [http://www.service-architecture.com]

1.2        What is SOA?

• SOA is ”A collection of Services that communicate with each other” [Cryer.com]

(=A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed. - http://www.service-architecture.com)

 

• TODO: ”SOA is described, asynchronous, remote, loosly coupled, orchestrated, standard-based...” quote

• ”[SOA] is an integrated software infrastructure and design approach, leveraging Web computing standards, for delivering business functions as shared and reusable services.” [sun]

 

SOA is an architectural style for building software applications that use services available in a network such as the web. It promotes loose coupling between software components so that they can be reused. Applications in SOA are built based on services. [Sun]

 

SOA and web services are two different things, but web services are the preferred standards-based way to realize SOA. [Sun]

 

ZZZ Comments:  Such 'preferred way' contradicts the guideline on Services which says services should be implementation independent.

 

• ”SOA is web services” [unattributed]

ZZZ Comments: Sun contradicts this!

 

In reality " SOA misused web services to get focus (you naughty: your concepts are at least 40 years old)."  http://soa-eda.blogspot.com/2006/06/soa-doesnt-add-business-value-but-eda.html

 

·        SOA is an architectural style whose goal is to achieve (?ZZZ)loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer.  [xml.com]

·        The idea of SOA departs significantly from that of object oriented programming (!ZZZ), which strongly suggests that you should bind data and its processing together. [xml.com]

 

• Loose coupling

 

Orchestration - the act of combining hharmoniously ; instrumentation(?)

1.3        Advantages of SOA:

 

SOA allows for the reuse of existing assets where new services can be created from an existing IT infrastructure of systems. In other words, it enables businesses to leverage existing investments by allowing them to reuse existing applications, and promises interoperability between heterogeneous applications and technologies. SOA provides a level of flexibility that wasn't possible before in the sense that:  [sun]

Services are software components with well-defined interfaces that are implementation-independent. An important aspect of SOA is the separation of the service interface (the what) from its implementation (the how).

Such services are consumed by clients that are not concerned with how these services will execute their requests.

Services are self-contained (perform predetermined tasks) and loosely coupled (for independence)

Services can be dynamically discovered  (ZZZ ?)

Composite services can be built from aggregates of other services

1.4        Kill Offshore Model?

http://webservices.sys-con.com/read/175388_p.htm even say that SOA Will Kill the Offshore Model.

ZZZ comments: In reality SOA will complicate and confuse the application development to such an extent that more and more stuff will be offshored!

1.5        Realizing Loose Coupling

 

How does SOA achieve loose coupling among interacting software agents? It does so by employing two architectural constraints:

1.      A small set of simple and ubiquitous interfaces to all participating software agents. Only generic semantics are encoded at the interfaces. The interfaces should be universally available for all providers and consumers.

2.      Descriptive messages constrained by an extensible schema delivered through the interfaces. No, or only minimal, system behavior is prescribed by messages. A schema limits the vocabulary and structure of messages. An extensible schema allows new versions of services to be introduced without breaking existing services.

[Xml.com] ubiquitous =Present, appearing, or found everywhere; omnipresent.[1]

 

 

1.6        Martin Fowler on SOA

“I've heard people say the nice thing about SOA is

that it separates data from process,

that it combines data and process,

that it uses web standards,

that it's independent of web standards,

that it's asynchronous,

that it's synchronous,

that the synchronicity doesn't matter.... “

http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html

 

Here is the full text:

 

Whenever ThoughtWorks rashly lets me out in front of a client, one question I'm bound to be asked is "what do you think of SOA (Service Oriented Architecture)?" It's a question that's pretty much impossible to answer because SOA means so many different things to different people.

  • For some SOA is about exposing software through web services. This crowd further sub-divides into those that expect the various WS-* standards and those that will accept any form of XML over http (and maybe not even XML).
  • For some SOA implies an architecture where applications disappear. Instead you have core services that supply business functionality and data separated by UI aggregators that apply presentations that aggregate together the stuff that core services provide.
  • For some SOA is about allowing systems to communicate over some form of standard structure (usually XML based) with other applications. In it's worse form this is "CORBA with angle brackets". In more sophisticated forms this involves coming up with some form of standard backbone for an organization and getting applications to work with this. This backbone may or may not involve http.
  • For some SOA is all about using (mostly) asynchronous messaging to transfer documents between different systems. Essentially this is EAI without all the expensive EAI vendors locking you in.

I've heard people say the nice thing about SOA is that it separates data from process, that it combines data and process, that it uses web standards, that it's independent of web standards, that it's asynchronous, that it's synchronous, that the synchronicity doesn't matter....

I was at Microsoft PDC a couple of years ago. I sat through a day's worth of presentations on SOA - at the end I was on the SOA panel. I played it for laughs by asking if anyone else understood what on earth SOA was. Afterwards someone made the comment that this ambiguity was also something that happened with Object Orientation. There's some truth in that, there were (and are) some divergent views on what OO means. But there's far less Object Ambiguity than the there is Service Oriented Ambiguity.

So what do we do? For a start we have to remember all the time about how many different (and mostly incompatible) ideas fall under the SOA camp. These do need to be properly described (and named) independently of SOA. I think SOA has turned into a semantics-free concept that can join 'components' and 'architecture'. It's beyond saving - so the concrete ideas that do have some substance need to get an independent life.

 



[1]Excerpted from Oxford Talking Dictionary. Copyright © 1998 The Learning Company, Inc. All Rights Reserved.