WEB SERVICES INTEROPERABILITY TECHNOLOGY

(WSIT)
Prof. Sangram Z. Gawali
Bharati Vidyapeeth University College of Engineering, Pune
gsangram@gmail.com

Lalit Jain (B.E.-IT)

Bharati Vidyapeeth University College of Engineering, Pune
erlalit_jain@yahoo.co.in

Prakash Narain (B.E.-IT)

Bharati Vidyapeeth University College of Engineering, Pune
prakashnarain2005@gmail.com

Abstract Seamless integration will also enable greater

Web Services Interoperability Technology collaboration for enterprises, by allowing them
(WSIT) is an open-source implementation of next to leverage a larger ecosystem of partners in
generation Web services technologies that application development. Additionally,
deliver interoperability between Java EE and interoperability between the two platforms will
.Net to help you build, deploy, and maintain help pave the way for greater adoption of web
Composite Applications for your Service services and service-oriented architecture (SOA)
Oriented Architecture. Built upon JAX-WS (Java -based application development by reducing the
API for XML Web Services), this implementation associated cost, complexity and risk.
will be made available as the "Web Services
Interoperability Technology (WSIT)" and is Sun plans to implement WSIT specifications
focused on four main categories: pertaining to SOAP-based Messaging, Metadata,
Security and Quality of Service, and will make
Keyword: WSDL, SOA, UDDI, W3C , XSD and them available to the community via Sun's
SOAP Glassfish project, the open source development
project for Sun’s Java System Application
Introduction Server Platform Edition 9. Additionally, Sun will
The ability to seamlessly integrate Java provide the Java community with tools, sample
Enterprise Edition (Java EE) and .NET applications, and supporting materials via its
environments will help developers create integrated software system platform, the Java
applications on a diverse range of operating Enterprise System (Java ES), and through its
systems including the Solaris Operating System Java Web Services Developer Pack (Java
(OS), Windows and Linux, that can co-exist and WSDP)
interoperate across heterogeneous computing
environments.
Interoperability
The SOA vision of interaction between clients
and loosely-coupled services means widespread
interoperability. In other words, the objective is
for clients and services to communicate and
understand each other no matter what platform
they run on. This objective can be met only if
clients and services have a standard way of
communicating with each other -- a way that's
consistent across platforms, systems, and
languages. In fact, web services provide exactly
that.
Web services comprise a maturing set of
protocols and technologies that are widely
accepted and used, and that are platform, system,
and language independent. In addition, these
protocols and technologies work across firewalls,
making it easier for business partners to share
vital services. Promising to make things even
more consistent is the WS-I basic profile,
introduced by the Web Services Interoperability
Organization (an organization chartered to
promote web services interoperability).
The WS-I basic profile identifies a core set of
web services technologies that when
implemented in different platforms and systems,
helps ensure that services on these different
platforms and systems, and written in different
languages, can communicate with each other.
The WS-I basic profile has widespread backing
in the computer industry, virtually guaranteeing
interoperability of services that conform to the
profile.
Weaving together Web services to create cross-
organizational business processes requires all
partners to program to the same standard model
and to avoid exposing proprietary
implementations. After many years of promoting
the interoperability among vendors through joint
efforts on standardizing protocols, significant
progress has been made.
However, the ultimate goal of making Web
services interact seamlessly is still a frequent
concern and a hot discussion topic. Explore the
source of some common interoperability
challenges facing Web services integration
across platforms and join in analyzing a number
of interoperability problems resulting from
interaction styles, basic data types and structures,
and namespace issues between .NET and J2EE
technology.
Start from WSDL
Ultimately all Web services interoperability
issues center on the WSDL file. WSDL is the
interface definition language (IDL) of Web
services and the contract between the client and
the server. The services semantics, namely the
message types, data types, and interaction styles
in the WSDL file, are the key to building
loosely-coupled systems. Even though WSDL
does not mandate the use of a particular type
system, the XML Schema data type (XSD) is
widely embraced by the Web services
community.
Bootstrapping and configuration (as shown)
consists of using a URL to access a web service,
retrieving its WSDL file, and using the WSDL
file to create a web service client that can access
and consume a web service. The process consists
of the following steps
1. Client acquires the URL for a web service that
it wants to access and consume. How you
acquire the URL is outside the scope of this
tutorial. For example, you might look up the
URL in a Web Services registry.
2. The client uses the URL and the WS import
tool to send a Metadata Exchange Request to
access the web service and retrieve the WSDL
file. The WSDL file contains a description of the
web service endpoint. The description describes
the requirements that must be satisfied to access
and consume the web service.
3. The client uses the WSDL file to create the
web service client.
Bootstrapping and Configuration
A service-oriented architecture is an
information technology approach or strategy in
which applications make use of (perhaps more
accurately, rely on) services available in a
network such as the World Wide Web.
Enterprise architects believe that SOA can help
businesses respond more quickly and cost-
effectively to the changing market conditions.
This style of architecture promotes reuse at
the macro (service) level rather than micro
levels (eg. objects). It can also simplify
4. The web service client accesses and consumes
the web service.
Service Oriented Architecture
Service Oriented Architecture is the future of IT
services. An SOA lets you integrate virtually all
of your IT resources, including isolated data and
previously incompatible legacy, .NET and Java
technology applications. Sun and its partners
have everything you need to create, use, manage,
and secure an SOA solution.
interconnection to and usage of existing IT
(legacy) assets.
In some respects, SOA can be considered an
evolution in architecture, not a revolution. It
captures many of best practices or actual use of
the architectures that came before it. In
communications systems, for example, there has
been little development in recent years of
solutions that use truly static bindings to talk to
other equipment in the network, but by formally
embracing an SOA approach, solutions are better
positioned to stress the importance of well- (Fig: Simple Object Access Protocol

defined, highly interoperable interfaces. (SOAP))

