Transcript Developing Web Services: SunONE vs .NET

Developing Web
Services:
SunONE vs .NET
Abner Mendoza
[email protected]
Selen Ustun
[email protected]
What is a Web Service?
“A collection of functions that are packaged as a single
entity and published to the network for use by other
programs. Web Services are building blocks for creating
open distributed systems, and allow companies and
individuals to quickly and cheaply make their digital
assets available worldwide."
Graham Glass,
CEO and Chief Architect of The Mind Electric
So, a Web Service is:

A self-describing software that can
 discover
and engage other Web Services or
applications to complete tasks over the
network, and
 dynamically locate and interact with other
components on the network, to provide a
service, without intervention.
Technical Motivations for Web
Services
Technologists are looking for the simplicity
and flexibility promised, but never
delivered, by RPC architectures and
object-oriented technologies.
Why not CORBA or DCOM?



DCOM is expressly a Microsoft-only
architecture.
Although CORBA is intended to provide crossplatform interoperability, in reality it is too
complex and semantically ambiguous to provide
any level of interoperability without a large
amount of manual integration work.
The specter of marshalling executable code and
shipping it over the Internet has many security
concerns, such as viruses and worms.
Why not CORBA or DCOM?

Each of these technologies handles key
functionality in its own, propriety way.
 CORBA’s
payload parameter value format is the
Common Data Representation (CDR) format,
whereas DCOM uses the incompatible Network Data
Representation (NDR) format (Web Services use
XML).
 CORBA uses Interoperable Object References (IORs)
for endpoint naming, whereas DCOM uses OBJREFs
(Web Services use URIs, which are generalized
URLs).
Characteristics of Web Services
They are:
 described using a service description language
 published to a registry of services
 discovered through a standard mechanism (at
runtime or design time)
 invoked through a declared API, usually over a
network
 composed with other services
The Service-Oriented Architecture
(SOA)
Service Provider
Publish
Bind
Service Registry
Find
Service Requester
Operations of SOA




Service providers publish (and unpublish) their services
to a service registry.
Service requesters discover the desired Web Services
by searching for their descriptions at the service registry.
Once the requester locates the desired service, its client
binds with the service at the service provider and then
invokes the service.
SOA is responsible for


describing and organizing the mechanisms and practices for
these actions
Describing how Web Services can be combined into larger
services.
Functional Components of SOA

Service Implementation
 Develop
a new Web Service and a new service
interface
 Develop a new Web Service when there is an existing
service interface
 Develop a new service interface for an existing
application
 Create a Web Service that wraps an existing
application when you have an existing service
interface
Functional Components of SOA

Publication
 Author the Web Service description document.
 Written in the Web Services Description Language (WDSL),
this document describes what the Web Service will do, where
it can be found, and how to invoke it.
 Publish
the Web Service description document on a
Web server so that it is accessible to the desired
audience.
 Publish the existence of the document in a Web
Services registry using the Universal Description,
Discovery, and Integration (UDDI) specification.
Functional Components of SOA

Discovery
 Once
a Web Service appears in a registry, any
application can discover the service and therefore
locate the published Web Service description
document.
 UDDI registries support pattern queries for automated
lookups and return the location of the WSDL file for
the desired service.
 The location of the file is in the form of a Uniform
Resource Indicator (URI), which is a generalization of
the Uniform Resource Locator (URL).
Functional Components of SOA

Invocation
 Author
a client using the Simple Object Access
Protocol (SOAP). The downloaded WSDL file
contains the necessary information for this. Since
authoring happens on-the-fly, the Web Service can be
invoked dynamically at runtime.
 Make a SOAP call. The client then creates a SOAP
message describing what it wants the remote Web
Service to do and then sends it to the specified URI.
Typically, the Web Service returns a SOAP message
in the format detailed in the Web Service description
document.
Architecting Web Services
Service Conversations (WSCL)
Service Composition (WSFL)
UDDI
Service Interface Definition
Wire Protocol (SOAP)
XML
Network (HTTP, SMTP, etc)
Management
Service Impl. Definition
Transactions
Service Description (WSDL)
Endpoint Description (WSEL)
Security
Service Publication
Quality of Service
Service Discovery
XML


