SOA interview questions
- Published: 04 April 2009
Here's a collection of SOA interview questions which could be useful before going for a technical interview.
SOA Interview questions
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
How do you transform an Enterprise business in a SOA ?
Transforming an enterprise business to Service Oriented Architecture includes obtaining standardized service contract, service reusability, service abstraction, service loose coupling, service composability 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.
How do you map your Organization Roles in order to promote SOA ?
Enterprise architect: It is his responsibility to ensure that SOA endeavors are in venture with business goals, and that the SOA is expanding business readiness. He will translate business goals into general SOA objectives, set the overall direction of the SOA, and guarantee that the work progresses within the established architecture for the organization.
Solutions architect: Solutions architects generally report to the enterprise architect or CTO, and may have pretty much of a hands-on part, depending on the size of the company. Solutions architects are truly interpreters between business objectives and designs that can fulfill those objectives, and they consult with both the management and technical sides of the house to architect a solution. They may assist in vendor selection and focus on business integration, making sure that their solutions are aligned with all impacted business domains.
Technical architect: Technical architects fall right amidst the SOA, as they work closely with the solutions architect, business analysts, service infrastructure administrators, and service developers to identify viable technical specifications that conform to the needs of all of these different areas.
This is a technical role, deepening the contours suggested by the solutions architect’s work product. They must be sharply aware of SOA technology options, as well as fundamentals like network technology, infrastructure support technology, and so on.
Technical architects should have deep knowledge of the products in use. Just as the solutions architect is the translator between the business and the architecture,technical architects are the translators between everyone at the technology level in order to determine an appropriate architecture that’s ready to be implemented by the service developers.
Developer: Service developers work with technical architects to implement services. IDE. They work with the network administrators to ensure the safe arrival of the services into production. They may also support and maintain services after they are developed.
Service administrators: Service administrators’ primary tools are the registry and repository. They ensure that services are available and documentation is correct. They may serve with architects on a change control or governance board, and they keep on top of versioning and availability.
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.
Talking about Service identification, which approach between top-down and bottom-up methodologies best fits with a SOA ?
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.
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.
- Next >>