HOME
BLOG
SHOPPING
 
CATEGORIES
 
Business Technology
RFID
 
Comms Technology
Telco Data
Digital Convergence
Telco Path To Profitability
Network Technology
IP Layering
Cloud Computing
Convergence
IP Infrastructure
Intro To Voice Over IP
Telecoms Whitepapers
Telecoms Index
WiMax
 
Telco Profiles
New Zealand
Australia
 
Mobile Networks
Mobile Applications
Mobile OS
Mobile Advertising
Mobile Video
 
Media
Digital Interactive Media
Digital Music Downloads
Top10 Video Sharing Sites
Mobile Media Broadcast
Mobile Media Industry
 
Web Technologies
Web 2.0
Web 3.0 Semantic
Web 3 Collaboration
Web 4.0 Quality Content
Web - X
Mashups
SOA - Web Services
VoIP in Business
Web 2.0 Enterprises
 
Virtualization
Intro To Virtualization
Planning
Server Virtualization
Platform Virtualization
App. Virtualization
OS Virtualization
Virtual Desktop [VDI]
Microsoft Hyper-V
VMWare VDI
 
On-Demand / SaaS
About SaaS
Selling SaaS
SaaS Channel Models
SaaS Sales Models
Billing SaaS
 
Electricity
Smart Power
Inductive Power Transfer
 
Electronic Payment
E-Payment Systems
E-Payment Directory
Mobile Payment Systems
 
Other
Personal Technology
Oyco Comms Portals
Convergence Marketing
Home Technology
Car Technology
Boat Technology
 
NEWS UPDATES
Media Technology
Telco Industry Updates
News Index
 
OTHER RESOURCES
Convergence Search
Social Media Podcasts
Events
Sitemap
PROJECT LOGIN
 

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:

  1. An XML standards approach
  2. 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:

  1. As reusable application components - language translation, currency conversion, weather reports etc
  2. 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:

  1. Development - the web services programming model as well as the deployment descriptors
  2. Deployment - actions expected of the container
  3. Service publication - how the WSDL is made available to clients
  4. Service consumption- the client deployment descriptors and lookup model

 

Web Services Communication Messages

In a typical web services application:

  1. The service request is entered into a form on a website, or by clicking a link
  2. The web service creates a WSDL and SOAP request
  3. This is sent to the web application using an HTTP POST
  4. The request is imported to and processed by the application
  5. 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:

  1. Static Stub
  2. Dynamic Proxy
  3. 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