A meta-language for defining the structure and
meaning of data.
Aims at solving the problems related to getting
computer systems to interact with each other on
a programmatic level, by specifying a platformneutral approach by which objects and
programmatic functionality can be operated on a
global, distributed basis.
ebXML
An XML application to facilitate the sharing
of structured business documents.
 The ebXML standards support a specific
methodology for modeling business
requirements and processes.

 This
makes it possible to define XML
semantics for universal descriptions of
business services and processes.
Simple Object Access Protocol
(SOAP)


XML-based messaging and remote procedure call (RPC)
specification that enables the exchange of information
among distributed systems.
Advantages:





It is an open specification, available for anyone to use.
It is simple to write and is human-readable.
It is extensible, taking advantage of the power of XML to enable
loose coupling between systems.
It is a flexible protocol that is useful in both request/response and
message passing/queueing architectures.
It can be thought of as a simplified XML-based
replacement for IIOP underlying CORBA and DCOM.
SOAP Implementations
Vendor
Languages
Platforms
Microsoft
Visual Basic, C#
Windows
Apache
Java
UNIX, Windows
SOAP::Lite
Perl
UNIX, Windows
Systinet, WASP
C++, Java
UNIX, Windows
GLUE
Java
UNIX, Windows
Microsoft SOAP Toolkit



Can be found at http://msdn.Microsoft.com/soap
Requires Visual Basic runtime files, Windows Installer,
Internet Explorer 5.0, IIS, and MSXML 3.0 SP1.
Contains:




A client-side component that enables an application to invoke
Web Services operations that are described by a WSDL
document.
A server side component that maps those operations to COM
object method calls. These calls are described by the WSDL and
Web Services Meta Language (WSML) files.
Marshalling and unmarshalling components.
A WSDL/WSML document-generator tool.
Apache SOAP



Open-source Apache SOAP 2.2 at
http://xml.apache.org/soap
Originally developed by IBM, who donated it to the
Apache foundation.
Requires:




Java 1.1 or higher,
Apache Jakarta Tomcat 3.2.1 Web server and servlet engine,
Apache Xerses XML parser 1.2.3,
JavaMail (mail.jar), and the JavaBeans Activation Framework.
SOAP Interoperability
Feature
Apache SOAP 2.2
MS SOAP Toolkit 2.0
SP2
Data Types
Custom Encoding Styles
Yes
Limited
Arrays
Single dimensional
Yes
Yes
Multidimensional
No
Yes
Partial
No
No
Sparse
No
No
SOAP Interoperability
Feature
Apache SOAP 2.2
MS SOAP Toolkit 2.0
SP2
Fault
Actor
Limited
Limited
Complex detail
Yes
Yes
XML schema data types
Yes
Yes
Attributes
mustUnderstand
Yes
Limited
actor
Limited
Limited
root
Yes
No
SOAP Interoperability
Feature
id/href
Apache SOAP 2.2
Yes
MS SOAP Toolkit 2.0
SP2
Limited
HTTP
M-POST
No
No
Object serialization
Yes
Yes
UTF-8 support
Yes
Yes
Transports
SMTP
Yes
No
SOAP Interoperability
Feature
Apache SOAP 2.2
MS SOAP Toolkit 2.0
SP2
POP3
No
No
FTP
No
No
TCP
No
No
HTTP
Yes
Yes
Attachments
SOAP attachments
support
Yes
No
Web Services Description
Language (WSDL)


XML-based format for describing Web Services.
Describes:
 which operations Web Services can execute, and
 the format of the messages Web Services can send
and receive.


The WSDL standard is currently at version 1.1
and the official source of the WSDL standard is
in a W3C Note, which can be found at
http://www.w3c.org/TR/wsdl
Bridges SOAP and UDDI
WSDL Implementations

Two most popular implementations are:

