WebServices SOA

Document Sample
WebServices SOA Powered By Docstoc
					Web Services and Service
Oriented Architecture

                    Aravind Sriram
Today’s Web
 Web designed for application to human interactions
 Served very well its purpose:
    Information sharing: a distributed content library
    Enabled B2C e-commerce
    Non-automated B2B interactions
 How did it happen?
    Built on very few standards
    Shallow interaction model: very few assumptions made
     about computing platforms
    Result was ubiquity
                 Involve a whole learning curve
        Not based on standardized rules and specifications

Module    CORBA   Module
  A                 B



                           Module   RMI   Module
                             A              B
What’s next?
 The Web is everywhere. There is a lot more we can do!
    E-marketplaces.
    Open, automated B2B e-commerce.
    Business process integration on the Web.
    Resource sharing, distributed computing.
 Current approach is ad-hoc on top of existing standards.
    e.g., application-to-application interactions with HTML
 Goal:
  enabling systematic application-to-application
  interaction on the Web.
             Web Services
Standardized method of communication between
             software applications

    Distributed components are interfaced
       via non-object-specific protocols

      Module                         Module
        A                              B

       C++                            Java
What is a web service?
  W3C Definition:
    A Web service is a software application identified by a URI, whose
     interfaces and binding are capable of being defined, described and
     discovered by XML artefacts and supports direct interactions with
     other software applications using XML based messages via internet-
     based protocols
  Other definitions
    “Web services” is an effort to build a distributed computing platform
     for the Web.
    enabling systematic application-to-application interaction on the
     Designing Web Services
 Goals
    Enable universal interoperability.
    Widespread adoption, ubiquity: fast!
      Enable (Internet scale) dynamic binding.
    Efficiently support both open (Web) and more constrained
 Requirements
    Based on standards. Pervasive support is critical.
    Minimal amount of required infrastructure is assumed.
        Only a minimal set of standards must be implemented.
    Very low level of application integration is expected.
        But may be increased in a flexible way.
    Focuses on messages and documents, not on APIs.
Web Services Framework
 Describe
 Expose—Services register in a repository providing
    Business information (White pages)
    Service information (Yellow pages)
    Binding information (Green pages) describing how to connect and
     use the services
 Invoke—Remote application can invoke service
 Respond—When service is invoked, results are returned to the
 Manage/Govern – Provided structure and process control
Fundamentals of Web Services
A web service is a programmable component that provides a service and is
accessible over the Internet.

                    Instance                                Client

Component           Instance                                 Client

                    Instance                                Client
Fundamentals of Web Services
        Web services stack
    Fundamentals of Web Services
                     Web services stack

       Service & Information Layer




   Service                                Port Type

                 Web Service Interface
                       (WSDL)              Service
Using WSDL
1.   Describe the message interchange formats the service can support
2.   WSDL may define where the service is available and what
     communications protocol is used to talk to the service.
3.   As extended IDL: WSDL allows tools to generate compatible client
     and server stubs.
4.   Allows industries to define standardized service interfaces.
5.   Allows advertisement of service descriptions, enables dynamic
     discovery and binding of compatible services.
6.   Provides a normalized description of heterogeneous applications.
   WSDL Document
   Abstract         interface      Logical grouping of operations
   interface        message
  definition)                      Data description using XML Schema
   Concrete                        Actual data structures used to pass
   (service          binding       data
  Definition)     endpoint/port

      Service Definition = Abstract + Concrete
      Service Description = Service Definition + Supplementary Definitions
    XML-eXtensible Markup Language
 In Web services, a message is an XML document information item as
    defined by the XML Information
 The Information items generally maps to the various features in an
    XML document, such as elements, attributes, namespaces, and
    comments ….

 All the technologies in Web Services are XML based
      Messaging
      Description       Are all in XML
      Registry

 Why?
Fundamentals of Web Services
                 Web services stack
   Packaging Layer

