Webservices architecture:

Web Services are self-contained, modular applications that can be described, published, located, and invoked over a network, generally, the World Wide Web. The Web Services architecture describes three roles: service provider, service requester and service broker; and three basic operations: publish, find and bind. A network component can play any or all of these roles. Two separate documents describe Web Services: A Well-Defined Service (WDS) document describes nonoperational service information, such as service category, service description, and expiration date, as well as business information about the service provider, such as company name, address, and contact information. A NetworkAccessible Service Specification Language (NASSL) document describes operational information about the service, such as service interface, implementation details, access protocol, and contact endpoints. A Web Services architecture implementation should allow for incremental security and quality of service models facilitated by configuring a set of environmental prerequisites (for example, authentication mechanism, billing, and so on) to control and manage the interactions. Web Services can be dynamically composed into applications stemming from capabilities-based look-up at runtime, instead of the traditional static binding.The dynamic nature of the collaborations allow the implementations to be platform- and programming language-neutral, and communications mechanism-independent, while creating innovative products, processes, and value chains.

Web Services components Several essential activities need to happen in any service-oriented environment: 1. A Web service needs to be created, and its interfaces and invocation methods must be defined. 2. A Web service needs to be published to one or more intranet or Internet repositories for potential users to locate. 3. A Web service needs to be located to be invoked by potential users. 4. A Web service needs to be invoked to be of any benefit. 5. A Web service may need to be unpublished when it is no longer available or needed. A Web Services architecture then requires three fundamental operations: publish, find, and bind. Service providers publish services to a service broker. Service requesters find required services using a service broker and bind to them. These ideas are shown in the following figure.

Publish, find, and bind

The mechanism of service description is one of the key elements in a Web Services architecture. The full description of a service for our architecture is found in two separate documents, a Network Accessible Service Specification Language (NASSL) document and a Well-Defined Service (WDS) document. NASSL is an XML-based Interface Definition Language (IDL) for network-based services, and is used to specify the operational information for a Web Service, such as service interface, implementation details, access protocol, and contact endpoints. A WDS document is used to specify the nonoperational information for a service, such as service category, service description, and expiration date, as well as business information about the service provider, such as company name, address, and contact information. A WDS document is complementary to a corresponding NASSL document. Together these two documents are used to specify a full service description that allows service requesters to locate and invoke a service. All collaborations in the Web Services architecture have the possibility of being controlled by a configurable, negotiable set of environmental prerequisites. An environmental prerequisite is any nonfunctional component or infrastructure mechanism that must be made operational before a service can be invoked -- for example, the use of a particular communications mechanism (HTTPS, IBM MQSeries), or the use of a particular third-party auditing or billing service. These components (often, themselves, implemented as services) must be put in place before the service can actually be invoked. A service may support multiple possible implementations for any environmental prerequisite it specifies. For example, the service could offer a choice of communications layer, choice of billing service, or other option. The service requester can then negotiate or choose which implementation to use to satisfy the environmental prerequisite. It is through environmental prerequisites that collaborations can be as secure, reliable, and safe as required by the two collaborators in a Web Services architecture.

Back to top

Web Services benefits Use of the Web Services architecture provides the following benefits:

Promotes interoperability by minimizing the requirements for shared understanding XML-based interface definition language (NASSL), an XML-based service description (WDS) and a protocol of collaboration and negotiation are the only requirements for shared understanding between a service provider and a service requester. By limiting what is absolutely required for interoperability, collaborating Web services can be truly platform and language independent. By limiting what is absolutely required, Web Services can be implemented using a large number of different underlying infrastructures.

Enables just-in-time integration Collaborations in Web Services are bound dynamically at runtime. A service requester describes the capabilities of the service required and uses the service broker infrastructure to find an appropriate service. Once a service with the required capabilities is found, the information from the service's NASSL document is used to bind to it. Dynamic service discovery and invocation (publish, find, bind) and message-oriented collaboration yield applications with looser coupling, enabling just-in-time integration of new applications and services. This in turn yields systems that are self-configuring, adaptive and robust with fewer single points of failure.

Reduces complexity by encapsulation All components in Web Services are services. What is important is the type of behavior a service provides, not how it is implemented. A WDS document is the mechanism to describe the behavior encapsulated by a service. Encapsulation is key to: Coping with complexity. System complexity is reduced when application designers do not have to worry about implementation details of the services they are invoking. o Flexibility and scalability. Substitution of different implementation of the same type of service, or multiple equivalent services, is possible at runtime. o Extensibility. Behavior is encapsulated and extended by providing new services with similar service descriptions. Enables interoperability of legacy applications By allowing legacy applications to be wrappered in NASSL and WDS documents, and exposed as services, the Web Services architecture easily enables new interoperability between these applications. In addition, security, middleware and communications technologies can be wrappered to participate in a Web service as environmental
o

prerequisites. Directory technologies, such as LDAP, can be wrappered to act as a service broker. Through wrappering the underlying plumbing (communications layer, for example), services insulate the application programmer from the lower layers of the programming stack. This allows services to enable virtual enterprises to link their heterogeneous systems as required (through http-based communications) and/or to participate in single, administrative domain situations, where other communications mechanisms (for example, MQSeries) can provide a richer level of functionality. Examples of this can be found in merger situations, where the resulting enterprise must integrate disparate IT systems and business processes. A service-oriented architecture would greatly facilitate a seamless integration between these systems. Another example can be found in the combination of the travel industry with pervasive computing, when largely mainframe-based travel applications can be exposed as services through wrappering and made available for use by various devices in a service-oriented environment. New services can be created and dynamically published and discovered without disrupting the existing environment.

The structure of a SOAP message

A SOAP message is encoded as an XML document, consisting of an <Envelope> element, which contains an optional <Header> element, and a mandatory <Body> element. The <Fault> element, contained within the <Body>, is used for reporting errors. The SOAP envelope The SOAP <Envelope> is the root element in every SOAP message, and contains two child elements, an optional <Header> and a mandatory <Body>. The SOAP header The SOAP <Header> is an optional sub-element of the SOAP envelope, and is used to pass application-related information that is to be processed by SOAP nodes along the message path. The SOAP body The SOAP <Body> is a mandatory sub-element of the SOAP envelope, which contains information intended for the ultimate recipient of the message. The SOAP fault The SOAP <Fault> is a sub-element of the SOAP body, which is used for reporting errors.

With the exception of the <Fault> element, which is contained in the <Body> of a SOAP message, XML elements within the <Header> and the <Body> are defined by the applications that make use of them, although the SOAP specification imposes some constraints on their structure. Figure 1 shows the main elements of a SOAP message.

Figure 1. The structure of a SOAP message

What is a web service?

W3C defintion for a web service is, a software system designed to support interoperable machine-to-machine interaction over a network. Web service is an interface for your software. We may have web user interface or a thick client (desktop) user interface for our software. Imagine web service as another similar interface. This interface is not for humans but for softwares. Web/thick client directly serves end user as an interface to interact with the software. Web service serves as an interface to software developers. Using web service as an API, developers can build external systems that will interact with the software. There are two major categories of web services
1. SOAP Web Service 2. RESTful Web Service

Soap Web Service

Simple Object Access Protocol (SOAP) is a standard protocol specification for message exchange based on XML. Communication between the web service and client happens using XML messages. SOAP defines the rules for communication like what are all the tags that should be used in XML and their meaning.

RESTful Web Service

RESTful web service uses architectures that use HTTP or similar protocols by restricting the interface to use standard operations like GET, POST, PUT, DELETE for HTTP. Based on my experience RESTful is easier to develop. I know this statement will invite wrath of SOAP lovers.

WSDL
One major component of a web service is Web Services Description Language (WSDL). It is an xml file that describes the web service technically in a machine readable format. That is, using this WSDL file we can understand things like,

Port / Endpoint URL of the web service (using which we should access it) Input message format Output message format Security protocol that needs to be followed (like https) Which protocol the web service uses

I just want this article to be a beginning point for your web service exploration. Do not stop with this, explore more and more and you will love this service oriented architecture. Theory is too dull isnt it? Lets move to fun part the coding.

Hello World SOAP Web Service

Download the latest Netbeans IDE. Go! I will wait I am using NetBeans IDE 7.1 for this tutorial. You can download the complete source SOAPHelloWorld of this article.

Challenge No.1 - Heterogeneity

Heterogeneity - Describes a system consisting of multiple distinct components Of course heterogeneity applies to pretty much anything which is made up of many different items or objects including Food! (Okay so that might be a bad analogy but you get the idea) Anyway, in many systems in order to overcome heterogeneity a software layer known as Middleware is often used to hide the differences amongst the components underlying layers.

Challenge No.2 Openness

Openness Property of each subsystem to be open for interaction with other systems So once something has been published it cannot be taken back or reversed. Furthermore in open distributed systems there is often no central authority, as different systems may have their own intermediary.

Challenge No.3 Security

The issues surrounding security are those of

Confidentiality Integration Availability

To combat these issues encryption techniques such as those of cryptography can help but they are still not absolute. Denial of Service attacks can still occur, where a server or service is bombarded with false requests usually by botnets (zombie computers).

Challenge No.4 Scalability

What is scalability?! Okay so basically a system is described as scalable if: As the system, number of resources, or users increase the performance of the system is not lost and remains effective in accomplishing its goals Thats a fairly self explanatory description, but there are a number of important issues that arise as a result of increasing scalability, such as increase in cost and physical resources. It is also important to avoid performance bottlenecks by using caching and replication.

Challenge No.5 Fault handling

Failures are inevitable in any system; some components may stop functioning while others continue running normally. So naturally we need a way to:

Detect Failures Various mechanisms can be employed such as checksums. Mask Failures retransmit upon failure to receive acknowledgement Recover from failures if a server crashes roll back to previous state Build Redundancy Redundancy is the best way to deal with failures. It is achieved by replicating data so that if one sub system crashes another may still be able to provide the required information.

Challenge No.6 Concurrency

Concurrency issues arise when several clients attempt to request a shared resource at the same time. This is problematic as the outcome of any such data may depend on the execution order, and so synchronisation is required.Click here to find out more about synchronisation

Challenge No.7 Transparency

A distributed system must be able to offer transparency to its users. As a user of a distributed system you do not care if we are using 20 or 100s of machines, so we hide this information, presenting the structure as a normal centralized system.

Access Transparency where resources are accessed in a uniform manner regardless of location Location Transparency the physical location of a resource is hidden from the user Failure Transparency Always try and Hide failures from users (see challenge No.5)