The Microsoft SOAP Toolkit – Primarily aimed at developers who
want to work with SOAP in a Microsoft environment, although it
does support Microsoft’s UDDI implementation.

The IBM Web Services Toolkit (WSTK) – Provides WSDL
support, several security enhancements, UDDI integration, and
support for the IBM WebSphere application server. Also includes
the open-source Web Services Description Language for Java
Toolkit (WSDL4J).
WSDL the Microsoft Way


WSDL files are generated with SOAP Toolkit. This file is
standard WSDL, and it’s generated automatically.
However, Microsoft’s implementation requires another
file to map the invoked Web Service operations to COM
methods.


This additional file is expressed in the Web Services Markup
Language (WSML), which is Microsoft’s propriety language for
this particular purpose.
The Microsoft SOAP Toolkit generates WSML files
automatically.
WSDL the IBM Way




WSTK runs on Linux or Windows 2000/NT 4
Requires a recent installation of Java Development Kit
(JDK).
Can be downloaded from
http://www.alphaworks.ibm.com/tech/webservicestoolkit
By separating the service implementation from the
service interface, the WSTK allows the service to be
changed without affecting the interface.

This provides greater reuse and flexibility.
Universal Description, Discovery,
and Integration (UDDI)



Platform independent, open framework for describing
services, discovering businesses, and integrating
business services using the Internet as well as public
registries of Web Services designed to store information
about businesses and the services they offer.
Is also a specification for building such registries, as well
as an application programming interface (API) that
exposes the functionality of the registries.
Essentially, it provides for the publication and discovery
of Web Services.
UDDI Implementations