Simple Object Access Protocol (SOAP) is a lightweight protocol
designed for the exchange of information using XML
Defines a modular packaging model and the encoding
mechanisms for encoding data within modules .


                             Encoding rules

            SOAP             RPC representation
Fundamentals of Web Services
                   Web services stack
    Protocol Layer

 Any of the standard Internet protocols may be used to invoke web
 services over the network .

 The initial definition focuses specifically on HTTP/1.1 and the
 encrypted HTTPS

 FTP and SMTP can also be used
  Invoking a web service

A client invoking a Web service
      Discovery Layer

 The Universal Description, Discovery, and Integration protocol, or
  UDDI, specifies a protocol for querying and updating a common
  directory of Web service information.

 UDDI directory approach can be used when Web service information is
  stored in well-known locations.

 UDDI provides inquiry and publishing API’s
 Microsoft, IBM and SAP host the UDDI Business Registry.

 Directory entry has three primary parts – the service provider, Web
  services offered, and bindings to the implementations.

 Dynamically discovered Web services explicitly announce their arrival
  and departure from the network.
     UDDI Universal Description Discovery
     and Integration           3.
      1.            SW companies, standards
                    bodies, and programmers
                    populate the registry with
                    descriptions of different              Marketplaces, search
                    types of services                      engines, and business
                                                           apps query the registry
                                                           to discover services at
2.                                                         other companies

     • Businesses                 Business                   4.
     populate                                    Service
     the registry with
     descriptions of the
     services they                                           Business uses this
     support                                                 data to facilitate
                                                             easier integration
                                                             with each other
                                                             over the Web
Web Services Pros and Cons
Pros                             Cons
 Global method for describing    Emerging technology
  and finding Internet–based
                                  Managing and Tracking changes
  business services
                                   is a challenge
 Packaging and publishing of
  applications in a readily       Transactions not fully addressed
  understood format               Multiple, evolving security
 New revenue streams through      standards
  syndication of existing         Processing overhead
  application as Web Service
Future Vision and Challenges
 Technology vendors plan to develop, market, and lend online Web
  services to fulfill virtually any business function.

 Companies will be able to simply search a public directory of
  applications and download those that fit their needs.

 Right now we have only tools and standards which are still not matured,
  but it’s needless to say that its time to learn and practice some web
  services development

 Google

 A great search engine
    but what if I want my own GUI?
Google web service
 Google offers a web service that performs searches for
 Why?
     clients can build custom GUIs
     google.com can make money!

// ask google to search for us...
google = new GoogleSearchService();
result = google.doGoogleSearch("4a8/TvZQFHID0WIWnL1CMmMx0sNqhG8H",
                    txtSearch.Text, 0, 10, false, "", false, "", "", "");

// display resulting URLs...
foreach (ResultElement re in result.resultElements)
(1) Building a web service
 Start by creating a project of type “ASP.NET Web
A web service is…
 One or more objects that respond to web-based
 method calls
   there is no GUI design to a web service
    only raw classes with methods…
public class Service1 : System.Web.Services.WebService
 Looks like C#, but keep in mind these are web-based methods
       client could be calling from any platform
       parameters passed using XML

public class Service1 : System.Web.Services.WebService
  public int Add(int x, int y)
    return x + y;

    public string[] Attendees()
      <<open DB, read attendees into array, return it>>
(2) Building a client
 Start by creating a client…
    WinForm, WebForm, console-based, anything you
    for fun, let's use VB…
Reference the component
 As usual, we need to reference component
    this will activate IntelliSense
    this will make sure we call it correctly
    this will enable underlying XML +
     SOAP communication
 How?
    project references, right-click, Add web reference…
    type URL for web service, e.g.
        http://localhost/WebService/Service1.asmx

                  web        service      class
                 server       name        name
Program against component
 Treat web service like any other class!
     use new to create instances
     make method calls
     pass parameters
