Developing%20Web%20Services:%20SunONE%20vs%20.NET

1
Developing Web Services SunONE vs .NET

• Abner Mendoza
• mendoza_at_microagecs.com
• Selen Ustun
• selen_at_cs.tamu.edu

2
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

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

4
Technical Motivations for Web Services

• Technologists are looking for the simplicity
  and flexibility promised, but never delivered, by
  RPC architectures and object-oriented
  technologies.

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

6
Why not CORBA or DCOM?

• Each of these technologies handles key
  functionality in its own, propriety way.
• CORBAs 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).

7
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

8
The Service-Oriented Architecture (SOA)
9
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.

10
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

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

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

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

14
Architecting Web Services
Service Conversations (WSCL)
Service Composition (WSFL)
UDDI
Service Discovery
Service Publication
Security
Management
Transactions
Quality of Service
Service Description (WSDL)
Endpoint Description (WSEL)
Service Impl. Definition
Service Interface Definition
Wire Protocol (SOAP)
XML
Network (HTTP, SMTP, etc)
15
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.

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

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

18
SOAP Implementations
Vendor Languages Platforms
Microsoft Visual Basic, C Windows
Apache Java UNIX, Windows
SOAPLite Perl UNIX, Windows
Systinet, WASP C, Java UNIX, Windows
GLUE Java UNIX, Windows
19
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.

20
Apache SOAP

• Open-source Apache SOAP 2.2 at http//xml.apache.o
  rg/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.

21
SOAP Interoperability
Feature Apache SOAP 2.2 MS SOAP Toolkit 2.0 SP2
Data Types Data Types Data Types
Custom Encoding Styles Yes Limited
Arrays Arrays Arrays
Single dimensional Yes Yes
Multidimensional No Yes
Partial No No
Sparse No No
22
SOAP Interoperability
Feature Apache SOAP 2.2 MS SOAP Toolkit 2.0 SP2
Fault Fault Fault
Actor Limited Limited
Complex detail Yes Yes
XML schema data types Yes Yes
Attributes Attributes Attributes
mustUnderstand Yes Limited
actor Limited Limited
root Yes No
23
SOAP Interoperability
Feature Apache SOAP 2.2 MS SOAP Toolkit 2.0 SP2
id/href Yes Limited
HTTP HTTP HTTP
M-POST No No
Object serialization Yes Yes
UTF-8 support Yes Yes
Transports Transports Transports
SMTP Yes No
24
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 Attachments Attachments
SOAP attachments support Yes No
25
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

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

27
WSDL the Microsoft Way

• WSDL files are generated with SOAP Toolkit. This
  file is standard WSDL, and its generated
  automatically.
• However, Microsofts 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
  Microsofts propriety language for this
  particular purpose.
• The Microsoft SOAP Toolkit generates WSML files
  automatically.

28
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.c
  om/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.

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

30
UDDI Implementations

• First two public UDDI registries made available
  are
• Microsofts (http//uddi.microsoft.com)
• IBMs (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.

31
The Microsoft UDDI SDK

• Available at http//www.microsoft.com/downloads/re
  lease.asp?ReleaseID30880
• Requires
• Windows 2000 Professional, Server, or Advanced
  Server
• Visual Studio .NET Beta2
• SQL Server 2000 Desktop Engine (MSDE), Personal,
  Standard, or Enterprise Edition.

32
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 IBMs Web Services
  Toolkit (WSTK).
• WSTK toolkit is available at http//www.alphaworks
  .ibm.com/tech/webservicestoolkit

33
Sun Open Net Environment Sun ONE

• The Sun Open Net Environment (Sun ONE) is Suns
  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 users 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.

34
Sun ONE Framework
35
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

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

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

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

39
Web Services with J2EE
40
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.

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

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

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

44
Web Services with J2EE

• Web browsers and wireless devices connect to
  JavaServer Pages (JSPs) which render user
  interfaces in HTML, XHTML, or WML.

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

46
Web Services with .NET
47
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.

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

49
Web Services with .NET

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

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

51
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
52
Comparison of J2EE and .NETSingle 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 vendorMicrosoft.

53
Comparison of J2EE and .NETSupport 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.

54
Comparison of J2EE and .NETSupport 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).

55
Comparison of J2EE and .NETLanguage 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.

56
Comparison of J2EE and .NETLanguage 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.

57
Comparison of J2EE and .NETPortability

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

58
Comparison of J2EE and .NETShared 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.

59
Comparison of J2EE and .NETShared 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.

60
Comparison of J2EE and .NETShared 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.

61
Comparison of J2EE and .NETShared 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.

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

63
Future ConceptsComputing 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.

64
Future ConceptsComputing 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.

65
Future ConceptsComputing 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.

66
Future ConceptsOntologies 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.

67
Future ConceptsOntologies 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.

68
Future ConceptsOntologies 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.

69
Future ConceptsSoftware 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.

70
Future ConceptsEmbedded 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.

71
Future ConceptsEmbedded 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.

72
Thank You