SOAP provides "a message construct that can be

SOA principles:- exchanged over a variety of underlying
The following guiding principles define the protocols" according to the SOAP 1.2 Primer. In
ground rules for development, maintenance, and other words, SOAP acts like an envelope that
usage of the SOA: carries its contents. One advantage of SOAP is
• Reuse that it allows rich message exchange patterns
• Granularity ranging from traditional request-and-response to
• Modularity broadcasting and sophisticated message
• Composability correlations. There are two flavors of SOAP web
• Componentization services, SOAP RPC and document-centric
• Interoperability SOAP web service. SOAP RPC web services are
Compliance to standards (both common and not SOA; document-centric SOAP web services
industry-specific) are SOA.
SOAP Web service
A SOAP web service introduces the following SOAP RPC Web Services
constraints: Except for binary data attachment, A SOAP RPC web service breaks the second
messages must be carried by SOAP. The constraint required by an SOA. A SOAP RPC
description of a service must be in WSDL. Web service encodes RPC (remote procedure
A SOAP web service is the most common and calls) in SOAP messages. In other words, SOAP
marketed form of web service in the industry. RPC "tunnels" new application-specific RPC
Some people simply collapse "web service" into interfaces though an underlying generic
SOAP and WSDL services. interface.
Effectively, it prescribes both system behaviors
and application semantics. Because system
behaviors are very difficult to prescribe in a
distributed environment, applications created
with SOAP RPC are not interoperable by nature.
Many real life implementations have confirmed
this.
Faced with this difficulty, both WS-I basic
profile and SOAP 1.2 have made the support of
RPC optional. RPC also tends to be instructive
rather than descriptive, which is against the spirit
of SOA. Ironically, SOAP was originally
designed just for RPC. It won't be long before
someone claims that "SOAP" actually stands for
"SOA Protocol".
Features & Benefits XML - a markup language for describing data in
Web Services Interoperability Technology message payloads in a document format
(WSIT) provides interoperability between Java
Web Services and Microsoft's Windows
Communication Foundation. It focuses on
enterprise class features such as security, reliable
messaging, and atomic transactions. Helps you
build, deploy, and maintain Composite
Applications for your Service Oriented
Architecture.
Interoperability is accomplished by
implementing a number of WS-specifications
and holding plug fests where Sun and Microsoft
Enders work together testing our respective
implementations of those specifications.
As an extension to JAX-WS, WSIT provides
Service Oriented Architecture
additional interoperability between Java Web
Services and Microsoft's Windows
HTTP (or HTTPS) - request/response protocol
Communication Foundation. It focuses on
between clients and servers used to transfer or
enterprise class features such as security, reliable
convey information SOAP - a protocol for
messaging, and atomic transactions. From a
exchanging XML-based messages over a
functional point-of-view the main features
computer network, normally using HTTP
enabled by the above specifications are:
Web Services Description Language (WSDL) -
1. Bootstrapping communication (WS-Metadata XML-based service description that describes
Exchange) the public interface, protocol bindings and
2. Securing communication (WS-Security message formats required to interact with a web
Policy, WS-Security, WS-Trust) service
3. Optimizing communication (MTOM, WS-
Secure Conversation) Universal Description, Discovery, and
4. Enabling reliability (WS-Reliable Messaging) Integration (UDDI) - An XML-based registry to
5. Enabling atomic transactions (WS- publish service descriptions (WSDL) and allow
Coordination, WS-Atomic Transactions) their discovery

SOA and Web service protocols Note, however, that a system does not
Service-oriented architecture is often defined as necessarily need to use any or all of these
services exposed using the Web Services standards to be "service-oriented." For example,
Protocol Stack. The base level of Web services some service oriented systems have been
standards relevant to SOA includes the implemented using Cobra.
following:
Do not expose unsigned numerical data types in Avoid passing an array with null elements
Web services methods. Consider creating between Web services clients and servers. Do
wrapper methods to expose and transmit the data not expose unsigned numerical data types in
types. Take care when mapping XSD types to a Web services methods. Consider creating
value type in one language and to a reference wrapper methods to expose and transmit the data
type in another. Define a complex type to wrap types.
the value type and set the complex type to be
null to indicate a null value. Take care when mapping XSD types to a value
type in one language and to a reference type in
Since base URIs are not well-defined in WSDL another. Define a complex type to wrap the value
documents, avoid using relative URI references type and set the complex type to be null to
in namespace declarations. To avoid conflicts indicate a null value.
resulting from different naming conventions
among vendors, qualify each Web service with a Because base URIs are not well-defined in
unique domain name. Some tools offer custom WSDL documents, avoid using relative URI
mapping of namespaces to packages or provide references in namespace declarations. To avoid
refactoring of package names to resolve this conflicts resulting from different naming
problem. conventions among vendors, qualify each Web
service with a unique domain name. Some tools
Develop a comprehensive test suite for Web offer custom mapping of namespaces to
Services Interoperability Organization (WS-I) packages or provide re-factoring of package
conformance verification. names to resolve this problem.
Develop a comprehensive test suite for Web
Summary of best practices for Web Services Interoperability Organization (WS-I)
services interoperability conformance verification.
Design the XSD and WSDL first, and program .
against the schema and interface. If at all
possible, avoid using the RPC/encoded style. References
Wrap any weakly-typed collection objects with [1] J2EE Web Services by Richard Monson-
Haefel - Computers – 2003
simple arrays of concrete types as the signature [2] Extending Web Services Technologies: The
for Web service methods. Use of Multi-Agent Approaches - Page by
Lawrence (EDT) Cavedon - Computers - 2005
[3] Java Web Services by Dave Chappell, Tyler
Jewell - Computers - 2002