Internet Edition. December 19, 2007, Updated: Bangladesh Time 12:00 AM 
Home | Daily Ittefaq | FORMICON | Tech News | Ebiz | Photos

Structure and necessity of a web address

Azizur Rahman

The ability for SOAP to use standard ports and protocols, such as SMTP, HTTPS, and HTTP, offsets its performance and bandwidth issues. The use of common Internet technologies allows SOAP to transverse firewalls easier than other remote procedure call protocols. The ability of SOAP to interoperate with existing network topologies without requiring network reconfigurations is one of the driving factors for its popularity.

WSDL

Web Services Description Language (WSDL) is an XML-based language that describes how external programs interface with a Web Service. WSDL is similar to header files in C/C++ or IDL in CORBA in that it defines a standardized interface into a software function. WSDL is independent of any programming language and can define interfaces to Web Services regardless of the programming language.

Typically, a developer uses development tools to generate Web Service implementation skeleton code from a WSDL. Conversely, developers can use tools to generate WSDL from existing code. While the later approach is easier for existing code, it is more prone to issues as it strongly couples the WSDL to the development environment.

The WSDL has two parts. The first part is an abstract part that describes the operations and associated parameters supported by a Web Service. The abstract WSDL is independent of technological implementation of those services. Many of the WS-* standards use abstract WSDLs to define their interfaces. The second part is a concrete binding that describes implementation details of operations and service hosting information. In a typical WSDL, a concrete binding describes how the abstract operations are bound to SOAP messages, but these bindings can also describe Representational State Transfer (REST) bindings or even bindings to CORBA. A service can implement multiple bindings in a single WSDL.

UDDI

Universal Description Discovery and Integration (UDDI) is a XML-based registry to store information regarding services. UDDI contains three types of information, White Pages, Yellow Pages and Green Pages. White Pages contain basic contact information, such as address and phone numbers, regarding business proving a service. Yellow Pages describe services by categorizing them according using a taxonomy. Green Pages provide technical information necessary to bind to a Web Service. Green Pages can include WSDL definitions, but are not limited to using WSDL to describe Web Service interfaces and bindings. Developers and services can access UDDI through standardized Web Interfaces.

While it is possible to invoke UDDI, developers normally access it to discover new Web Services and to develop code to invoke those services. For organizations with a limited number of Web Services, a UDDI registry is not necessarily essential. As numbers of Web Services in an organization grow, UDDI is a recommended building block to register and discover new Web Services.

WS-*

Developers can create basic and functional Web Services using only SOAP and WSDL, but will need to implement a great deal of software to handle complex interactions. Most Web Services need advanced capabilities such as quality of service assurances and security.

Fortunately, many of the commonly needed features are standardized and implemented in a wide range of open source and proprietary products.

The extensions to basic Web Services are known as the WS-* family of specifications as most of these specifications begin with WS prefix. These specifications are vendor independent standards approved by organizations such as the World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS). Common WS-* specifications include WS-Security, WS-ReliableMessaging, WS-BPEL and WS-Addressing.

Security

In many uses of Web Services, services send messages outside of the network boundaries of an organization and onto open networks. Often times, external organizations are the consumers of Web Services.

Service owners need to assure only properly authenticated and authorized end users can access their Web Services. There are a variety WS-* security standards that address protecting Web Service messages, passing authentication information, describing security policy and other security related issues.

WS-Security defines the basic elements necessary to apply security to SOAP messages. In lay terms, WS-Security provides the means to prove that messages sent are from the intended receiver, assures an unauthorized entity does not change messages in transit, prevent an unintended recipient from reading messages and pass information necessary to prove one's identity. In technical terms, WS-Security specifies how to apply encryption and digital signatures to SOAP messages in a standardized way as well as how to pass security tokens.

WS-Security builds upon previous standards such as XML Encryption, XML Digital Signature and Security Assertion Markup Language (SAML). It also incorporates non-XML security models such as Kerberos, Public-Key Infrastructure (PKI), and Security Socket Layer (SSL).

Do you like the new site? Do you have any improvement suggestion? Please drop us a line.

 

 
Privacy Policy | Feedback | Contact Us
Developed and Maintained by M. Kaisar-Ul-Haque.