First two public UDDI registries made available
are:
 Microsoft’s (http://uddi.microsoft.com)
 IBM’s (http://www-3.ibm.com/services/uddi/)



They both support UDDI 2.0
Both operator sites host production and test
registries.
It is possible to interact with both registries from
either a Java or a Microsoft (Visual Basic or C#)
platform.
The Microsoft UDDI SDK


Available at
http://www.microsoft.com/downloads/release.asp
?ReleaseID=30880
Requires:
 Windows
2000 Professional, Server, or Advanced
Server
 Visual Studio .NET Beta2
 SQL Server 2000 Desktop Engine (MSDE), Personal,
Standard, or Enterprise Edition.
UDDI4J (IBM)




Java-based implementation of the UDDI APIs
written by IBM and released as open-source.
Its home page is http://oss.software.ibm.com
The package is included in IBM’s Web Services
Toolkit (WSTK).
WSTK toolkit is available at
http://www.alphaworks.ibm.com/tech/webservice
stoolkit
Sun Open Net Environment –
Sun ONE




The Sun Open Net Environment (Sun ONE) is Sun’s
standards-based software vision, architecture, platform,
and expertise for building and deploying Web Services.
Web site: http://www.sun.com/sunone
Allows users to build open, Java-based Web Services
that are attuned to a user’s location, available networked
devices, group affiliation, and current tasks.
It uses J2EE APIs and XML technologies, such as EJBs,
JSPs, JNDI, UDDI, ebXML, SOAP, WSDL, JAXP, etc.
Sun ONE Framework
Sun ONE Framework:
The Directory

The iPlanet Directory Server suite
of software delivers the software
platform necessary to collect,
distribute, manage, and protect
the most valuable core
information assets of an
enterprise, such as:


customer, employee, partner, and
supplier information, or
non-human entities, such as
products, internal resources, and
manufacturing equipment capable of
providing services
Sun ONE Framework:
The Portal


The iPlanet Portal Server provides a
connection from the user in a particular
community to the enterprise.
The iPlanet Portal Server content
aggregation capabilities enable the
aggregation of any HTML or XML
encoded content as well as virtually any
application that can be run on any major
server OS, such as Microsoft Windows
and X Windows-based applications
running on the UNIX® operating system.
Sun ONE Framework:
Application and Integration Servers

The iPlanet Application Server offers two
capabilities

It enables access to legacy pieces of the
business IT environment.
 It provides a scalable platform to run
Java technology-based business logic.


The iPlanet Integration Server allows an
enterprise to integrate all of its internal
services and make them available for
use.
Together, they provide an environment
for the execution of business logic,
integrating of internal legacy application
services and external data services.
Sun ONE Framework:
Development Tools


Forte Tools offer an integrated
development environment (IDE)
for the Java, C, C++, and
FORTRAN languages.
Forte Tools feature automatic
loading of the capabilities that the
developer needs, which


enables developers of all types to
seamlessly access the plug-ins they
need
speeds the development of a
diversity of Web-based service
components.
Web Services with J2EE
Web Services with J2EE



J2EE Application is hosted
within a container, which
provides qualities of service
necessary for enterprise
applications, such as
transactions, security, and
persistence services.
The business layer performs
business processing and data
logic.
In large-scale J2EE
applications, business logic is
built using Enterprise
JavaBeans (EJB) components.
Web Services with J2EE


It connects to databases using
Java Database Connectivity
(JDBC) or SQL/J, or existing
systems using the Java
Connector Architecture (JCA).
It can also connect to business
partners using web services
technologies (SOAP, UDDI,
WSDL, ebXML) through the
Java APIs for XML (the JAX
APIs).
Web Services with J2EE


Business partners can connect
with J2EE applications through
web services technologies
(SOAP, UDDI, WSDL, ebXML).
A servlet, which is a
request/response oriented
Java object, can accept web
service requests from business
partners. The servlet uses the
JAX APIs to perform web
services operations.
Web Services with J2EE

Traditional 'thick' clients such
as applets or applications
connect directly to the EJB
layer through the Internet InterORB Protocol (IIOP) rather
than web services, since
generally the thick clients are
written by the same
organization that authored
J2EE application, and
therefore there is no need for
XML-based web service
collaboration.
Web Services with J2EE

Web browsers and
wireless devices
connect to
JavaServer Pages
(JSPs) which render
user interfaces in
HTML, XHTML, or
WML.
Microsoft .NET Framework
Microsoft builds its Web Services using its
new ASP.NET.
 ASP.NET extends ASP by providing
support for using any .NET programming
language, use of existing components,
better support for using XML to separate
content from formatting and presentation,
and compiled code.

Web Services with .NET
Web Services with .NET


The .NET application is
hosted within a container,
which provides qualities
of service necessary for
enterprise applications,
such as transactions,
security, and messaging
services.
The business layer of the
.NET application is built
using .NET managed
components.
Web Services with .NET


This layer performs business
processing and data logic. It
connects to databases using
Active Data Objects
(ADO.NET) and existing
systems using services
provided by Microsoft Host
Integration Server 2000, such
as the COM Transaction
Integrator (COM TI).
It can also connect to business
partners using web services
technologies (SOAP, UDDI,
WSDL).
Web Services with .NET
• Business partners
can connect with the
.NET application
through web services
technologies (SOAP,
UDDI, WSDL,
BizTalk).
Web Services with .NET


Traditional 'thick' clients,
web browsers, wireless
devices connect to Active
Server Pages (ASP.NET)
which render user
interfaces in HTML,
XHTML, or WML.
Heavyweight user
interfaces are built using
Windows Forms.
Analogies Between J2EE and .NET
Feature
J2EE
.NET
Type of technology
Standard
Product
Middleware vendors
30+
Microsoft
Interpreter
JRE
CLR
Dynamic web pages
JSP
ASP.NET
Middle-tier components
EJB
.NET managed
components
JDBC SQL/J
ADO.NET
SOAP, WSDL, UDDI
Yes
Yes
Implicit middle-ware
(load-balancing, etc.)
Yes
Yes
Database access
Comparison of J2EE and .NET:
Single Vendor Solution

J2EE has spawned a wide variety of tools,
products, and applications in the marketplace
 This
provides more functionality in total than any one
vendor could ever provide.
 However, J2EE tools are often not interoperable, due
to imperfections in portability.


Larger vendors, such as IBM, Oracle, BEA, and
iPlanet, offer a complete Web Services solution.
.NET provides a fairly complete solution from a
single vendor—Microsoft.
Comparison of J2EE and .NET:
Support for Existing Systems

J2EE achieves legacy integration through:





The Java Message Service (JMS) to integrate with existing
messaging systems
Web services to integrate with any system
CORBA for interfacing with code written in other languages that
may exist on remote machines.
JNI for loading native libraries and calling them locally
But by far, the most important part of the J2EE vision for
integration is the J2EE Connector Architecture (JCA),
which is a specification for plugging in resource adapters
that understand how to communicate with existing
systems.
Comparison of J2EE and .NET:
Support for Existing Systems




.NET also offers legacy integration through the Host
Integration Server 2000.
COM Transaction Integrator (COM TI) can be used for
collaborating transactions across mainframe systems.
Microsoft Message Queue (MSMQ) can integrate with
legacy systems built using IBM MQSeries.
Finally, BizTalk Server 2000 can be used to integrate
with systems based on B2B protocols, such as
Electronic Data Interchange (EDI).
Comparison of J2EE and .NET:
Language Support


All components deployed into a J2EE
deployment (such as EJB components and
servlets) must be written in the Java language.
In order to use J2EE, at least some of the coding
should be done using the Java programming
language. Other languages can be bridged into
a J2EE solution through web services, CORBA,
JNI, or the JCA. However, these languages
cannot be intermixed with Java code.
Comparison of J2EE and .NET:
Language Support


.NET supports development in any language
that Microsoft's tools support due to the new
CLR. With the exception of Java, all major
languages are supported.
All languages supported by the CLR are
interoperable in that all such languages, once
translated to IL, are now effectively a “common”
language. A single .NET component can
therefore be written in several languages.
Comparison of J2EE and .NET:
Portability


J2EE is platform-agnostic, running on a variety of
hardware and operating systems, such as Win32, UNIX,
and Mainframe systems, since the Java Runtime
Environment (JRE), is available on any platform.
Another aspect of portability is that J2EE is a standard,
and so it supports a variety of implementations, such as
BEA, IBM, and Sun.


The danger is that if vendors are not held strictly to the standard,
application portability is sacrificed. For this, Sun has built a J2EE
compatibility test suite, ensuring compliance with standards.
.NET only runs on Windows, its supported hardware,
and the .NET environment. There is no portability at all.
Comparison of J2EE and .NET:
Shared Context


A key element of smart web services is shared context.
The vision for shared context is that the user types this
information in once, and that information is then
accessible to all web services that she chooses to give
access to that information. The information is under her
control, rather than the control of the Web Services, and
is protected using security rules that she defines.
The Sun J2EE vision for shared context is a
decentralized, distributed suite of shared context
services that live on the Internet.
Comparison of J2EE and .NET:
Shared Context



Each user might have a list of one or more of their
preferred shared context services, with each repository
storing select information about that user.
In the future, Sun J2EE will include standards to access
shared context services. This will enable the context
repositories to act as Web Services using a standard
interface, empowering other web services to connect
with and tap into the shared context service in standard
ways.
Microsoft .NET achieves shared context via the Passport
.NET service. Passport .NET is a repository hosted by
Microsoft that contains user identity information.
Comparison of J2EE and .NET:
Shared Context

Advantages of J2EE approach:

Each shared context repository can be specialized for different needs.
For example, there could be medical repositories that store medical
history information, or financial repositories that store credit card and
banking information. It is unlikely that a single repository approach such
as Passport .NET would be specialized enough to cover all the bases of
shared context information that the industry demands when smart web
services become widely used.
 Businesses and individuals do not need to trust their data to any
individual firm. Local shared context repositories can be created within a
trusted few partners in a business web, which means data can be
contained.
 There is no single point of failure.
 There is no control being enforced by a single organization.
Comparison of J2EE and .NET:
Shared Context

Advantages of .NET approach:
 There
is no question of what is the 'official' shared
context repository. There is one place to find identity
information. This is a very important point. J2EE runs
the risk of a fragmented shared context repositories,
eliminating the usefulness of such systems.
 Passport is an established and active system.
 Sun J2EE has not yet standardized on a schema and
API for accessing Web Services that are shared
context services.
Future Concepts:
Computing as a Utility


In the future computing will be viewed as a utility,
similar to electrical power or cable TV.
Personal computing example:
 Mr.
Smith arrives at his hotel room.
 There is a plug in the wall, next to the electrical and
phone outlets, labeled Computing. It takes a standard
plug type.
 He plugs in his PDA (laptop, or any other computing
platform). A network connection is automatically
established.
Future Concepts:
Computing as a Utility

Personal Computing Example:
 As
he goes about doing his work, his local software
agent (machine resident) finds the services that he is
going to need, based on where he is and what he is
about to do.


These could be software services if, for example, he is trying
to collaborate with some colleagues in a different city,
or hardware services if, for example, he needs to run a stress
simulation on the latest board design.
Future Concepts:
Computing as a Utility

Enterprise Computing Example:




On the factory floor, a new manufcturing robot is brought in and
plugged into the computing grid.
After a short initialization period, it finds a controller, requests
and receives a set of tasks, and starts working on them in
coordination with all the other robots.
On that same factory floor, as data from dealers, customers and
suppliers comes in, it is processed and interpreted as requiring a
change in the specs of the bearings being used in the wheels of
the MAXX model.
The controller finds a design and simulation Web service,
submits new requirements, and receives updated specs.
Future Concepts:
Computing as a Utility

Enterprise Computing Example:




As soon as these come in, the robot tasks are updated, and new
bearings are ordered. This is done by finding supplier Web
services.
As a conclusion, web services will be used everywhere.
Whenever a need is triggered in the system, either
through human intervention or external automated
triggers, the need will be translated into formalized
requests through intelligent interfaces.
These requests will make their way into the grid/network
and be routed intelligently to other entities who will fulfill
the request.
Future Concepts:
Ontologies and the Semantic Web

The eventual goal of the evolution of the Web is to
facilitate integration between human tasks and machine
tasks.



Therefore, meaning and context must be taken into account.
In order to realize this goal, web content, and resources
in general, have to be marked up with some structured
metadata that can be processed by machines.
XML makes structured metadata possible, but it is only a
language and another layer of meaning has to be built
on top of it.
Future Concepts:
Ontologies and the Semantic Web



This layer of meaning is exposed through Resource
Description Framework (RDF), an application of XML
developed under the auspices of the W3C.
The layer of meaning on top of RDF is provided by
ontologies.
An ontology is defined as a document containing a set of
formal definitions of relations among terms. They contain
a taxonomy of terms and a set of inference rules to make
sense of the terms, usually in machine-readable form.
Future Concepts:
Ontologies and the Semantic Web


Semantic Web technologies will eventually
converge with Web Services.
In the future, Web Service descriptions and
registires will be marked up using RDF and
there will be ontologies as a semantic
enhancement to WSDL and UDDI.
 This
will enable dynamic discovery and invocation of
services by software through common terminology
and shared meaning.
Future Concepts:
Software Agents



They are intelligent, reactive, autonomous, goaloriented, temporally continuous, communicative,
learning, mobile and flexible software programs.
They will be able to process the resource
definitions and ontologies.
They can be exposed as Web Services,
interfaces to Web Services, or parts of the
functionalities of Web Services.
Future Concepts:
Embedded Web Services
Devices in general can either be
requestors or providers of Web services.
 PDAs and cell phones are usually
considered as requestors but they can
also be providers in the future.

 For
example, my PDA might make available
my calendar as a Web service for some
restricted list of users.
Future Concepts:
Embedded Web Services

Even devices that we consider as noncomputing, may participate in Web
services world.
 For
example, my home entertainment center
may provide a list of Web services to be used
by other devices on my home LAN.

For these to happen, Web services have
to be embedded in those devices.
Thank You