SOA

SOA (Service Oriented Architecture)

D 1: Used to design and develop a wide range of services which can be inter-operable.
D 2: It adopts component based programming model.
D 3: It is a set of principles and methodologies for designing and developing software in the for of inter-operable
D 4: Service-oriented architecture (SOA) is an approach used to create an architecture based upon the use of services. Services (such as Restful Web services) carry out some small function, such as producing data, validating a customer, or providing simple analytical services.

SOA is an architectural concept and web service is one of the technical approach to complete it,

Services

D 1: Repeatable business task and composed in to a business process.
D 2: Reusable ,defined with particular articrafts
D 3: Services are the building blocks and they are composed in to a business process.
D 4: Services are used to help get the right information to the right people at right time.
D 5: Service is nothing but a task or a method that is used to execute an activity,
D 6: Services can be reused and combined to deploy composite application to address to address new opportunities.

Service Characteristics 

• Well defined interfaces.
• Well defined quality of service capabilities.
• Well known endpoints: As a destination on the n/w that receives service requests.

Service Register

Locating and publishing web services.

Architectural Components

Figure 1 shows the basic components of a service-oriented architecture. The components of a service-oriented architecture include:

• Service providers. A service provider is a component or set of components that execute a business function in a stateless fashion, accepting predefined inputs and outputs.
• Service consumers. A service consumer is a set of components interested in using one or more of the services provided by service providers.
• Service repository. A service repository contains the descriptions of the services. Service providers register their services in this repository and service consumers access the repository to discover the services being provided.

Figure 1. Service-oriented architectural components

Principles of SOA

Modularity: 

• Component of a larger system that operates independently from the operation of the other components.

Encapsulation:

•  A service hides information or implementation details by encapsulating the information into a construct which presents an interface
•  Many services which were not initially planned under SOA, may get encapsulated or become a part of SOA.

Loose Coupling :

• Incompatible system technologies can be joined ,dis assembled just as easily in to their functional components.
• Services minimize dependencies on each other. 

Separation of Concerns/ Service Composability :

• Services break down a complex problem in a series of smaller pieces. Each of the smaller pieces address a specific concern.
• Services break big problems into little problems. 

Reuse:

• SOA is enabled through pluggable components with standard interfaces.
• Logic is divided into services with the intent of maximizing reuse.

Service Interoperability :

• Services should use standards that allow diverse subscribers to use the service. This is considered so obvious these days that it is often dropped as a principle. 
• 

Service Discoverability :

• Services can be discovered (usually in a service registry).
• 

Service Autonomy :

• Services should have control over the logic they encapsulate. 
• 

Service Abstraction :

• Services hide the logic they encapsulate from the outside world. 

Challenges of SOA

• Managing service metadata(Information about data,Data About Data)
• Lack of testing in SOA space.
• Providing appropriate security
• Interoperability
• Early adoption and evolution of supporting technology 
• Organization change in necessary since SOA crosses system boundaries 
• The architecture is enterprise in scope encompassing dispersed and heterogeneous systems 
• The infrastructure is distributed requiring high availability and scalability 
• The project life cycle methodology requires changes due to complex system dependencies, SOA specific design patterns, and the change impact to the infrastructure and users 
• Program management is often complex due the project scope, interdependencies and new technology risks 
• Quality Assurance is difficult since services are distributed, have many interfaces, require new testing environments, and message based testing tools 
• New competencies must be developed spanning project management, analysis and design, development and operations. 

Challenges

While implementing a service-oriented architecture, a company faces up to eight key challenges. These challenges align to the steps in a typical project deployment plan:

1. Service identification. What is a service? What is the business functionality to be provided by a given service? What is the optimal granularity of the service?
2. Service location. Where should a service be located within the enterprise?
3. Service domain definition. How should services be grouped together into logical domains?
4. Service packaging. How is existing functionality within legacy mainframe systems to be re-engineered or wrapped into reusable services?
5. Service orchestration. How are composite services to be orchestrated?
6. Service routing. How are requests from service consumers to be routed to the appropriate service and/or service domain?
7. Service governance. How will the enterprise exercise governance processes to administer and maintain services?
8. Service messaging standards adoption. How will the enterprise adopt a given standard consistently?

https://msdn.microsoft.com/en-us/library/aa480029.aspx