Developing Web Services: SunONE vs.NET Abner Mendoza [email protected] Selen Ustun [email protected]

Developing Web Services: SunONE vs .NETAbner Mendoza

[email protected] 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 candiscover 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 cross-platform 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

Service Registry Service Requester

Publish Bind

Find

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


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.


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).


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

Wire Protocol (SOAP)

XML

Network (HTTP, SMTP, etc)

Service Publication

Service Interface Definition

Endpoint Description (WSEL)

Service Impl. Definition

Service Discovery

Service Conversations (WSCL)

Service Composition (WSFL)

Security

Quality of S

ervice

Transactions

Managem

ent

UDDI

Service Description (WSDL)

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 platform-neutral 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 ImplementationsVendor 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 InteroperabilityFeature 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


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


SP2

id/href Yes Limited

HTTP

M-POST No No

Object serialization Yes Yes

UTF-8 support Yes Yes

Transports

SMTP Yes No


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/webservicestoolkit

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


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.


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).


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.


Traditional 'thick' clients such as applets or applications connect directly to the EJB layer through the Internet Inter-ORB 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 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


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.


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).


• Business partners can connect with the .NET application through web services technologies (SOAP, UDDI, WSDL, BizTalk).


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

Database access JDBC SQL/J ADO.NET

SOAP, WSDL, UDDI Yes Yes

Implicit middle-ware (load-balancing, etc.)

Yes Yes

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, goal-

oriented, 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 non-

computing, 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

Documents

Developing Web Services: SunONE vs.NET Abner Mendoza [email protected] Selen Ustun [email protected]