Private Sub Button1_Click(...) Handles Button1.Click
 Dim i, j, k As Integer

 i = CInt(TextBox1.Text)
 j = CInt(TextBox2.Text)

 Dim obj As localhost.Service1
 obj = New localhost.Service1()
 k = obj.Add(i, j)

 MessageBox.Show("Sum = " + k.ToString())
End Sub
Underlying execution…
                                            web service

     client app

       obj.Add(i, j);                       obj.Add(10, 20);

                                             Web server

              HTTP request: Service1.asmx
Service Oriented Architecture
  Allows a collection of services to communicate with each other and
     unifies processes by collecting smaller service modules in an ad hoc
    Operational
    Implementation
    Architectural
    Business
    Principles
SOA Concept
  SOA enables a standards-based marketplace of service
   consumers and service providers across an enterprise
   community or across the Web
  SOA is a specification-based architecture to transition the
   technical landscape to a standards-based, vendor
   independent, and loosely-coupled information sharing
     Decoupling the service contract from the service
     Promoting design and invocation by contract
 Basic Components of SOA

Basic Component of SOA
De-mystifying SOA
 SOA is…                SOA is NOT…
A design philosophy    A technology or a
 and Architecture        methodology

A means                Not an end
A solution             Not a product
Achieved through Web   Only Web Services
 Services and related
SOA Requirements
• Agility
• Use of standards
• Separation of concerns
• Reuse
• Interoperability between different systems and programming
• Clear and unambiguous description language
• Retrieval of the service
• Security
The Architecture
  SOA - an evolution in objectives

   From                              To
   Function oriented                 Process oriented
   Build to last                     Build to change
   Prolonged development cycles      Incrementally built and deployed

   Application silos                 Orchestrated solutions
   Tightly coupled                   Loosely coupled
   Structuring applications using    Structure applications using services
   components or objects

   Known implementation              Implementation abstraction
The Architecture
   Building an SOA - a Closer look at services

Services in a Service-Oriented Architecture are always:
SOA services neither remember the last thing they
were asked to do, nor care what the next is.
A service must be “discoverable” by potential consumers
of the service
The SOA service interface describes, exposes, and
provides an “entry point” to the service.
SOA services are, by nature, composite.
The Architecture
       Building an SOA - a Closer look at services

Only one implementation of a given service should exist
in an SOA.
Loosely coupled
Loose coupling allows the concerns of application features
to be separated into independent pieces.
Governed by policy
Services are built by contract.
Independent of location, language, and protocol
Services are designed to be location-transparent and
The Architecture
          Building an SOA - a Closer look at services

As Coarse-grained as possible
Services are typically coarse-grained business functions.
Granularity is a statement of functional richness for a service –
the more coarse-grained a service is, the richer the function
offered by the service.
Potentially Asynchronous
Asynchronous communication is not required of an SOA service,
but it increases system scalability through asynchronous behavior
and queuing techniques.
SOA Infrastructure Standards
    • WSS                                                   • WS-RM
    • SAML                                                  • WS-RM policy
    • XACML                                                 • WS-Policy
    • XML-Signature                                         • WS-Addressing
    • XML-Encryption                                        • WS-Notification
    • WS-Trust
    • WS-Policy                                                                                      • UDDI
    • WS-SecurityPolicy                                                                              • ebXML
    • XKMS                                                                                           • WS-Discovery
                          Security              Messaging              Service Discovery

                          Mediation            Governance                 Management

                                                                                           • WSDM
   • XSL                                                                                   • WS-Management
   • BPEL
                                      • WS-Policy
                                      • XQuery
                                      • XPath
     Steps to Implement SOA
1. Create/Expose Services
2. Register Services
3. Secure Services
4. Manage (monitor) Services
5. Mediate and Virtualize Services
6. Govern the SOA

