Web Services
Web services are application components that extend client-server
applications to open audiences, via web browers and using open protocols.
They are self-contained and self-describing.
Web Services
Web services are application components that support communication
between applications over a network or the Web.
There are two ways to develop web services:
- An XML standards approach
- Using a J2EE platform
Using XML Standards
This uses a set of XML-based open standards
- Web Services Description Language [WSDL],
- Simple Object Access Protocol [SOAP]
- Universal Description, Discovery, and Integration [UDDI]
These standards are used to define, publish, and use web services.
More On XML Web Services
Using A J2EE 1.4 Platform
Alternatively, web services can be developed in the J2EE 1.4 platform.
This method does not require knowledge of the XML standards.
Java APIs for XML Registries [JAXR] and Java APIs are automatically
generated for XML Remote Procedure Calls [JAX-RPC]
More on J2EE Web Services
Key Benefits Of Web Services
The two key problems solved by Web Services over previous distributed
systems [CORBA, DCOM, RPC etc] are:
Interoperability - previously each vendor implemented
its own on-wire format for distributed object messaging. By using
XML as an on-wire standard, finally Java/J2EE and .NET/C# can communicate.
Firewall traversal - CORBA and DCOM used non-standard
ports, limiting collaboration across corporations without needing
to open a hole in the corporate firewall. Even using restricted
limited zones [DMZ], this was often unacceptable to IT. Web Services
use HTTP as a transport protocol, which is allowed by most firewalls
though port 80 [for HTTP].
Uses For Web Services
Web services are generally used in two ways:
- As reusable application components - language translation, currency
conversion, weather reports etc
- For connecting existing software - to help solve interoperability
problems between different applications and different platforms.
See:
Web Service Development
Web Services can be developed using:
- Visual Basic [VB]
- C/C++
- Java
- .Net - ASP.NET automates the process; you do not have to write
your own WSDL and SOAP documents. These are automatically created.
Runtime System
Developing and deploying web services is coupled with the runtime
system.
Deploying a web service on Apache Axis is different from deploying
the same web service on Apache SOAP or any other platform.
Development Lifecycle
The standard lifecycle to develop web services includes:
- Development - the web services programming model as well as
the deployment descriptors
- Deployment - actions expected of the container
- Service publication - how the WSDL is made available to clients
- Service consumption- the client deployment descriptors and
lookup model
Web Services Communication Messages
In a typical web services application:
- The service request is entered into a form on a website, or
by clicking a link
- The web service creates a WSDL and SOAP
request
- This is sent to the web application using an HTTP POST
- The request is imported to and processed by the application
- The application will send a XML response back to the web service,
and the response data is displayed on the webpage.
By using Web services, your application can publish its function
or message to the rest of the world.
Web Services Files
Web site applications can contain a number of file types, some
supported and managed by ASP.NET, and others supported and managed
by the IIS server.
Web Services can be identified by file extensions:
.aspx - a simple ASP.NET Web forms file that can
contain Web controls and presentation and business logic.
.asmx - is the ASP.NET file extension for XML
Web Services.
.soap - can be used to write SOAP Servers and
Clients. It supports subsets of SOAP 1.1, SOAP 1.2 and WSDL 1.1
specifications. This extension is only available if PHP is configured
with --enable-soap. Definition: NAME=soap.wsdl_cache_enabled;
DEFAULT= "1"; CHANGEABLE= PHP_INI_ALL
.jws - Java Web Services are standard Java files
with annotations to use Web services functionality, such as asynchronous
messaging and XML to Java mapping. These files are executed by BEA
WebLogic Workshop and other platforms supporting JWS.
Web Service Clients
A client invokes a web service in the same way it invokes a method
locally.
There are three types of web service clients:
- Static Stub
- Dynamic Proxy
- Dynamic Invocation Interface [DII]
Static Stub
A Java class that is statically bound to a service endpoint interface.
A stub, or a client proxy object, defines all the methods that the
service endpoint interface defines. Therefore, the client can invoke
methods of a web service directly via the stub.
- Advantage - simple and easy to code
- Disadvantage - it is implementation-specific,
meaning the slightest change of web service definition makes the
stub useless and it must be regenerated.
- Uses - when the web service is stable and not
likely to change its definition.
Dynamic Proxy
Supports a service endpoint interface dynamically at runtime. No
stub code generation is required.
A proxy is obtained at runtime and requires a service endpoint
interface to be instantiated. It is invoked in the same way as a
stub.
- Uses - for testing web services that may change
their definitions. The dynamic proxy needs to be re-instantiated
but not re-generated as is the case with stub.
Dynamic Invocation Interface [DII]
Defines javax.xml.rpc.Call object instance for dynamic invocation.
DDI must be configured before it can be used.
A client needs to provide:
- operation name
- parameter names
- types
- modes, and
- port type
Advantage - Call is not bound to anything; there
is no impact of changes in the web service definition.
Disadvantage - much more coding is required.
Also See:
Back To Top
|