For example, consider Figure 3. In this case, the service controller could be a process engine that implements an end-to-end automated use case. The inventory management system provides services, namely "GetResourceDetails" and "SetResourceDetails." The details of the contract specification for each of these services are stored in the service catalogue. It is possible for the process running in the service controller to verify if a specific resource is available in the network inventory using the GetResourceDetails service, and then to set the status of the appropriate resource using SetResourceDetails. The service controller looks up the service details in the service catalogue, which could potentially be realized using UDDI. In this case, the service controller invokes the specific services by publishing events or messages on the integration media. It is possible to use a middleware (like TIBCO) for realizing the integration media, and SOAP/XML messages/events can be published to initiate the services.

Myth #5: Any software development using Web services is aligned with SOA
Web services, coupled with the other relevant tools and technologies, offer one option that can be used to build and realize an SOA solution. However, a solution cannot be classified as SOA just by virtue of being built using Web services. A solution is compliant with SOA if it meets the following requirements:

• Interaction between service providers and consumers
• Usage of service contracts
• Usage of metadata

Myth #6: Each service is always atomic in nature
Services in the context of SOA represent the functionality provided by software assets. These services, when invoked, perform a specific task. At the lowest level, these services are mapped to a specific task. The services that always perform one atomic task are referred to as "leaf" services. The services that are created by the federation of other services are called as "composite" services. In other words, it is possible to define services in the SOA context, which are in turn composed of other SOA atomic services. Figure 4 shows that there are three atomic services (namely ProvisionCustomerInCRM, ProvisionCustomerinBilling, and ProvisionCustomerInInventory). Each of these services provisions the customer in the specified subsystem - for example, the ProvisionCustomerInCRM provisions the customer in the CRM (customer relationship management) subsystem, and so on. However, these atomic services are aggregated and a new composite service is created, called as ProvisionCustomer, which basically provisions the customer in all three subsystems.

Myth #7: SOA is not aligned with any standards
SOA is based on several industry-standard initiatives, namely the OASIS working group, the Web services standards bodies, and so on. Figure 5 shows the exact scenario of the associated standards body.

Myth #8: SOA is the same as EAI
There is a general misconception that SOA is the same as enterprise application integration (EAI). EAI is the integration approach in which various applications are integrated using a middleware, through the use of a set of connectors (or adapters). These adapters provide access to and exposure of all of the atomic interfaces of the underlying applications.

However, SOA is not the same as EAI. SOA is based on service aggregation that is based on functionality, and not on atomic APIs. SOA can be visualized as a further evolution of EAI, as shown in Figure 6.

SOA advocates integration based on services rather than on atomic APIs. SOA integration is similar to a richer form of ESB (enterprise service bus) integration, and represents a significant evolution from traditional EAI integration. Using SOA as an architectural approach results in significant improvement in the performance, flexibility, usability, and TCO (total cost of ownership) of the overall solution.

SOA is more sophisticated than "classical/traditional" EAI in several ways. First, SOA provides an aggregation capability (support for composite services) that is lacking in EAI. EAI deals with basic atomic APIs and data. Second, SOA provides support to work with service-level data, whereas EAI always deals with application integration using atomic API (application programming interface). Also, most important, SOA provides support for transformations and mappings, whereas EAI does not support these directly. Keeping all this in mind, it is possible to say that SOA is a more advanced architectural methodology.

Myth #9: SOA is a very expensive solution
SOA solutions are deployed in an evolutionary, stepwise manner that requires incremental investments. However, the framework allows for the consistency across the incremental solution.

The cost of the solution depends on several factors, among which the level of automation and the level of sophistication required in the solution are foremost. It is possible to arrive at a reasonable level of automation, and design and build an SOA solution that is cost-effective. Also, the cost depends on the choice of the other parameters such as the technology chosen, the products chosen (in case of green-field customers), and so on. All of the factors that contribute to the cost need to be considered carefully, and appropriate choices need to be made in order to reduce the cost. By doing so, it is possible to build a reasonably feature-rich and yet cheap solution. The enterprise architecture plays a crucial role in the SOA roadmap for the enterprise and precedes any major commitments. The concept of service and a means of interaction are more important than changing technologies overnight.

Myth #10: SOA solution components (services, contracts, and data model) are completely reusable
SOA strives for the highest possible amount of reuse, and the amount of reuse achievable increases over time.

In terms of the service, a large amount of reuse is possible in the technology-neutral representation. However, as the implementation is associated with the chosen technology, the reuse is limited if the technology is changed. However, when newer services are designed using existing services, a large amount of reuse is possible. In any case, the learning and the knowledge can definitely be reused, in addition to possible code reuse.