Post on 18-Dec-2015
Developing Web Services: SunONE vs .NETAbner Mendoza
mendoza@microagecs.comSelen Ustun
selen@cs.tamu.edu
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
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
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
SOAP InteroperabilityFeature 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 InteroperabilityFeature Apache SOAP 2.2 MS SOAP Toolkit 2.0
SP2
id/href Yes Limited
HTTP
M-POST No No
Object serialization Yes Yes
UTF-8 support Yes Yes
Transports
SMTP Yes No
SOAP InteroperabilityFeature 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/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: 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.
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 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 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
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
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.