A web service is a network accessible interface to application functionality, built using standard Internet technologies. It is software application that can be accessed remotely using different XML-based languages. Normally, a web service is identified by a URL,just like any other Web site. What makes web services different from ordinary Web sites is the type of interaction that they can provide.
A web service is a very well known open technology standard provides a number of benefits including:
- Increase competition among vendors, resulting in lower product costs.
- Ease transition from one product to another, resulting in lower training costs.
- Increase the ability for parties to interoperate, resulting in lower maintenance costs.
- Ensure a greater degree of adoption and longevity for a standard. A large degree of usage from the vendors and the users leads to a higher degree of acceptance.
There are three main ways in which an organization can move deploy web services. These are as follows:
- Creating a new web service from scratch (Contract First): The developer creates the functionalities of the services as well as preparing a document to describe those services.
- Exposing an existing functionality through a web service (Code First): Here, the functionalities of the service already exist. Only the service description needs to be implemented.
- Integrating web services from other vendors or business partners (Meet in the Middle): There are instances where using a service implemented by another is more feasible than building from scratch. On these occasions, the organization will be required to integrate others' or even business partners' Web Services.
The real utility of the web service concept is present in the second and the third methods, which leads to other web services and applications that can be used in existing applications.
SOA and web services are two different things, but web services are the preferred standards-based way to realize SOA. Service-oriented architecture (SOA) is an architectural style for building software applications that use services available in a network such as the web. It promotes loose coupling between software components so that they can be reused. Applications in SOA are built based on services. A service is an implementation of well-defined business functionality, and such services can then be consumed by clients in different applications or business processes.
As SOA promotes loose coupling it obviously allows reuse of existing assets where new services can be created from an existing IT infrastructure of systems. In other words, it enables businesses to leverage existing investments by allowing them to reuse existing applications, and promises interoperability between heterogeneous applications and technologies. SOA provides a level of flexibility that wasn't possible before in the sense that:
- Services are software components with well-defined interfaces that are implementation-independent. An important aspect of SOA is the separation of the service interface (the what) from its implementation (the how). Such services are consumed by clients that are not concerned with how these services will execute their requests.
- Services are self-contained (perform predetermined tasks) and loosely coupled (for independence).
- Services can be dynamically discovered.
- Composite services can be built from aggregates of other services.
SOA uses the find-bind-execute paradigm as shown in Figure 1. In this paradigm, service providers register their service in a public registry. This registry is used by consumers to find services that match certain criteria. If the registry has such a service, it provides the consumer with a contract and an endpoint address for that service.
SOA-based applications are distributed multi-tier applications that have presentation, business logic, and persistence layers. Services are the building blocks of SOA applications. While any functionality can be made into a service, the challenge is to define a service interface that is at the right level of abstraction. Services should provide coarse-grained functionality.
Web services are software systems designed to support interoperable machine-to-machine interaction over a network. This interoperability is gained through a set of XML-based open standards, such as WSDL, SOAP, and UDDI.
Interoperability is the most important principle of SOA. This can be realized through the use of web services, as one of the key benefits of web services is interoperability, which allows different distributed web services to run on a variety of software platforms and hardware architectures. The advent of web services and SOA offers potential for lower integration costs and greater flexibility. An important aspect of SOA is the separation of the service interface (the what) from its implementation (the how). Such services are consumed by clients that are not concerned with how these services will execute their requests. Web services are the next step in the Web's evolution, since they promise the infrastructure and tools for automation of business-to-business relationships over the Internet.
REST is definitely the trendy way to create a web service, if creating web services could ever be trendy (let's face it you use soap to wash, and you rest when you are tired). The main advantages of REST web services are:
- Lightweight - not a lot of extra xml markup
- Human Readable Results
- Easy to build - no toolkits required
SOAP also has some advantages:
- Easy to consume - sometimes
- Rigid - type checking, adheres to a contract
- Development tools
For consuming web services, it is sometimes a tossup between which is easier. For instance Google's Ad Words web service is really hard to consume, as it uses SOAP headers, and a number of other things that make it kind of difficult. On the converse, Amazon's REST web service can sometimes be tricky to parse because it can be highly nested, and the result schema can vary quite a bit based on what you search for.
While you can certainly leverage a cloud without practicing SOA, and you can leverage SOA without leveraging cloud computing, the real value of cloud computing is the ability to use services, data, and processes that can exist outside of the firewall in somebody else's datacenter. Indeed, one can consider cloud computing the extension of SOA out to cloud-delivered resources, such as storage-as-a-service, data-as-a-service, platform-as-a-service. The trick is to determine which services, information, and processes are good candidates to reside in the clouds as well as which cloud services should be abstracted within the existing or emerging SOA. SOA not only is a mechanism to drive more reuse and agility but also offers the ability to figure out what should stay local and what should find a place in the clouds. Good SOA leads to a good cloud computing strategy, which leads to reduced costs, enhanced agility, and more excitement around enterprise computing than we have seen in a while.
Service Design - Many SOA projects have a tendency to build in services that are too course-grained, too fine-grained, or just not at all well designed. In reality, unless services are not well defined and well designed, they will not sell well when delivered on demand. The major cloud computing providers, who provide services through the cloud, spends a lot of time on the design of the services, including usability and durability.
Service Expandability - Cloud computing services are designed to expand as needed, and those who leverage cloud services do so because they can get the services on demand, when they need them.
Google App Engine lets you run your web applications on Google's infrastructure. It provide both development community and the enterprise-computing space. App Engine applications are easy to build, easy to maintain.
The App Engine enables you to build enterprise-scalable applications on the same infrastructure that Google uses.
App Engine is structured differently from the typical web application server. At its core, App Engine restricts your application from any access to the physical infrastructure, preventing you from opening sockets, running background processes (although you can use cron), and using other common back-end routines that application developers take for granted in other environments.
App Engine costs nothing to get started. All applications can use up to 500 MB of storage and enough CPU and bandwidth to support an efficient app serving around 5 million page views a month, absolutely free. When you enable billing for your application, your free limits are raised, and you only pay for resources you use above the free levels.