Source: SOA Software, Inc., 2008.
1. Create & Expose Services
    Three primary choices
           Rebuild existing applications using SOA paradigm
           Expose existing application logic as a set of services
           A combination of rebuild and expose
    Enterprises typically use a combination of rebuild & expose
    Granularity is a key criterion for Web Service

2. Register Services
     Application architects & developers need to know that a service exists
     Use a registry

Source: SOA Software, Inc., 2008.
    3. Secure Services
           May have inadvertently created gaping security holes
           May have exposed sensitive information
           principles of security

    4. Manage Services
       Look for potential disaster
       Need to be able to monitor for
            Basic Availability
            Performance
            Throughput
            SLA agreement

    Source: SOA Software, Inc., 2008.
5. Mediate & Virtualize Services
      As SOA matures may need to:
           Introduce new versions
           Increase capacity by running multiple instances
           Provision applications to use specific instances of services
      Solution is Virtualization
      XML transformation can be used to allow consumers to use an old version of service
       that no longer exists.
      Consumers can provide different policy requirements for different classes of users
      Transport bridging can be provided
           E.g. HTTP and JMS
      Meditation between different standards implementation or versions of standards
      Mediation between different messaging styles
           RSS, SOAP, REST, Plain old XML (POX)
      Content-or-context-based routing to deliver advanced load-balancing and high-
       availability capabilities

Source: SOA Software, Inc., 2008.
    6. Govern the SOA
        Use a governance framework
        Design Time Issues
        Run Time Issues
        Tools needed for active participants
        Service Developer needs tools to:
              Publish, categorize, define meta-data, virtualize
              Choose policy, participate in capacity planning & access workflow
        Service Consumer needs tools to:
              Facilitate service discovery, selection & access workflow
        Operations Staff need to:
              Monitor service performance
              Troubleshoot problems, monitor dependencies
              Version services, virtualization & proxy management

    Source: SOA Software, Inc., 2008.
Govern the SOA Cont’d
      Security Staff needs tools to:
         Manage policy, report policy, check compliance, audit security
     Enterprise Architect needs tools to:
         Monitor application, manage relationships
         Define & validate design policy
         Assign services to proxy
         Virtualize services
     Enterprise IT Management
           Manage reuse metrics
           Gather service reuse statistics
           Gather SOA statistics

Source: SOA Software, Inc., 2008.
Enterprise Service Bus (ESB)
 ESB is the backbone of SOA that acts as a message
  broker providing a message queuing system using
  industry standard specifications for messaging such as
  SOAP, or JMS (Java Message Service).
 Expert Sally Hudson, an IDC analyst, describes the
  Enterprise Service Bus as an open standards-based
  messaging means designed to provide interoperability
  between larger-grained applications and other
  components via simple standard adapters and
ESB Architecture
                     ERP                  .NET                 Web Services

  Transformation                 SOAP/                  SOAP/                 Connection Layer
     (XSLT)                JCA   HTTP                   HTTP

                                                                                     Communication Layer
                   Reliable Asynchronous Secure Messaging

                       SOAP/                                                  Connection Layer
                       HTTP                      JMS

                         C/C++ Legacy                   J2EE
According to the SOA
                    A Web service is:
 An interface that describes a collection of   network accessible
 Described using a service description language
 Published by making this service description available to
 Found by sending queries to a registry matching service
 Bound-Invoked by using the information contained in the
service description
 Composed with other services to create new services (service
How it all works together
   Provides location independence: Services need not be
    associated with a particular system on a particular
   Protocol-independent communication framework
    renders code reusability
   Offers better adaptability and faster response rate to
    changing business requirements
   Allows easier application development, run-time
    deployment and better service management
Benefits (cont.)
  Loosely coupled system architecture allows easy
   integration by composition of applications,
   processes, or more complex services from other
   less complex services
  Provides authentication and authorization of
   Service consumers, and all security functionality
   via Services interfaces rather than tightly-coupled
  Allows service consumers (ex. Web Services) to
   find and connect to available Services dynamically
 Thank You

Shared By: