Web Services Concept
- Web Services Concept
- Types of Web Services
- Deciding Which Type of Web Service to Use
- Web Services Characteristics
- Web Services Components
Web Services Concept |
By using Web services, your application can publish its function or message to the rest of the world.
Web services use XML to code and to decode data, and SOAP (Simple Object Access Protocol) to transport it (using open protocols).SOAP is versatile enough to allow for the use of different transport protocols.
Java EE 6 web services technologies. these technologies include Java API for XML Web Services (JAX-WS) and Java API for RESTful Web Services (JAX-RS).
Web services are client and server applications that communicate over the World Wide Web’s (WWW) HyperText Transfer Protocol (HTTP). As described by the World Wide Web Consortium (W3C), web services provide a standard means of interoperating between software applications running on a variety of platforms and frameworks. Web services are characterized by their great interoperability and extensibility, as well as their machine-processable descriptions, thanks to the use of XML. Web services can be combined in a loosely coupled way to achieve complex operations. Programs providing simple services can interact with each other to deliver sophisticated added-value services.
Types of Web Services |
Types of Web Services
On the conceptual level, a service is a software component provided through a network-accessible endpoint.
The service consumer and provider use messages to exchange invocation request and response information in the form of self-containing documents that make very few assumptions about the technological capabilities of the receiver.
On a technical level, web services can be implemented in various ways.
The two types of web services discussed in this section can be distinguished as “big” web services and “RESTful” web services.
“Big” Web Services
In Java EE 6, JAX-WS provides the functionality for “big” web services,
Big web services use XML messages that follow the Simple Object Access Protocol (SOAP) standard, an XML language defining a message architecture and message formats.
Such systems often contain a machine-readable description of the operations offered by the service, written in the Web Services Description Language (WSDL), an XML language for defining interfaces syntactically.
The SOAP message format and the WSDL interface definition language have gained widespread adoption.Many development tools, such as NetBeans IDE, can reduce the complexity of developing web service applications.A SOAP-based design must include the following elements.
- A formal contract must be established to describe the interface that the web service offers. WSDL can be used to describe the details of the contract, which may include messages, operations, bindings, and the location of the web service. You may also process SOAP messages in a JAX-WS service without publishing a WSDL.
- The architecture must address complex nonfunctional requirements. Many web service specifications address such requirements and establish a common vocabulary for them. Examples include transactions, security, addressing, trust, coordination, and so on.
- The architecture needs to handle asynchronous processing and invocation. In such cases, the infrastructure provided by standards, such as Web Services Reliable Messaging (WSRM), and APIs, such as JAX-WS, with their client-side asynchronous invocation support, can be leveraged out of the box.
RESTful Web Services
In Java EE 6, JAX-RS provides the functionality for Representational State Transfer (RESTful) web services. REST is well suited for basic, ad hoc integration scenarios. RESTful web services, often better integrated with HTTP than SOAP-based services are, do not require XML messages or WSDL service-API definitions.
Project Jersey is the production-ready reference implementation for the JAX-RS specification. Jersey implements support for the annotations defined in the JAX-RS specification, making it easy for developers to build RESTful web services with Java and the Java Virtual Machine (JVM).
Because RESTful web services use existing well-known W3C and Internet Engineering Task Force (IETF) standards (HTTP, XML, URI, MIME) and have a lightweight infrastructure that allows services to be built with minimal tooling, developing RESTful web services is inexpensive and thus has a very low barrier for adoption. You can use a development tool such as NetBeans IDE to further reduce the complexity of developing RESTful web services.
A RESTful design may be appropriate when the following conditions are met.
-
The web services are completely stateless.
A good test is to consider whether the interaction can survive a restart of the server. -
A caching infrastructure can be leveraged for performance.
If the data that the web service returns is not dynamically generated and can be cached,
the caching infrastructure that web servers and other intermediaries inherently provide
can be leveraged to improve performance.
However, the developer must take care because such caches are limited to the HTTP GET method for most servers. -
The service producer and service consumer have a mutual understanding of the context and content being passed along.
Because there is no formal way to describe the web services interface, both parties must agree out of band on the schemas
that describe the data being exchanged and on ways to process it meaningfully.
In the real world, most commercial applications that expose services as RESTful implementations
also distribute so-called value-added toolkits that describe the interfaces to developers in popular programming languages. -
Bandwidth is particularly important and needs to be limited.
REST is particularly useful for limited-profile devices, such as PDAs and mobile phones,
for which the overhead of headers and additional layers of SOAP elements on the XML payload must be restricted. -
Web service delivery or aggregation into existing web sites can be enabled easily with a RESTful style.
Developers can use such technologies as JAX-RS and Asynchronous JavaScript with XML (AJAX) and
such toolkits as Direct Web Remoting (DWR) to consume the services in their web applications.
Rather than starting from scratch, services can be exposed with XML and consumed by HTML pages without significantly
refactoring the existing web site architecture.
Existing developers will be more productive because they are adding to something they are already familiar with rather
than having to start from scratch with new technology. - RESTful web services can be build using both NetBeans IDE and the Maven project management tool.
JAX-RS RESTful Web Services Example
Deciding Which Type of Web Service to Use |
Basically, you would want to use RESTful web services for integration over the web and use big web services in enterprise application integration scenarios that have advanced quality of service (QoS) requirements.
JAX-WS : addresses advanced QoS requirements commonly occurring in enterprise computing.
When compared to JAX-RS, JAX-WS makes it easier to support the WS-* set of protocols, which provide standards for security and reliability, among other things, and interoperate with other WS-* conforming clients and servers.
JAX-RS : makes it easier to write web applications that apply some or all of the constraints of the REST style to induce desirable properties in the application, such as loose coupling (evolving the server is easier without breaking existing clients), scalability (start small and grow), and architectural simplicity (use off-the-shelf components, such as proxies or HTTP routers). You would choose to use JAX-RS for your web application because it is easier for many types of clients to consume RESTful web services while enabling the server side to evolve and scale. Clients can choose to consume some or all aspects of the service and mash it up with other web-based services.
Web Services Characteristics |
- Loosely coupled – A consumer of a web service is not tied to that web service directly. The web service interface can change over time without compromising the client’s ability to interact with the service. A tightly coupled system implies that the client and server logic are closely tied to one another, implying that if one interface changes, the other must also be updated. Adopting a loosely coupled architecture tends to make software systems more manageable and allows simpler integration between different systems.
- Coarse-grained – Object-oriented technologies such as Java expose their services through individual methods. An individual method is too fine an operation to provide any useful capability at a corporate level. Building a Java program from scratch requires the creation of several fine-grained methods that are then composed into a coarse-grained service that is consumed by either a client or another service. Businesses and the interfaces that they expose should be coarse-grained. Web services technology provides a natural way of defining coarse-grained services that access the right amount of business logic.
- Ability to be synchronous or asynchronous – Synchronicity refers to the binding of the client to the execution of the service. In synchronous invocations, the client blocks and waits for the service to complete its operation before continuing. Asynchronous operations allow a client to invoke a service and then execute other functions. Asynchronous clients retrieve their result at a later point in time, while synchronous clients receive their result when the service has completed. Asynchronous capability is a key factor in enabling loosely coupled systems.
- Supports Remote Procedure Calls (RPCs) – Web services allow clients to invoke procedures, functions, and methods on remote objects using an XML-based protocol. Remote procedures expose input and output parameters that a web service must support. Component development through Enterprise JavaBeans (EJBs) and .NET Components has increasingly become a part of architectures and enterprise deployments over the past couple of years. Both technologies are distributed and accessible through a variety of RPC mechanisms. A web service supports RPC by providing services of its own, equivalent to those of a traditional component, or by translating incoming invocations into an invocation of an EJB or a .NET component.
- Supports document exchange – One of the key advantages of XML is its generic way of representing not only data, but also complex documents. These documents can be simple, such as when representing a current address, or they can be complex, representing an entire book or RFQ. Web services support the transparent exchange of documents to facilitate business integration.
- XML-based – Web Services uses XML at data representation and data transportation layers. Using XML eliminates any networking, operating system, or platform binding. So Web Services based applications are highly interoperable application at their core level.
Web Services Components |
Over the past few years, below primary technologies have emerged as worldwide standards that make up the core of today’s web services technology.
These technologies are as follows
WSDL
- WSDL was developed jointly by Microsoft and IBM.
- WSDL is pronounced as ‘wiz-dull’ and spelled out as ‘W-S-D-L’
- WSDL is an XML-based language for describing Web services and how to access them.
- WSDL stands for Web Services Description Language
- WSDL is an XML based protocol for information exchange in decentralized and distributed environments.
- WSDL is the standard format for describing a web service.
- WSDL definition describes how to access a web service and what operations it will perform.
- WSDL is a language for describing how to interface with XML-based services.
- WSDL is an integral part of UDDI, an XML-based worldwide business registry.
- WSDL is the language that UDDI uses.
SOAP
- SOAP is an XML-based protocol for exchanging information between computers.
- SOAP is a format for sending messages
- SOAP is designed to communicate via Internet
- SOAP is platform independent
- SOAP is language independent
- SOAP is a communication protocol
- SOAP is for communication between applications
- SOAP is simple and extensible
- SOAP allows you to get around firewalls
- SOAP will be developed as a W3C standard
UDDI
- UDDI stands for Universal Description, Discovery and Integration.
- UDDI is a specification for a distributed registry of Web services.
- UDDI is platform independent, open framework.
- UDDI can communicate via SOAP, CORBA, Java RMI Protocol.
- UDDI uses WSDL to describe interfaces to web services.
- UDDI is an XML-based standard for describing, publishing, and finding Web services.
- UDDI is seen with SOAP and WSDL as one of the three foundation standards of web services.
- UDDI is an open industry initiative enabling businesses to discover each other and define how they interact over the Internet.
XML-RPC
- This is the simplest XML based protocol for exchanging information between computers.
- XML-RPC is a simple protocol that uses XML messages to perform RPCs.
- XML-RPC allows diverse applications to communicate.
- A Java client can speak XML-RPC to a Perl server.
- XML-RPC is the easiest way to get started with web services.
- Requests are encoded in XML and sent via HTTP POST.
- XML responses are embedded in the body of the HTTP response.
- XML-RPC is platform-independent.
Recent Comments