24 Frequently Asked Basic SOA Interview Questions and Answers
24 Frequently Asked Basic SOA Interview Questions and Answers
SOA stands for Service Oriented Architecture. If you are preparing for SOA interview, the following SOA interview questions and answers can be very useful to you. Basically, these SOA interview questions and answers cover basic concepts of SOA like services in SOA, characteristics and principles of services in SOA, loose coupling of services, contract, address and bindings in SOA, main benefits of SOA to the business and IT, difference between services and components in SOA, requirement of SOA to the business, pitfalls of SOA etc. Let's have a look:
1. What is a Service in SOA?
In the real world, a service is what we pay for and we get the intended service.
Example 1 (from Real World): You go to a restaurant and order food. Your order first goes to the counter and then it goes to the kitchen where the food is prepared and finally the waiter serves the food.
So in order to order an item from a restaurant you need three logical departments / services to work together (counter, kitchen, and waiter).
In the same manner in software world, these services are termed as business services.
Example 2 (from Software World): You go to Amazon to order a book. Different services like payment gateway, stock system, and delivery system come together to achieve your task.
All the services are self contained and logical. They are like black boxes. In short we do not need to understand the internal details of how the business service works. For the external world it’s just a black box which takes messages and serves accordingly. For instance the ‘payment gateway’ business service takes the message ‘check credit’ and gives out output: does the customer have credit or not. For the ‘order system’ business service ‘payment gateway’ service is a black box.
2. What are the main characteristics of services in SOA?
Following are the main characteristics of services in SOA:
A) SOA components are loosely coupled. When we say loosely coupled that means every service is self contained and exists alone logically. For instance we take the ‘payment gateway’ service and attach it to a different system.
B) SOA services are black boxes. In SOA, services hide there inner complexities. They only interact using messages and send services depending on those messages. By visualizing services as black boxes, services become more loosely coupled.
C) SOA service should be self defined: SOA services should be able to define themselves.
D) SOA services are maintained in a listing: SOA services are maintained in a central repository. Applications can search the services in the central repository and use them accordingly.
E) SOA services can be orchestrated and linked to achieve a particular functionality: SOA services can be used/orchestrated in a plug and play manner. For instance, the figure ‘Orchestration’ shows two services ‘Security service’ and ‘Order processing service’. You can achieve two types of orchestrations from it: one you can check the user first and then process the order, or vice-versa. Yes, you guessed right, using SOA we can manage a workflow between services in a loosely coupled fashion.
3. What is SOA?
SOA stands for Service Oriented Architecture. SOA is an architecture for building business applications using loosely coupled services which act like black boxes and can be orchestrated to achieve a specific functionality by linking together.
4. What are Contract, Address, and Bindings?
These three terminologies on which SOA service stands. Every service must expose one or more ends by which the service can be available to the client. End consists of three important things where, what and how:-
Contract is an agreement between two or more parties. It defines the protocol how client should communicate with your service. Technically, it describes parameters and return values for a method.
An Address indicates where we can find this service. Address is a URL, which points to the location of the service.
Bindings determine how this end can be accessed. It determines how communications 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 communications medium two bindings will be created.
5. Are web-services SOA?
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.
6. What are the main benefits of SOA?
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
7. What is a reusable Service?
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.
8. Talking about Service identification, which approach between top-down and bottom-up methodologies encourages re-use and maintenance?
Since the top-down approach is business-driven it can be practical to separate the different concerns of business and IT on different plans, providing a common ground in between. So in most situations it the most appropriate if you want to improve reuse and ROI in the medium/long term.
9. How can you achieve loose coupling in a SOA?
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
10. Do you recall any pattern which could be used to leverage loose coupling?
The Mediation pattern, using an enterprise service bus (ESB), will help in achieving this.
Mediation will take loose coupling to the highest level. It will establish independence between consumers and providers on all levels, including message formats, message types (including SOAP, REST, XML, binary) and transport protocols (including HTTP, HTTPS, JMS).
Architecturally speaking this means the separation of concerns between consumers and providers on the transport, message type, and message format levels.
11. The Service of a SOA should be engineered as stateless or stateful?
Service should be stateless. It may have a context within its stateless execution, but it will not have an intermediary state waiting for an event or a call-back. The retention of state-related data must not extend beyond a request/response on a service. This is because state management consumes a lot of resources, and this can affect the scalability and availability that are required for a reusable service.
12. What is composition of a Service?
Composition is the process by which services are combined to produce composite applications or composite services. A composite application consists of the aggregation of services to produce an enterprise portal or enterprise process. A composite service consists of an aggregation of services that produces another reusable service. It’s just like combining electronic components to create a computer motherboard, and then using that motherboard in a computer. Think of the motherboard as a reusable composite service that is a component of the computer, and of the computer as the composite application.
13. How do I integrate my Legacy applications with SOA?
Legacy applications are frequently at the core of your IT environment. With the right skills and tools, you need to identify discrete elements within your legacy applications and “wrap” them in standards-based interfaces and use them as services within your SOA.
14. How does the ESB fits in this picture?
The Enterprise Service Bus is a core element of any SOA. ESBs provide the “any to any” connectivity between services within your own company, and beyond your business to connect to your trading partners. But SOA does not stop at just implementing an ESB. Depending on what your goals are, you may want to use an ESB to connect other services within your SOA such as information services, interaction services and business process management services. Additionally, you will need to consider development services and IT service management services. The SOA reference architecture can help you lay out an SOA environment that meets your needs and priorities. The ESB is part of this reference architecture and provides the backbone of an SOA but it should not be considered an SOA by itself.
15. In SOA do we need to build systems from scratch?
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.
16. What’s the difference between services and components?
Services are logical grouping of components to achieve 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.
17. The concept of SOA is nothing new, however why everyone started to talk about SOA only in the recent years?
Yes, I agree the basic concepts of SOA aren’t new, however some technology technology changes in the last 10 years made service-oriented architecture more practical and applicable to more organizations than it was previously. Among this:
1. Universally-accepted industry standards such as XML, its many variants, and Web-services standards have contributed to the renewed interest in SOA.
2. Data governance frameworks, which are important to a successful SOA implementation, have well test and refined over the years.
3. A variety of enabling technologies and tools (e.g., modeling, development, infrastructure/middleware, management, and testing) have matured.
4. Understanding of business and business strategies has grown, shifting attention from technology to the people, cultural changes, and process that are key business success factors.
18. What is the most important skill you need to adopt SOA? Technical or Cultural?
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.
19. What are the main obstacles in the way of SOA?
1. Shortage of skills.
2. Justifying the ROI of SOA projects.
20. Can I buy an SOA or must I build one?
To move your organization toward greater service orientation, you need to take a balanced approach to building versus buying. To create the infrastructure for an SOA, you'll need the right commercial off-the-shelf software that complements (rather than replaces) your existing IT infrastructure. This is a “buy” statement. On the “build” side, you may also choose to access know-how and hands-on involvement to use these software products effectively and get the most out of them. This infrastructure and the associated tools can help you create the business services that run on your SOA. Again, there is some “building” associated with this. So the real answer is that you need a certain measure of both building and buying.
21. Do I need SOA Governance to get started?
A key aspect of successful SOA implementations is having business involved in the effort from the beginning. One of the values from SOA you can gain is improved Business/IT Alignment. SOA Governance supplies the decision rights, processes, and policies for business and IT to work together. After a service is deployed, there must be management aspects in place to control and monitor the service. You do not need a lot of SOA Governance to get started, but enough to work with the level of Smart SOA you are implementing.
22. What are SOA Entry Points?
To get started quickly with SOA, you need to select an initial project that focuses on a particular business opportunity that can be completed in a reasonably short time frame. The SOA Entry points are project areas that have been shown to provide business value in a timely manner. Each Entry Point provides a key SOA related solution:
People - collaboration improving productivity by giving employees and partners the ability to create a personalized, consolidated way to interact with others.
Process - optimize and deploy processes on the fly and monitor the effectiveness of the altered processes.
Information - improve business insight and reduce risk by using trusted information services delivered in line and in context.
Reuse - newly created and reusable services are the building blocks of SOA. Reuse gives users flexibility through reduced cycle time and elimination of duplicate processes.
Connectivity - although, in the past, connectivity has been a requirement, SOA brings new levels of flexibility to these linkages. The connectivity provided by SOA has distinct value on its own and as a building block for additional SOA initiatives.
23. What are the common pitfalls of SOA?
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 time-frame or to offer a compelling return on investment.
24. Is SOA really needed on your opinion?
SOA is not for everyone. While SOA delivers significant benefits and cost savings, SOA does require disciplined enforcement of centralized governance principals to be successful. For some organizations, the cost of developing and enforcing these principals may be higher than the benefits realized, and therefore not a sound initiative.