Explore topic-wise InterviewSolutions in .

SOA is a thinking, it’s an architectural concept, and web service is ONE of the TECHNICAL approaches to complete it. Web services are the preferred standards to achieve SOA.

• In SOA we need services to be loosely coupled. A web service communicates using the SOAP protocol which is XML based, which is very loosely coupled. It answers the what part of the service.
• SOA services should be able to DESCRIBE themselves. WSDL DESCRIBES how we can access the service.
• SOA services are located in a directory. UDDI describes where we can get the web service. This is nothing but the implementation of the SOA registry.

SOA is a thinking, it’s an architectural concept, and web service is one of the technical approaches to complete it. Web services are the preferred standards to achieve SOA.

These are the three terminologies on which SOA service stands. Every service must expose one or more ends by which the service can be MADE available to the client. The End consists of three important things: where, what, and how:

• Contract (What): Contract is an agreement between two or more parties. It defines the protocol how clients should communicate with your service. TECHNICALLY, it describes parameters and return values for a method.
• Address (Where): An Address indicates where we can find this service. Address is a URL, which points to the location of the service.
• Binding (How): BINDINGS DETERMINE how this end can be accessed. It determines how communication is done. For instance, you expose your service, which can be accessed using SOAP over HTTP or binary over TCP. So for each of these communication MEDIUMS, two bindings will be created.

These are the three terminologies on which SOA service stands. Every service must expose one or more ends by which the service can be made available to the client. The End consists of three important things: where, what, and how:

Please note this architecture diagram is not tied up with implementations of Microsoft, IBM etc. It’s a general architecture. Any vendor who implements SOA needs to fulfill the below SOA components. How they do it is completely their own technological implementation.

The main goal of SOA is to CONNECT disparate systems. In order that these disparate systems WORK they should message each other. ESB (Enterprise Service Bus) acts like a reliable post office which guarantees the delivery of messages between systems in a loosely coupled manner. ESB is a SPECIAL layer which delivers messages between applications. In the figure we have shown a huge plump pipe. It’s not hardware or some wire etc. It’s a group of components/software which helps you send and receive messages between the disparate applications. Do not try to CODE your own ESB, you can think of buying one from Microsoft, IBM, Oracle, Progress, etc.

Please note this architecture diagram is not tied up with implementations of Microsoft, IBM etc. It’s a general architecture. Any vendor who implements SOA needs to fulfill the below SOA components. How they do it is completely their own technological implementation.

The main goal of SOA is to connect disparate systems. In order that these disparate systems work they should message each other. ESB (Enterprise Service Bus) acts like a reliable post office which guarantees the delivery of messages between systems in a loosely coupled manner. ESB is a special layer which delivers messages between applications. In the figure we have shown a huge plump pipe. It’s not hardware or some wire etc. It’s a group of components/software which helps you send and receive messages between the disparate applications. Do not try to code your own ESB, you can think of buying one from Microsoft, IBM, Oracle, Progress, etc.

Services are logical grouping of components to achieve a business FUNCTIONALITY. Components are implementation APPROACHES to MAKE a service. The components can be in Java, C#, C++ but the services will be exposed in a general format LIKE Web Services.

Services are logical grouping of components to achieve a business functionality. Components are implementation approaches to make a service. The components can be in Java, C#, C++ but the services will be exposed in a general format like Web Services.

In SOA we can divide any architecture in two layers. The FIRST which has direct relevance to the BUSINESS as it CARRIES out business functions. The second layer is a technical layer which talks about managing computer resources like database, web server, etc. This division is needed to identify a service. Consider the FIGURE ‘Simple order system’. It has various components which interact with each other to complete the order system functionality.

The simple order system can be divided in to two layers. You can see the plumbing layer consisting of data access layer, AJAX, and yes more technical stuff.

In SOA we can divide any architecture in two layers. The first which has direct relevance to the business as it carries out business functions. The second layer is a technical layer which talks about managing computer resources like database, web server, etc. This division is needed to identify a service. Consider the figure ‘Simple order system’. It has various components which interact with each other to complete the order system functionality.

The simple order system can be divided in to two layers. You can see the plumbing layer consisting of data access layer, AJAX, and yes more technical stuff.

