This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
As a general description WS offer a new and growing standard for building distributed network applications. They are available services that are offered via the internet that use standardized Extensible Mark-up Language (XML ) - specification for meaningful structure of data- messaging system which is used to encode all communications to a Web service. (Bell et al. 2007) WS are simple standards that work independently, regardless of communication platforms, systems and any programming language or operating system. These services can be accessed from different devices, networks or operating systems.
W3C says: “a Web service is a software system designed to support interoperable machine-to-machine interaction over a network”.
Bell, D, Cesare, S, Iacovelli, N, Lycett, M, and Merico, A. ‘A framework for deriving semantic Web Services' Information Systems Frontiers 9, 1 (Mar. 2007)
A Web Service is a programmable application that can be created by standard Internet protocols. Web Services has ability to represent web functionality in different websites without having knowledge of the services implementation by combining the best characteristics of the Web and component based development. (san diego media)
In the marketplace Web Services are establishing its importance as a mechanism for efficient development integration in the enterprise. In creating Web services for individual business networks it is important to grow the scope of services beyond the limit of firewall. Individuals can offer services to business partners, customers, and subscribers. It allows service users to become integral parts of the service provider organizations.
(An introduction to Web Services Gateway http://www.ibm.com/developerworks/webservices/library/ws-gateway/ 31/12/09 01:14)
Nowadays Web Service technology operates almost any current IT environments. Here are some definitive characteristics of Web services.
- Accessibility of Web services over the Web. Web Services are language neutral and platform independent communication web protocols. These protocols certify easy integration of various environments.
- Web Services provide interface. Web Service Interface can be used by other web applications, this programming interface can be invoked from any client or service of other applications. The Web Service interface combines the logic that implements the service between actual application and Web.
- A registered Web Service can be located through a Web Service Registry. Web service registry allows consumers to find their required services.
- Web Services support insecurely links between connected systems. The Web Services communicate between each other by sending messages. The connection between Web services make adaptable and flexible by adding an abstraction layer to be environment.
(Introduction to web services san diego media http://www.sandiegomedia.com/webservices-intro 30/12/09 18:21)
History of WS
Web Service is a service that allows applications to communicate using a set of technologies with other applications over a network. There are certain objectives that have to be met in order to run Web Services:
- Platform agnostic. The infrastructure of Web Services must be supported by the traders in order to meet same specifications.
- Language agnostic. A Web Service written in a language must support the specifications for other Web Services in the same fashion as they are written in different languages.
- Free from restrictive Intellectual Property Rights (IPR) terms. The developers of the Web service technologies have to have widespread adoption as their main goal.
The initial names in Web Service development are IBM and Microsoft; these companies had the above objectives in mind in the early years of Web Services development. In the 1990s the development of the World Wide Web (WWW) introduced the importance of how communications and the Information Technology industry can work together to establish a common framework together with defining fundamental protocols such as HTTP and TCP. However, the invention of XML that let developers to establish the Web Services.
As a broadly revealed platform independent standard for data description, XML was a logical basis for the job between services to service communication. In 1998 XML became a standard when W3C declared that XML 1.0 had reached draft recommendation status.
The next step after developing the basic protocols of XML was the agreement on specification for a standardised message passing protocol. Microsoft developed the simple object access protocol (SOAP). SOAP was platform agnostic, general purpose and flexible. In March 2000, IBM supported SOAP and started work together with Microsoft to SOAP 1.1, and in next few months of 2000, SOAP gained wider acceptance.
Microsoft and IBM at the same time were working on a technique in order to describe programmatically how to connect Web Service. A protocol proposal merged after some discussion between Microsoft and IBM. Microsoft offered both SOAP Contract Language and Service Description Language where IBM contributed Network Accessible Service Specification Language. Web Services Description Language (WSDL), was introduced in late 2000.
Companies using WSDL and SOAP could create and describe their Web Services. Microsoft, IBM and Ariba started work to provide a meaningful solution in discovering Web Services in March 2000 and Universal Description Discovery, and Integration (UDDI) version 1.0 Specification was introduced in September 2000.
The standards to create Web Services took place at the end of 2000 after arriving UDDI, SOAP and WSDL. The main IT software companies announced their commitment to Web Services. Microsoft, IBM Oracle, Sun, HP, and BEA assured their intention to support and deploy the Web Services standards in their products.
(An introduction to Web Services Paul Muschamp BT Technology Journal â€¢ Vol 22 No 1 â€¢ January 2004)
Potential user of web services
In this section the business values of distributed computing within a single enterprise has been discussed.
Peer To Peer Computing
Intel uses peer to peer computing to maintain performance of their network. The heavy use on their programming networks made their central network slow and to solve this problem by shifting processing requests to a system where it makes use of caching and peer to peer computing.
In peer to peer computing each request looks for local computers in a well planned order rather than searching from main network. The first requester will get course from the original server and second requester get course form first requester or from original depending on which one is nearer to requester and third requestor needs the course, there are there copies available, potentially bringing the course ever nearer. This system balance automatically and more copies distributed of popular courses that are available throughout the network. New or less famous courses may be still distributed from the central server.
Hub to Node Distributed computing
Boeing uses hub to node distributed computing in order to increase the ability to control their finite element analysis, a process heavy in calculations. Only the first calculations are performed by a central computer. Any request for subsequent levels of analysis is distributed to less powerful computers, even laptops ordesktops, on the network. This permits machines throughout Boeing that would otherwise sit idle to be engaged in these valuable, but time-consuming, calculations.
As the acceptance and utilisation of web services grow, similar operations are being distributed between enterprises, building efficiencies and sharing data throughout a much larger network. Web services provide real advantages to a company in creating increasingly modular and flexible IT systems and in connecting to other companies.
Web services and businesses
The evolution of web services will proceed in small steps and will be driven by the need to improve the flexibility, reliability, performance, and connectivity of enterprise and trans-enterprise scale systems. The viability of the web services approach, the ability to implement a service model incrementally, coupled with the imperative rooted in the cost-driven need for efficiency in IT development and operations and the value-driven need to exploit the advantages of connectivity across organisational boundaries all make the evolution to web services as inevitable as the evolution of organisms when their environment changes. In the IT world, as in the natural world, it is change or perishes.
What should business be doing to get ready for web services? The good news is that web services architectures can be implemented incrementally without tearing out a company's entire infrastructure. While the tools are not quite there yet, the business imperative is strong enough to sustain the effort to conclusion. The best plan of attack is to start building your web services infrastructure now, and roll out viable applications and services one project or business unit at a time. Following this model, your company will build its skill set, develop a proof of concept, and ensure scalability, taking first steps towards a roll out.
Dimension Data is poised to introduce their first web services product, Web Services Framework. Unique in the marketplace, this offering is a fully installed, "plug and play" framework that supplies the necessary web services infrastructure, includingregistryand standards, in a single package. As well, the offering includes a sample application, which can be utilized to build out later web services adapted applications.
(http://www.crm2day.com/content/t6_librarynews_1.php?id=EpuuVkulVuulTTrQJz 25/12/09 22:36)
Web Service Description
Since the Web services approach is centred on the notion of “service”, one of the first issues to be addressed by its technology is what exactly a service is and how it can be described. Service description in conventional middleware is based on interfaces and interface definition languages. In that context, IDL specifications are needed to automatically generate stubs and to constitute the basis for dynamic binding. The semantics of the different operations, the order in which they should be invoked and other (possibly non-functional) properties of the services are assumed to be known in advance by the programmer developing the clients. This is reasonable, since clients and services are often developed by the same team. In addition, the middleware platform defines and constrains many aspects of the service description and binding process that are therefore implicit, and they do not need to be specified as part of the service description. In Web services and B2B interactions, such implicit context is missing. Therefore, service descriptions must be richer and more detailed, covering aspects beyond the mere service interface.
The stack of Figure 5.8 illustrates the different aspects involved in Web services description. The figure essentially shows a stack of languages, where elements at higher levels utilize or further qualify the descriptions provided by elements at the lower levels
Common base language.
The first problem to be addressed is the definition of a common meta-language that can be used as the basis for specifying all the languages necessary to describe the different aspects of a service. XML is used for this purpose, both because it is a widely adopted and commonly accepted standard and because it has a syntax flexible enough to enable the definition of service description languages and protocols.
Interface definition languages are at the base of any service oriented paradigm. In Web services, interface definitions resemble CORBA like IDLs, although there are a few differences between the two. The availability of different interaction modes in the interface definition language and the XML schema-driven type system are two of them. In addition, since (as mentioned above) Web services lack an implicit context (often there is no centralized middleware), their description needs to be more complete. For example, it is necessary to specify the address (URI) of the service and the transport protocol (e.g., HTTP) to use when invoking the service. With this information, it is possible to construct a client that invokes the operations offered by a Web service. The dominant proposal for IDLs in this area is the Web Services Description Language (WSDL) .
A Web service often offers a number of operations that clients must invoke in a certain order to achieve their goals. In the procurement example, the customer will have to first request a quote, then order the goods, and finally make a payment. Such exchanges between clients and Web services are called conversations. Service providers typically want to impose rules that govern the conversation, stating which conversations are valid and understood by the service. This set of rules is specified as part of the so called business protocol supported by the service (where the word “business” is used to differentiate it from a communication protocol). Business protocols are examples of why simple interface description is not enough in Web services. In fact, to completely describe a service, it is necessary to specify not only its interface but also the business protocols that the service supports. In this regard, there are several proposals to standardize the languages for defining business protocols (as opposed to standardizing the protocols, discussed next). Examples are the web Services Conversation Language (WSCL)  and the Business Process Execution Language for Web Services (BPEL) . This is nevertheless a rather immature area in terms of standardization at the time of writing.
Properties and semantics.
Most conventional middleware platforms do not include anything but functional interfaces in the description of a service. Again, this is because the system context allows designers to infer other information needed to bind to a service, and because services are tightly coupled. Web services provide additional layers of information to facilitate binding in autonomous and loosely-coupled settings, where the service description is all that clients have at their disposal to decide whether to use a service or not. For instance, this may include non-functional properties such as the cost or quality of a service, or a textual description of the service such as the return policy when making a purchase. This is information that is crucial for using the service but is not part of what we traditionally understand as the interface of the service. In Web services, such information can be attached to the description of a service by using the Universal Description, Discovery, and Integration (UDDI)  specification. This specification describes how to organize the information about a Web service and how to build repositories where such information can be registered and queried.
All the layers explained so far are generic. They standardize neither the contents of the services nor their semantics (e.g., the meaning of a certain parameter or the effect of a certain operation). Vertical standards define specific interfaces, protocols, properties, and semantics that services offered in certain application domains should support. For example, RosettaNet  describes commercial exchanges in the IT world, standardizing all the aspects described above. These vertical standards complement the previous layers by tailoring them to concrete applications, further facilitating the use of standard tools for driving the exchanges. Specifically, they enable the development of client applications that can interact in a meaningful manner with any Web service that is compliant with a certain vertical standard.
(Web Services - Concepts, Architectures and Applications Gustavo Alonso, Fabio Casati, Harumi Kuno, Vijay Machiraju, Springer Verlag, ISBN 3-540-44008-9 Copyright Springer Verlag Berlin Heidelberg 2004)
Web Services Technologies
This section gives a high-level overview of some of the basic Web services technologies. In this section, we discuss the following concepts that are fundamental in understanding Web services: Web service message syntax (SOAP), Web service discovery and registration technologies, Web service orchestration, Web service security, and technologies that will undoubtedly shape the future of Web services. Although key standards and technologies will be discussed, this is not meant to present an in-depth technical study; instead, it will provide you with an understanding of how these technologies fit together to deliver the benefits of Web services.
XML Web services are the fundamental building blocks in the move to distributed computing on the Internet. Open standards and the focus on communication and collaboration among people and applications have created an environment where XML Web services are becoming the platform for application integration. Applications are constructed using multiple XML Web services from various sources that work together regardless of where they reside or how they were implemented.
There are probably as many definitions of XML Web Service as there are companies building them, but almost all definitions have these things in common:
- XML Web Services expose useful functionality to Web users through a standard Web protocol. In most cases, the protocol used is SOAP.
- XML Web services provide a way to describe their interfaces in enough detail to allow a user to build a client application to talk to them. This description is usually provided in an XML document called a Web Services Description Language (WSDL) document.
- XML Web services are registered so that potential users can find them easily. This is done with Universal Discovery Description and Integration (UDDI).
One of the primary advantages of the XML Web services architecture is that it allows programs written in different languages on different platforms to communicate with each other in a standards -based way. The other significant advantage that XML Web services have over previous efforts is that they work with standard Web protocols-XML, HTTP and TCP/IP. A significant number of companies already have a Web infrastructure, and people with knowledge and experience in maintaining it, so again, the cost of entry for XML Web
Services are significantly less than previous technologies.
XML web services tended to be information sources that you could easily incorporate into applications-stock quotes, weather forecasts, sports scores etc. It's easy to imagine a whole class of applications that could be built to analyze and aggregate the information you care about and present it to you in a variety of ways; for example, you might have a MicrosoftÂ® Excel spreadsheet that summarizes your whole financial picture-stocks, 401K, bank accounts, loans, etc. If this information is available through XML Web services, Excel can update it continuously. Some of this information will be free and some might require a subscription to the service. Most of this information is available now on the Web, but XML Web services will make programmatic access to it easier and more reliable.
(XML Web Services Basics http://msdn.microsoft.com/en-us/library/ms996507.aspx 27/12/09 03:21)
SOA is a technology-independent architectural blueprint for building software applications based on an application front-end service, service repository, and service bus. A service is a software component that consists of an implementation that provides business logic and data; a service contract that specifies the functionality, usage, and constraints for a client of the service; and a service interface that physically exposes the functionality. Application front-ends initiate a business process and receive the results. They can be a GUI (graphical user interface) such as a Web application, a client that interacts directly with end users, or even batch programs. The service repository stores the service contracts of the individual services of an SOA and the service bus interconnects the application front-ends and services.
The focus of SOA is to decouple business applications from technical services and make the enterprise independent of a specific technical implementation or infrastructure. This means that a service (the what) is separated from its implementation (the how). Because SOA promotes independence between business applications and technical services, software components can be reused.
This independence between a service and the execution of that service allows different applications to exchange data and participate in business processes regardless of the operating systems or programming languages underlying those applications. Therefore, SOA is a style of architectural design that facilitates application interoperability.
(Service-oriented Architecture and Web Services; March 2007 Melanie A. Allison Chief Technology Officer CalRHIO)
SOA provides the framework using which the creation and management of integrated systems and applications are simplified and a company's IT assets are aligned with the business model. Some of the ways in which an organization's business infrastructure is benefitted are as follows:
- Productivity and flexibility: SOA leverages the existing systems and applications to become more productive and more profitable to the business. SOA also enables development of new applications with cross-functional capabilities which can interoperate with each other irrespective of the underlying platforms and development language.
- Speed and cost-effectiveness: The design of a service is standardized and one service can be used in multiple applications. Therefore, the services that can be combined into higher-level, composite services as new business needs arise. This lowers the cost of solution development and testing, reduces redundancy, and speeds time to business value.
Manageability and security: SOA enables the consumer applications to access the services and not the applications running behind those services. This provides the means for protecting existing applications without inhibiting the deployment of new capabilities. As a strong authentication and authorization model is used for all services and as services exist independently of one another, the SOA approach provides greater overall security.
The most prevalent way of realizing SOA is using Web services. While SOA provides the principles, Web services provide a strategy using which SOA can be implemented. Web services can also be defined as software systems which support interoperable machine-to-machine interaction over a network. Web services are developed using a set of XML-based open standards, such as Web Service Definition Language (WSDL), Simple Object Access Protocol (SOAP), and Universal Description Discovery and Integration (UDDI). These standards provide a common way for defining, publishing, and using Web services. Web services are created using development environments and deployed on the Application server.
Many companies like Sun, Microsoft, IBM, HP, and others provide tools that enable creation and deployment of Web services.
(Service-Oriented Architecture (SOA) Abhishek Agrawal Director - Business Development, Rightway Solution (India) Pvt. Ltd. www.rightwaysolution.com March 2009)
SOAP is the envelope syntax for sending and receiving XML messages with Web services. That is, SOAP is the “envelope” that packages the XML messages that are sent over HTTP between clients and Web services. As defined by the W3C, SOAP is “a lightweight protocol for exchange of information in a decentralized, distributed environment.” (http://www.w3.org/TR/SOAP/). It provides a standard language for tying applications and services together. An application sends a SOAP request to a Web service, and the Web service returns the response in something called a SOAP response. SOAP can potentially be used in combination with a variety of other protocols, but in practice, it is used with HTTP.
SOAP has been adopted as the standard for Web services, and applications from major vendors have developed SOAP APIs for their products, thus making software systems integration easier. The syntax of SOAP, in its basic form, is fairly simple, as shown in Figure 4.4. A SOAP message contains the following elements:
- A SOAP envelope that wraps the message
- A description of how data is encoded
- A SOAP body that contains the application-specific message that the backend application will understand
(The Semantic Web: A Guide to the Future of XML, Web Services, and Knowledge Management, Michael C. Daconta Leo J. Obrst Kevin T. Smith)
A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the data being exchanged , and port types which are abstract collections of operations. The concrete protocol and data format specifications for a particular port type constitute a reusable binding. A port is defined by associating a network address with a reusable binding, and a collection of ports define a service. Hence, a WSDL document uses the following elements in the definition of network services:
- Types - a container for data type definitions using some type system (such as XSD).
- Message - an abstract, typed definition of the data being communicated.
- Operation - an abstract description of an action supported by the service.
- Port Type - an abstract set of operations supported by one or more endpoints.
- Binding - a concrete protocol and data format specification for a particular port type.
- Port - a single endpoint defined as a combination of a binding and a network address.
- Service - a collection of related endpoints.
Network and web services resource architecture is based on the ability to describe an operation of a web service that responds with an output message or a fault based on at least one or more input messages received. WSDL describes Web services starting with the messages that are exchanged between the requester and provider agents. The messages themselves are described abstractly and then bound to a concrete network protocol and message format. Web service definitions can be mapped to any implementation language, platform, object model, or messaging system . Simple extensions to existing Internet infrastructure can implement Web services for interaction via browsers or directly within an application. The application could be implemented using COM, JMS, CORBA, COBOL, or any number of proprietary integration solutions. As long as both the sender and receiver agree on the service description, (e.g. WSDL file), the implementations behind the Web services can be anything.
The requester entity and provider entity agree on the service description (a WSDL document) and semantics that will govern the interaction between the requester agent and the provider agent . This does not necessarily mean that the requester and provider entities must communicate or negotiate with each other. It simply means that both parties must have the same (or compatible) understandings of the service description and semantics, and intend to uphold them. Below are the proposed methods this can be achieved:
- The requester and provider entities may communicate directly with each other, to explicitly agree on the service description and semantics.
- The provider entity may publish and offer both the service description and semantics as ”take-it-or-leave-it” "contracts" that the requester entity must accept unmodified as conditions of use.
- The service description and semantics may be defined as a standard by an interested in organization, and used by many requester and provider entities. In this case, the act of the requester and provider entities reaching agreement is accomplished by both parties independently conforming to the same standard.
- The service description and semantics may be defined and published by the requester entity, and offered to provider entities on a “take-it-or-leave-it” basis. This may occur, for example, if a large company requires its suppliers to provide Web services that conform to a particular service description and semantics. In this case, agreement is achieved by the provider entity adopting the service description and semantics that the requester entity has published.
( Modeling network and web services resource using WSDL Martin Tsenov)
Universal Description, Discovery, and Integration (UDDI) is a SOAP-based API for publishing and discovering Web services.
The publishing API allows service providers to register themselves and their services with a UDDI registry. A UDDI registry can be viewed as the yellow pages for Web services. UDDI registry nodes replicate Web services information among them to provide the same information from any node.
The discovery API allows service subscribers to search for available services. The UDDI registry provides the WSDL document allowing the consumer to use the Web service. The way a UDDI registry is searched is similar to how domain names are looked up in the Web using the DNS architecture.
Macromedia has been involved in Web services before the term was coined and continues to provide industry leadership in the development and implementation of the Web services standards.
Macromedia has been involved in Web services technologies since 1998 when the company shipped an open source technology called Web Distributed Data Exchange (WDDX). WDDX provides a language and platform-independent architecture for application integration on the Web. WDDX allows developers to integrate Java, PHP, ColdFusion, and Microsoft technologies in a distributed environment.
Macromedia also participates in the W3C working group on XML protocol (XMLP) and the company co-submitted the WSDL specification with IBM, Microsoft and others to the W3C.
In addition, Macromedia participates in W3C working groups and, as part of the Java Community Process (JCP), is active in many Java expert groups related to XML and Web services including JAXB (Java APIs for XML data binding), JAXM (Java APIs for XML messaging), and JAX-RPC (Java APIs for XML RPC).
Macromedia has also taken a leadership role in open source efforts related to Web services. The company dedicates full-time engineers to work on the Axis Web services engine, a project of the Apache Software Foundation. The project also includes team members from IBM, HP, and other vendors.
(Web Services: Building the Next Generation of E-Business Applications Christophe Coenraets JRun Product Marketing Manager October, 2nd 2001)