SOAP
1. What is a Web service, and how does it relate to SOAP? (Hint: SOAP is the protocol.)
2. What is a common transport for SOAP messages? (Hint: HTTP )
3. What is WSDL? How would you use a WSDL file? (Hint: XML description of Web Service: interface and how to bind to it. )
4. With new J2EE SOAP support what is: JAXR, JAX-RPC, and SAAJ? (Hint: registry, rpc, attachments)
REST
1. What is differences between RESTful web services and SOAP web services ?
Ans:Though both RESTful web series and SOAP web service can operate cross platform they are architecturally different to each other, here is some of differences between REST and SOAP:
1) REST is more simple and easy to use than SOAP. REST language is based on use of nouns and verbs (better readability)
2) REST uses HTTP protocol for producing or consuming web services while SOAP uses XML.
4) REST supports different format like text, JSON and XML while SOAP only support XML.
POST - acceptRepresention()
PUT - storeRepresention()
DELETE - removeRepresention()
5) SOAP based reads cannot be cached. REST based reads can be cached. Performs and scales better.
6) Different error handling:
REST: requires HTTP error handling
SOAP: can have user defined error
7) REST only supports synchronous message because of its reliance of HTTP and HTTPS
8) SOAP WS supports both SSL security and WS-security, which adds some enterprise security features like maintaining security right up to the point where it is needed, maintaining identities through intermediaries and not just point to point SSL only, securing different parts of the message with different security algorithms, etc.
The REST supports only point-to-point SSL security. The SSL encrypts the whole message, whether all of it is sensitive or not.
9) The SOAP has comprehensive support for both ACID based transaction management for short-lived transactions and compensation based transaction management for long-running transactions. It also supports two-phase commit across distributed resources.
The REST supports transactions, but it is neither ACID compliant nor can provide two phase commit across distributed transactional resources as it is limited by its HTTP protocol.
10) The SOAP has success or retry logic built in and provides end-to-end reliability even through SOAP intermediaries. REST does not have a standard messaging system, and expects clients invoking the service to deal with communication failures by retrying.
2. What is REST and RESTful web services?
Ans:This is the first REST interview question on most of interviews as not everybody familiar with REST and also start discussion based on candidates response. Anyway REST stands for REpresentational State Transfer (REST) its a relatively new concept of writing web services which enforces a stateless client server design where web services are treated as resource and can be accessed and identified by there URL unlike SOAP web services which were defined by WSDL.
Web services written by apply REST Architectural concept are called RESTful web services which focus on System resources and how state of Resource should be transferred over http protocol to a different clients written in different languages. In RESTful web services http methods like GET, PUT, POST and DELETE can can be used to perform CRUD operations.
3.What is difference between top-down and bottom-up approach of developing web services ?
Ans:In top-down approach first WSDL document is created and than Java classes are developed based on WSDL contract, so if WSDL contract changes you got to change your Java classes while in case of bottom up approach of web service development you first create Java code and then use annotations like @WebService to specify contract or interface and WSDL field will be automatically generated from your build.
4.What happens if RestFull resources are accessed by multiple clients ? do you need to make it thread-safe?
Ans:Since a new Resource instance is created for every incoming Request there is no need to make it thread-safe or add synchronization. Multiple clients can safely access RestFull resources concurrently.
5.What will you do when an error code has to be returned to the client
OR
How will you handle application error scenarios in RESTful web service?
6.What is a web service?
Ans:A Web service is a method of communication between two electronic devices over the Web (Internet). The W3C defines a "Web service" as "a software system designed to support interoperable machine-to-machine interaction over a network". It has an interface described in a machine-processable format (specifically Web Services Description Language, known by the acronym WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XMLserialization in conjunction with other Web-related standards."
7.Can I use GET request instead of PUT to create resources?
Ans:No, you are supposed to use PUT or POST. GET operations should only have view rights.
8.What all kind of output formats can one generate using RESTful web service?
9.What all tools have you used to write RESTful web service?
10.What is meant by JAX-WS and JAX-RS?
Ans:Java API for XML Web Services(JAX-WS)
Java API for RESTful Web Services (JAX-RS)
11.What are the different application integration styles?
Ans. There are a number of different integration styles like
1. Shared database
2. batch file transfer
3. Invoking remote procedures (RPC)
4. Exchanging asynchronous messages over a message oriented middle-ware (MOM).
1. What is a Web service, and how does it relate to SOAP? (Hint: SOAP is the protocol.)
2. What is a common transport for SOAP messages? (Hint: HTTP )
3. What is WSDL? How would you use a WSDL file? (Hint: XML description of Web Service: interface and how to bind to it. )
4. With new J2EE SOAP support what is: JAXR, JAX-RPC, and SAAJ? (Hint: registry, rpc, attachments)
REST
1. What is differences between RESTful web services and SOAP web services ?
Ans:Though both RESTful web series and SOAP web service can operate cross platform they are architecturally different to each other, here is some of differences between REST and SOAP:
1) REST is more simple and easy to use than SOAP. REST language is based on use of nouns and verbs (better readability)
2) REST uses HTTP protocol for producing or consuming web services while SOAP uses XML.
- The SOAP WS is transport protocol neutral. Supports multiple protocols like HTTP(S), Messaging, TCP, UDP SMTP, etc.
- The REST is transport protocol specific. Supports only HTTP or HTTPS protocols.
4) REST supports different format like text, JSON and XML while SOAP only support XML.
- The SOAP WS permits only XML data format.You define operations, which tunnels through the POST. The focus is on accessing the named operations and exposing the application logic as a service.
- The REST permits multiple data formats like XML, JSON data, text, HTML, etc. Any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE Web operations. The focus is on accessing the named resources and exposing the data as a service. REST has AJAX support. It can use the XMLHttpRequest object. Good for stateless CRUD (Create, Read, Update, and Delete) operations.
POST - acceptRepresention()
PUT - storeRepresention()
DELETE - removeRepresention()
5) SOAP based reads cannot be cached. REST based reads can be cached. Performs and scales better.
6) Different error handling:
REST: requires HTTP error handling
SOAP: can have user defined error
7) REST only supports synchronous message because of its reliance of HTTP and HTTPS
8) SOAP WS supports both SSL security and WS-security, which adds some enterprise security features like maintaining security right up to the point where it is needed, maintaining identities through intermediaries and not just point to point SSL only, securing different parts of the message with different security algorithms, etc.
The REST supports only point-to-point SSL security. The SSL encrypts the whole message, whether all of it is sensitive or not.
9) The SOAP has comprehensive support for both ACID based transaction management for short-lived transactions and compensation based transaction management for long-running transactions. It also supports two-phase commit across distributed resources.
The REST supports transactions, but it is neither ACID compliant nor can provide two phase commit across distributed transactional resources as it is limited by its HTTP protocol.
10) The SOAP has success or retry logic built in and provides end-to-end reliability even through SOAP intermediaries. REST does not have a standard messaging system, and expects clients invoking the service to deal with communication failures by retrying.
2. What is REST and RESTful web services?
Ans:This is the first REST interview question on most of interviews as not everybody familiar with REST and also start discussion based on candidates response. Anyway REST stands for REpresentational State Transfer (REST) its a relatively new concept of writing web services which enforces a stateless client server design where web services are treated as resource and can be accessed and identified by there URL unlike SOAP web services which were defined by WSDL.
Web services written by apply REST Architectural concept are called RESTful web services which focus on System resources and how state of Resource should be transferred over http protocol to a different clients written in different languages. In RESTful web services http methods like GET, PUT, POST and DELETE can can be used to perform CRUD operations.
3.What is difference between top-down and bottom-up approach of developing web services ?
Ans:In top-down approach first WSDL document is created and than Java classes are developed based on WSDL contract, so if WSDL contract changes you got to change your Java classes while in case of bottom up approach of web service development you first create Java code and then use annotations like @WebService to specify contract or interface and WSDL field will be automatically generated from your build.
4.What happens if RestFull resources are accessed by multiple clients ? do you need to make it thread-safe?
Ans:Since a new Resource instance is created for every incoming Request there is no need to make it thread-safe or add synchronization. Multiple clients can safely access RestFull resources concurrently.
5.What will you do when an error code has to be returned to the client
OR
How will you handle application error scenarios in RESTful web service?
6.What is a web service?
Ans:A Web service is a method of communication between two electronic devices over the Web (Internet). The W3C defines a "Web service" as "a software system designed to support interoperable machine-to-machine interaction over a network". It has an interface described in a machine-processable format (specifically Web Services Description Language, known by the acronym WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XMLserialization in conjunction with other Web-related standards."
7.Can I use GET request instead of PUT to create resources?
Ans:No, you are supposed to use PUT or POST. GET operations should only have view rights.
8.What all kind of output formats can one generate using RESTful web service?
9.What all tools have you used to write RESTful web service?
10.What is meant by JAX-WS and JAX-RS?
Ans:Java API for XML Web Services(JAX-WS)
Java API for RESTful Web Services (JAX-RS)
11.What are the different application integration styles?
Ans. There are a number of different integration styles like
1. Shared database
2. batch file transfer
3. Invoking remote procedures (RPC)
4. Exchanging asynchronous messages over a message oriented middle-ware (MOM).
12.What are the different styles of Web Services used for application integration?
Ans. SOAP WS and RESTful Web Service
13.How would you decide what style of Web Service to use? SOAP WS or REST?
Ans. In general, a REST based Web service is preferred due to its simplicity, performance, scalability, and support for multiple data formats. SOAP is favored where service requires comprehensive support for security and transactional reliability.
The answer really depends on the functional and non-functional requirements. Asking the questions listed below will help you choose.
14. What tools do you use to test your Web Services?
Ans:SoapUI tool for SOAP WS and the Firefox "poster" plugin for RESTFul services.
15.What is the difference between SOA and a Web service?
Ans:SOA is a software design principle and an architectural pattern for implementing loosely coupled, reusable and coarse grained services. You can implement SOA using any protocols such as HTTP, HTTPS, JMS, SMTP, RMI, IIOP (i.e. EJB uses IIOP), RPC etc. Messages can be in XML or Data Transfer Objects (DTOs).
Web service is an implementation technology and one of the ways to implement SOA. You can build SOA based applications without using Web services – for example by using other traditional technologies like Java RMI, EJB, JMS based messaging, etc. But what Web services offer is the standards based and platform-independent service via HTTP, XML, SOAP, WSDL and UDDI, thus allowing interoperability between heterogeneous technologies such as J2EE and .NET.
16.Web services when you can use traditional style middle-ware such as RPC, CORBA, RMI and DCOM?
Ans:The traditional middle-wares tightly couple connections to the applications and it can break if you make any modification to your application. Tightly coupled applications are hard to maintain and less reusable. Generally do not support heterogeneity. Do not work across Internet. Can be more expensive and hard to use.
Web Services support loosely coupled connections. The interface of the Web service provides a layer of abstraction between the client and the server. The loosely coupled applications reduce the cost of maintenance and increases re-usability. Web Services present a new form of middle-ware based on XML and Web. Web services are language and platform independent. You can develop a Web service using any language and deploy it on to any platform, from small device to the largest supercomputer. Web service uses language neutral protocols such as HTTP and communicates between disparate applications by passing XML messages to each other via a Web API. Do work across internet, less expensive and easier to use.
17.What are the different approaches to developing a SOAP based Web service?
Ans. Following are the two approaches.
18.What are the pros and cons of each approach, and which approach would you prefer?
Ans:
Contract-first Web service
PROS:
PROS:
19.So, which approach will you choose?
Ans:The best practice is to use "contract-first", and here is the link that explains this much better with examples --> contract-first versus contract-last web services In a nutshell, the contract-last is more fragile than the "contract-first". You will have to decide what is most appropriate based on your requirements, tool sets you use, etc.
20.How will you migrate from SOAP web service to RESTfull web service?
21.Can you describe any one RESTful web service you have written?
22.Is it mandatory to use HTTP protocol for performing CRUD operations by a REST based web service?
23.Can one RESTful web service be a client to another RESTful web service for performing business operations? Describe with example?
24.Can you generate HTML output from a RESTful web service? How?
25.Can a RESTful web service generate output in various formats based on some parameter received from the client.
26.With a RESTful web service, whose state is getting transferred and how?
27.Who owns the specification for REST web services and how does it get updated to newer versions?
Also refer:
http://java-success.blogspot.com.au/2012/11/soap-versus-restful-web-service.html
SOA
1.What are the main benefits of SOA ?
Ans:
2.What is a reusable Service?
Ans:
3.Talking about Service identification, which approach between top-down and bottom-up methodologies encourages re-use and mantainance ?
Ans: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. Anyway
4.How can you achieve loose coupling in a soa ?
Ans: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
5.Do you recall any pattern which could be used to leverage loose coupling ?
Ans: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.
6.The Service of a SOA should be engineered as stateless or stateful ?
Ans: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.
7.What is composition of a Service ?
Ans: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.
8.How do I integrate my Legacy applications with SOA ?
Ans: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.
9.How does the ESB fits in this picture ?
Ans: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.
10.What are the common pitfalls of SOA ?
Ans: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.
11.What’s the difference between services and components?
Ans: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.
12.What are ends, contract, address, and bindings?
Ans: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:-
13.The concept of SOA is nothing new, however why everyone started to talk about SOA only in the last years ?
Ans:Yes I agree the basic concept 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:
14.What is the most important skill you need to adopt SOA ? technical or cultural ?
Ans: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.
15.Is SOA really needed on your opinion?
Ans: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.
Ans. SOAP WS and RESTful Web Service
13.How would you decide what style of Web Service to use? SOAP WS or REST?
Ans. In general, a REST based Web service is preferred due to its simplicity, performance, scalability, and support for multiple data formats. SOAP is favored where service requires comprehensive support for security and transactional reliability.
The answer really depends on the functional and non-functional requirements. Asking the questions listed below will help you choose.
- Does the service expose data or business logic? (REST is a better choice for exposing data, SOAP WS might be a better choice for logic).Do the consumers and the service providers require a formal contract? (SOAP has a formal contract via WSDL)
- Do we need to support multiple data formats?
- Do we need to make AJAX calls? (REST can use the XMLHttpRequest)
- Is the call synchronous or asynchronous?
- Is the call stateful or stateless? (REST is suited for stateless CRUD operations)
- What level of security is required? (SOAP WS has better support for security)
- What level of transaction support is required? (SOAP WS has better support for transaction management)
- Do we have limited band width? (SOAP is more verbose)
- What’s best for the developers who will build clients for the service? (REST is easier to implement, test, and maintain)
14. What tools do you use to test your Web Services?
Ans:SoapUI tool for SOAP WS and the Firefox "poster" plugin for RESTFul services.
15.What is the difference between SOA and a Web service?
Ans:SOA is a software design principle and an architectural pattern for implementing loosely coupled, reusable and coarse grained services. You can implement SOA using any protocols such as HTTP, HTTPS, JMS, SMTP, RMI, IIOP (i.e. EJB uses IIOP), RPC etc. Messages can be in XML or Data Transfer Objects (DTOs).
Web service is an implementation technology and one of the ways to implement SOA. You can build SOA based applications without using Web services – for example by using other traditional technologies like Java RMI, EJB, JMS based messaging, etc. But what Web services offer is the standards based and platform-independent service via HTTP, XML, SOAP, WSDL and UDDI, thus allowing interoperability between heterogeneous technologies such as J2EE and .NET.
16.Web services when you can use traditional style middle-ware such as RPC, CORBA, RMI and DCOM?
Ans:The traditional middle-wares tightly couple connections to the applications and it can break if you make any modification to your application. Tightly coupled applications are hard to maintain and less reusable. Generally do not support heterogeneity. Do not work across Internet. Can be more expensive and hard to use.
Web Services support loosely coupled connections. The interface of the Web service provides a layer of abstraction between the client and the server. The loosely coupled applications reduce the cost of maintenance and increases re-usability. Web Services present a new form of middle-ware based on XML and Web. Web services are language and platform independent. You can develop a Web service using any language and deploy it on to any platform, from small device to the largest supercomputer. Web service uses language neutral protocols such as HTTP and communicates between disparate applications by passing XML messages to each other via a Web API. Do work across internet, less expensive and easier to use.
17.What are the different approaches to developing a SOAP based Web service?
Ans. Following are the two approaches.
- The contract-first approach, where you define the contract first with XSD and WSDL and the generate the Java classes from the contract.
- The contract-last approach where you define the Java classes first and then generate the contract, which is the WSDL file from the Java classes.
18.What are the pros and cons of each approach, and which approach would you prefer?
Ans:
Contract-first Web service
PROS:
- Clients are decoupled from the server, hence the implementation logic can be revised on the server without affecting the clients.
- Developers can work simultaneously on client and server side based on the contract both agreed on.
- You have full control over how the request and response messages are constructed -- for example, should "status" go as an element or as an attribute? The contract clearly defines it. You can change OXM (i.e. Object to XML Mapping) libraries without having to worry if the "status" would be generated as "attribute" instead of an element. Potentially, even Web service frameworks and tool kits can be changed as well from say Apache Axis to Apache CXF, etc
- More upfront work is involved in setting up the XSDs and WSDLs. There are tools like XML Spy, Oxygen XML, etc to make things easier. The object models need to be written as well.
- Developers need to learn XSDs and WSDLs in addition to just knowing Java.
PROS:
- Developers don't have to learn anything related to XSDs, WSDLs, and SOAP. The services are created quickly by exposing the existing service logic with frameworks/tool sets. For example, via IDE based wizards, etc.
- The learning curve and development time can be smaller compared to the Contract-first Web service.
- The development time can be shorter to initially develop it, but what about the on going maintenance and extension time if the contract changes or new elements need to be added? In this approach, since the clients and servers are more tightly coupled, the future changes may break the client contract and affect all clients or require the services to be properly versioned and managed.
- In this approach, The XML payloads cannot be controlled. This means changing your OXM libraries could cause something that used to be an element to become an attribute with the change of the OXM.
19.So, which approach will you choose?
Ans:The best practice is to use "contract-first", and here is the link that explains this much better with examples --> contract-first versus contract-last web services In a nutshell, the contract-last is more fragile than the "contract-first". You will have to decide what is most appropriate based on your requirements, tool sets you use, etc.
20.How will you migrate from SOAP web service to RESTfull web service?
21.Can you describe any one RESTful web service you have written?
22.Is it mandatory to use HTTP protocol for performing CRUD operations by a REST based web service?
23.Can one RESTful web service be a client to another RESTful web service for performing business operations? Describe with example?
24.Can you generate HTML output from a RESTful web service? How?
25.Can a RESTful web service generate output in various formats based on some parameter received from the client.
26.With a RESTful web service, whose state is getting transferred and how?
27.Who owns the specification for REST web services and how does it get updated to newer versions?
Also refer:
http://java-success.blogspot.com.au/2012/11/soap-versus-restful-web-service.html
SOA
1.What are the main benefits of SOA ?
Ans:
- 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
2.What is a reusable Service?
Ans:
- 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.
3.Talking about Service identification, which approach between top-down and bottom-up methodologies encourages re-use and mantainance ?
Ans: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. Anyway
4.How can you achieve loose coupling in a soa ?
Ans: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
5.Do you recall any pattern which could be used to leverage loose coupling ?
Ans: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.
6.The Service of a SOA should be engineered as stateless or stateful ?
Ans: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.
7.What is composition of a Service ?
Ans: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.
8.How do I integrate my Legacy applications with SOA ?
Ans: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.
9.How does the ESB fits in this picture ?
Ans: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.
10.What are the common pitfalls of SOA ?
Ans: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.
11.What’s the difference between services and components?
Ans: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.
12.What are ends, contract, address, and bindings?
Ans: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.
13.The concept of SOA is nothing new, however why everyone started to talk about SOA only in the last years ?
Ans:Yes I agree the basic concept 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:
- Universally-accepted industry standards such as XML, its many variants, and Web-services standards have contributed to the renewed interest in SOA.
- Data governance frameworks, which are important to a successful SOA implementation, have well test and refined over the years.
- A variety of enabling technologies and tools (e.g., modeling, development, infrastructure/middleware, management, and testing) have matured.
- 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.
14.What is the most important skill you need to adopt SOA ? technical or cultural ?
Ans: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.
15.Is SOA really needed on your opinion?
Ans: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.