No. If you NEED to integrate or make an EXISTING system as a BUSINESS service, you just need to create loosely coupled wrappers which will WRAP your custom systems and expose the systems FUNCTIONALITY in a generic fashion to the external world.

No. If you need to integrate or make an existing system as a business service, you just need to create loosely coupled wrappers which will wrap your custom systems and expose the systems functionality in a generic fashion to the external world.

Surely CULTURAL. SOA does require people to THINK of BUSINESS and technology differently. Instead of thinking of technology first (e.g., If we implement this SYSTEM, what kinds of things can we do with it?), practitioners must first think in terms of business functions, or services (e.g., My company does these business functions, so how can I set up my IT system to do those things for me most efficiently?).

It is expected that adoption of SOA will CHANGE business IT departments, creating service-oriented (instead of technology-oriented) IT organizations.

Surely cultural. SOA does require people to think of business and technology differently. Instead of thinking of technology first (e.g., If we implement this system, what kinds of things can we do with it?), practitioners must first think in terms of business functions, or services (e.g., My company does these business functions, so how can I set up my IT system to do those things for me most efficiently?).

It is expected that adoption of SOA will change business IT departments, creating service-oriented (instead of technology-oriented) IT organizations.

One of the most common pitfalls is to view SOA as an end, rather than a means to an end. DEVELOPERS who focus on building an SOA solution rather than solving a SPECIFIC business problem are more likely to create COMPLEX, unmanageable, and unnecessary interconnections between IT resources.

Another common pitfall is to try to solve multiple problems at once, rather than solving small pieces of the problem. Taking a top-down approach—starting with major organization-wide infrastructure investments—often fails either to show results in a relevant TIMEFRAME or to offer a compelling RETURN on investment.

One of the most common pitfalls is to view SOA as an end, rather than a means to an end. Developers who focus on building an SOA solution rather than solving a specific business problem are more likely to create complex, unmanageable, and unnecessary interconnections between IT resources.

Another common pitfall is to try to solve multiple problems at once, rather than solving small pieces of the problem. Taking a top-down approach—starting with major organization-wide infrastructure investments—often fails either to show results in a relevant timeframe or to offer a compelling return on investment.

One strategy for achieving loose coupling is to use the service interface (the WSDL for a SOAP WEB Service) to limit this dependency, hiding the service IMPLEMENTATION from the consumer. Loose coupling can be addressed by encapsulating the service functionalities in a manner that limits the impact of CHANGES to the implementation on the service interface.

However, at some point you will NEED to change the interface and manage VERSIONING without impacting service consumers, in addition to managing multiple security constraints, multiple transports, and other considerations.

One strategy for achieving loose coupling is to use the service interface (the WSDL for a SOAP Web Service) to limit this dependency, hiding the service implementation from the consumer. Loose coupling can be addressed by encapsulating the service functionalities in a manner that limits the impact of changes to the implementation on the service interface.

However, at some point you will need to change the interface and manage versioning without impacting service consumers, in addition to managing multiple security constraints, multiple transports, and other considerations.

SOA is an architectural style. And building architecture is a Top-Down process and not Bottom-Up. The most compelling reason for saying that Web Services are not SOA is that they are technical stuff, often built with a Bottom-Up APPROACH. Building a Bottom-UP SOA is a wrong approach and might lead to an architecture with a lot of REDUNDANCY or maybe no architecture at all.

However, the result of building SOA only Top-Down could be PERCEPTUAL Architecture building with no run TIME artifacts, so some SOA efforts should be Bottom-Up efforts. To sum up: Initially SOA is a Top-Down approach but pragmatic approach requires mixing Top-Down approach with Bottom-Up approach.

SOA is an architectural style. And building architecture is a Top-Down process and not Bottom-Up. The most compelling reason for saying that Web Services are not SOA is that they are technical stuff, often built with a Bottom-Up approach. Building a Bottom-UP SOA is a wrong approach and might lead to an architecture with a lot of redundancy or maybe no architecture at all.

However, the result of building SOA only Top-Down could be perceptual Architecture building with no run time artifacts, so some SOA efforts should be Bottom-Up efforts. To sum up: Initially SOA is a Top-Down approach but pragmatic approach requires mixing Top-Down approach with Bottom-Up approach.

