SOA VS API

 

From what I understand about SOA, WCF is an implementation of this. Similarly, ASP.Net WebAPI is an API.

I have worked in both WCF and WebAPI and want to understand the conceptual difference between these.

API

SOA

API = any way of communicating exposed by a software component.

SOA = a set of enterprise architectural design principles to solve
scalability issues by splitting responsibility into services.

An API is an interface that a component/service exposes so that other
components can communicate with it. In the example above the Bus is providing
a common API for a number of services to communicate.

application programming interface (API) specifies how some software
components should interact with each other.

Service Oriented Architecture is an architectural methodology. It is
a way of specifying separation of responsibility from a business oriented
point of view into independent services, which communicate by a common API
(often but not necessarily by publishing events to a bus).

As an example, you could have one service responsible for capturing
customer orders, which publishes an OrderCaptured event to the bus; and a
separate service responsible for tracking when the customer is billed and how
much is owed, which subscribes to the Bus and responds to the OrderCaptured event.
The first service might not need to know anything about billing due to the
separation of responsibility. And the two services don’t need to know about
each other either, only about the events going on around them.

In addition to accessing databases or computer hardware, such as hard
disk drives or video cards, an API can be used to ease the work of
programming graphical user interface components.

Every architecture (except trivially small ones) will have one or
more APIs so that its components can communicate. And SOA is a type of
architecture pattern / design.

API comes in the form of a library that includes specifications for
routines, data structures, object classes, and variables. In some other
cases, notably for SOAP and REST services, an API comes as just a
specification of remote calls exposed to the API consumers

http://stackoverflow.com/questions/2026523/what-is-soa-in-plain-english/9499594#9499594

Eg. In its simplest form an object API is a prescription of how
objects work in a given object-oriented language: usually it is expressed as
set classes with an associated list of class methods.

For example, in the Java language, if a programmer wants to use the
class Scanner (a class that reads input from the user in text-based
programs), he would import the java.util.Scanner library in order to use it,
and later can use objects of type Scanner invoking some class methods:

where the methods nextLine() and close() are part of the API for the
Scanner class, and hence are described in the documentation for that API.

 

The API in this case can be conceived of as the totality of all
the methods publicly exposed by the classes (usually called the class
interface). This means that the API prescribes the methods by which one
interacts with/handles the objects derived from the class definitions.

 

In this sense, in object-oriented languages, the API defines a set of
object behaviors, possibly mediated by a set of class methods.

In such languages, the API is still distributed as a library.
For example, the Java language libraries include a set of APIs that are
provided in the form of the JDK used by the developers to build new Java
programs. The JDK includes the documentation of the API in JavaDoc notation.

APIs were one tool in the SOA toolbox. APIs have jumped out of the
enterprise toolbox, and found success in the richer oxygen environment of the
Internet, escaping from the claustrophobic environment of the restrictive
enterprise network in which strict governance was imposed, and technologists
decided everything.

Ref: http://apievangelist.com/2013/08/16/api-craft–soa-vs-api/

API vs Library: An API is usually related to a software
library: the API describes and prescribes the expected behavior while the
library is an actual implementation of this set of rules. A single API can
have multiple implementations (or none, being abstract) in the form of
different libraries that share the same programming interface.

 

http://stackoverflow.com/questions/2026523/what-is-soa-in-plain-english/9499594#9499594

Web API: When used in the context of web development, an API
is typically defined as a set of Hypertext Transfer Protocol (HTTP) request
messages, along with a definition of the structure of response messages,
which is usually in an Extensible Markup Language (XML) or JavaScript Object
Notation (JSON) format. While “web API” historically has been
virtually synonymous for web service, the recent trend (so-called Web 2.0)
has been moving away from Simple Object Access Protocol (SOAP) based web
services and service-oriented architecture (SOA) towards more direct
representational state transfer (REST) style web resources and
resource-oriented architecture (ROA).

Eg. The practice of publishing APIs has allowed web communities to
create an open architecture for sharing content and data between communities
and applications. In this way, content that is created in one place can be
dynamically posted and updated in multiple locations on the web:

Photos can be shared from sites like Flickr and Photobucket to social
network sites like Facebook and MySpace.

To Do:

1.       http://apigee.com/about/api-best-practices/apis-inside-enterprise-soa-displacement

2.       http://www.slideshare.net/apigee/apis-inside-enterprise-soa-displacement

3.      

 

 

–>

service oriented architecture

Ref: wiki

It’s based on discrete pieces of software providing application functionality as services to other applications. This is known as Service-orientation. It is independent of any vendor, product or technology.[1]

A service is a self-contained unit of functionality, such as retrieving an online bank statement.[2] Services can be combined by other software applications to provide the complete functionality of a large software application

SOA is based on the concept of a service. Each service that makes up an SOA application is designed to perform one activity. As a result, each service is built as a discrete piece of code. This makes it possible to reuse the code in different ways throughout the application by changing only the way an individual service interoperates with other services that make up the application, versus making code changes to the service itself. SOA design principles are used during software development and integration.

 

SOA generally provides a way for consumers of services, such as web-based applications, to be aware of available SOA-based services. For example, several disparate departments within a company may develop and deploy SOA services in different implementation languages; their respective clients will benefit from a well-defined interface to access them.

 

SOA defines how to integrate widely disparate applications for a Web-based environment and uses multiple implementation platforms. Rather than defining an API, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point for such a SOA implementation.

OA can be seen in a continuum from older concepts of distributed computing[6][8] and modular programming, through SOA, and on to current practices of mashups, SaaS, and cloud computing (which some see as the offspring of SOA).

The Microsoft Windows Communication Foundation team proposed the following principles for service-oriented design: [11]

  1. Boundaries are explicit.
  2. Services are autonomous.
  3. Services share schema and contract, not class.
  4. Service compatibility is based on policy.

Ref: http://msdn.microsoft.com/en-us/library/aa480021.aspx

  1. Design everything from a service perspective
  2. Eventually most software capabilities will be delivered and consumed as services.
  3. Over time, the level of abstraction at which functionality is specified, published and or consumed has gradually become higher and higher. We have progressed from modules, to objects, to components, and now to services. However in many respects the naming of SOA is unfortunate. Whilst SOA is of course about architecture, it is impossible to constrain the discussion to architecture, because matters such as business design and the delivery process are also important considerations. A more useful nomenclature might be Service Orientation (or SO). There are actually a number of parallels with object orientation (or OO) and component-based development (CBD):
  • Like objects and components, services represent natural building blocks that allow us to organize capabilities in ways that are familiar to us.
  • Similarly to objects and components, a service is a fundamental building block that
    1. Combines information and behaviour.
    2. Hides the internal workings from outside intrusion.
    3. Presents a relatively simple interface to the rest of the organism.
  • Where objects use abstract data types and data abstraction, services can provide a similar level of adaptability through aspect or context orientation.
  • Where objects and components can be organized in class or service hierarchies with inherited behaviour, services can be published and consumed singly or as hierarchies and or collaborations.

For many organizations, the logical starting place for investigating service-oriented architecture is the consideration of Web services. However Web services are not inherently service oriented. A Web service merely exposes a capability that conforms to Web services protocols.

  1. 4.       World Wide Web Consortium (W3C) for example refers to SOA as ‘A set of components which can be invoked, and whose interface descriptions can be published and discovered’.