It is an autonomous, reusable, discoverable, stateless functionality that has the necessary granularity, and can be part of a composite application or a composite service.A reusable service should be identified with a business activity described by the service SPECIFICATIONS (design-time contract).

A service’s constraints, including security, QoS, SLA, usage policies, MAY be defined by multiple run-time contracts, multiple interfaces (the WSDL for a SOAP WEB Service), and multiple implementations (the code).

A reusable service should be governed at the enterprise level throughout its entire lifecycle, from design-time through run-time. Its reuse should be promoted through a prescriptive PROCESS, and that reuse should be measured.

It is an autonomous, reusable, discoverable, stateless functionality that has the necessary granularity, and can be part of a composite application or a composite service.A reusable service should be identified with a business activity described by the service specifications (design-time contract).

A service’s constraints, including security, QoS, SLA, usage policies, may be defined by multiple run-time contracts, multiple interfaces (the WSDL for a SOAP Web Service), and multiple implementations (the code).

A reusable service should be governed at the enterprise level throughout its entire lifecycle, from design-time through run-time. Its reuse should be promoted through a prescriptive process, and that reuse should be measured.

Transforming an enterprise business to Service Oriented Architecture includes obtaining standardized service contract, service reusability, service abstraction, service loose coupling, service compos ability and so on.

Of course SOA is an architectural model agnostic to technology PLATFORMS and every enterprise can pursue the strategic GOALS associated with service-oriented computing using different technologies. However in the current MARKETPLACE, Web Services are probably the technology PLATFORM that better suits SOA PRINCIPLES and are most used to get to this architecture.

Transforming an enterprise business to Service Oriented Architecture includes obtaining standardized service contract, service reusability, service abstraction, service loose coupling, service compos ability and so on.

Of course SOA is an architectural model agnostic to technology platforms and every enterprise can pursue the strategic goals associated with service-oriented computing using different technologies. However in the current marketplace, Web Services are probably the technology platform that better suits SOA principles and are most used to get to this architecture.

• SOA helps create GREATER alignment between IT and line of business while generating more flexibility – IT flexibility to support greater business flexibility. Your business PROCESSES are changing faster and faster and global competition requires the flexibility that SOA can provide.
• SOA can help you get better reuse out of your existing IT investments as WELL as the new services you’re developing today. SOA makes integration of your IT investments easier by making use of well-defined interfaces between services. SOA also provides an ARCHITECTURAL model for integrating business partners’, customers’ and suppliers’ services into an enterprise’s business processes. This reduces cost and improves CUSTOMER satisfaction.

SOA principles were first defined by Thomas Erl. These 8 principles are underlying to any good architecture that utilizes SOA design to build their products and services:

• Standardized service contract: Services adhere to a communications agreement, as defined collectively by one or more service-description documents.
• Service loose coupling: Services maintain a relationship that minimizes dependencies and only requires that they maintain an AWARENESS of each other.
• Service abstraction: Beyond descriptions in the service contract, services hide logic from the outside world.
• Service re usability: Logic is divided into services with the intention of promoting reuse.
• Service autonomy: Services have CONTROL over the logic they encapsulate.
• Service statelessness: Services minimize resource consumption by deferring the management of state INFORMATION when necessary
• Service dis coverability: Services are supplemented with communicative meta data by which they can be effectively DISCOVERED and interpreted.
• Service composability: Services are effective composition participants, regardless of the SIZE and complexity of the composition.

SOA principles were first defined by Thomas Erl. These 8 principles are underlying to any good architecture that utilizes SOA design to build their products and services:

• SOA SEPARATES business functions into services (endpoints), which are made accessible over a network in order to allow USERS to combine and reuse them in their applications.
• The SOA services can be developed in different languages and OS’es as long as they follow the SOA principles.
• Services are unassociated and loosely COUPLED units that do not directly rely on each other for their full functioning. Rather than services embedding calls to each other in their source code, they use defined protocols that describe how services pass and parse messages using description metadata.
•  Orchestration is a process where business functionality from various services are combined in a system fully aware of all available services and the associated metadata that defines these services and their CHARACTERISTICS.