Distributed Computing Microsoft Solutions

Document Sample
Distributed Computing Microsoft Solutions Powered By Docstoc
					            Distributed Computing
           Present Microsoft Solutions
   MS .NET
                 Introduction
                 Architecture
                 Implementation
                 Current Issues
                 Future work
   Web Services
                 Introduction
                 Service-Oriented Architecture
                 Web Service Architecture
                 Implementation
                 Current Issues
                 Future work
   SOAP
                 Introduction
                 Architecture
                 Implementation
                 Current Issues
                 Future work
   Real World Implementation
The .NET Framework

 VB      C++      C#       JScript    …

      Common Language Specification


                                           Visual Studio.NET
Web Forms Web Services
 Mobile Internet Toolkit

            ADO.NET and XML

            Base Class Library

        Common Language Runtime

            Operating System
Unified programming models
          Consistent API availability regardless of
            language and programming model

                 .NET Framework
    RAD,            Subclassing,                 Server based,
 Composition,          Power,                      Stateless,
  Delegation       Expressiveness                 Projected UI

VB Forms               MFC/ATL                        ASP

                    Windows API
What is .NET?
   Microsoft development tool and distributed computing
   A software platform for XML Web Services
   Built with heavy emphasis on the creation of Web Services
          Common Language Runtime

          Unified programming classes

          ASP.NET
.NET Interoperability
      There is conformance to the Virtual Object System (VOS)
       object model
      There is conformance to the Common Language
   THEN
      Cross-language inheritance is possible
      No need to write wrappers, or IDL
         N.B. This will impact on our understanding of
          information-hiding interfaces for components!!!
      Cross-language debugging in Visual Studio.NETtm
      Cross-language exceptions
   BUT
      Not possible for many non-OO languages
      Features like overloading are difficult issues
      Multiple-inheritance not supported
The .NET Challenge
   .NET is Microsoft's new development platform
      Announced in 1999
      First products in 2000
      Designed to REPLACE COM+
         Throws away the “binary component” model
              Permits programmer customisations
         Rewrites DNA
         Targets web services
              i.e., the Java market
         Permits mixing of form and content in language-
           neutral way
              Radically challenges the idea of components as
               “interface + implementation” which was common
               to all prior CEEs
The .NET framework

                               .NET platform,
        Web Services           Visual Studio.NET, C# etc.,

   Interchange, persistence      ADO+, XML, SOAP

                              Common libraries,
    Reusable Components       Frameworks, ‘# components’

     Common Language
.NET Library Examples
System.Collections          ArrayList,bitArray,Dictionary,Hasht
                            able, Queue, SortedList, Stack etc.

System.Globalization        Calendar,NumberFormatInfo,
                            RegionInfo etc..

System.Net                  WebRequest,WebResponse,TopClie
System.Reflection           Assembly, ConstructorInfo,
                            FieldInfo, MemberInfo etc.
System.Web.UI.WebControls   AdRotator, BorderStyle, DataGrid,
                            Hyperlink, ListBox etc.,
System.WinForms             Button, Checkbox, Form, ListBox
System.Drawing.Design       BitMapEditor,
                            DrawingToolboxItem, FontEditor
Personal Remarks
   .NET provides plumbing for interesting new
   Opportunity for experimenting with new
    programming languages
   We can start asking questions:
       what new higher-level facilities can be designed
       how can we contribute: improvements, extensions,
   Not PDC Questions:
       when it will be available?
       Will it have this feature?
.NET : Role of CLR and Reflection
   Role of CLR
      more and more programs run on server
      avoid memory leaks
    Simplifies programming
      Avoid burden of reference counting
    Reduce incompatibilities
      Objects are remotely accessible
      More easily reproduced if built on same basic elements

   Reflection
    Avoids IDL
      Slight incompatibilities in CORBA
    Avoids type libraries
    Provides for dynamic invocation
    Allows customization
      e.g. serialization
MS .NET : Distributed Applications Model
   Intranet model
       .NET Remoting
       .NET to .NET
   Internet model
       Web services
       HTTP to HTTP
       Ad hoc services for .NET clients
MS .NET Remoting
   Set of services that enable applications to
       Applications can reside on the same computer
       On different computers in the same LAN
       Across the world in "very" different networks and
        running on heterogeneous platforms
   Enable communication between objects in
    different AppDomains or processes
       Different transportation protocols
       Different serialization formats
       Object lifetime schemes
       Modes of object creation
MS .NET : CLR Host
   The CLR provides an execution environment for
    code with services like garbage collection, security,
   Today, .NET executables require a piece of code to
    start the CLR up and running
       exe stub, ASP.NET ISAPI, IE 5.01+, Yukon
   In order to run managed code, the CLR Host must
    obtain a pointer to an entity called app-domain
       Normally, it is the default domain within the process
       Can create extra domains in the process
MS .NET : AppDomains
   Managed code runs in an application domain
   AppDomains are separate units of processing that
    the CLR recognizes in a running process
   AppDomains are separated from one another
       Similar to process boundaries but more lightweight

                                           Creates a CLR host and inject
                                           code in the default domain
dotnet.exe         Unmanaged Stub

                                                                    CLR Host

                                    Managed Code        Isolation
                               Default AppDomain
MS .NET : Isolation
   Managed code must get through a verification
    process before it can be run
       Code that passedd the test is said to be type-safe
   The certainty to run type-safe code allows the CLR
    to provide a level of isolation as strong as the
    process boundary, but more cost-effective
   The CLR enforces isolation by preventing direct
    calls between objects in different AppDomains
   .NET Remoting refers to the set of system services
    to access objects between domains
MS .NET : Remoting and AppDomains
    .NET Executable                         .NET Executable
           Stub                                    Stub

 Instantiates the CLR host               Instantiates the CLR host
   and inject code in the                  and inject code in the
    default AppDomain                       default AppDomain

  Process primary thread                  Process primary thread

    Default       Other      (local or      Default       Other
  AppDomain    AppDomains                 AppDomain    AppDomains

         Remoting                                Remoting
MS .NET : Marshaling
   Marshal by value
       Object is instantiated on the client and filled with
        data coming from the server
       State of the object downloaded
   Marshal by reference
       The object lives on the server and any calls take
        place remotely
       Input parameters and return value travel over
        the network
MS .NET : MarshalByRef
Client                             Server

 Stub    Proxy                      Stub    Proxy

            Object, method,
            and params
                                               Return values

MS .NET : Remote Components
 Class derived from MarshalByRef
 Public methods
 Work with serializable classes
 Application Host
       IIS, NT service, custom app
       Requires manual activation
       Publish your components
MS .NET : Client Applications
    Need a reference to the server component
    Mark the remote type as "well-known"
         Tell the run-time the type lives remotely
         JIT compiler adds code on-the-fly to transform local
          calls into remote calls
         Everything happens transparently
    Instantiated through operator new
MS .NET : COM & .Net
   COM components must be registered prior
    to use with .Net applications

   .Net Assemblies must be registered for
    use with COM components (regasm.exe)

   Regasm.exe must be run in VS.Net
    Command Prompt window.
MS .NET : COM & .Net Interoperability
   RCW: Runtime Callable Wrappers

   DLLHost.exe: host process for handling
    remote COM calls.

   TlbImp.exe: Converts COM to .Net
MS .NET : TLBIMP vs. Direct Reference

   Tlbimp.exe
       Tlbimp MyCOM.DLL /out:NetMyCOM.DLL (execute in VS CMD)
       Allows for signing the resulting assembly.
       Resulting code can be used in GAC

   Direct Reference
       Easier to use
       Does not allow for signing the assembly
       Resulting code cannot be placed in GAC or shared with other .Net
MS .NET : Dynamic Objects (.NET)
 Dynamic class creation
 Dynamic class loading
 Needed for interactive SQL interpreter

Other .NET Wire-Protocols HTTP GET
 … customized
MS .NET : Microsoft Distribution Patterns
Key degrees of freedom when distributing components

Rich Clients                           Business Components                            Data Sources

Web-based users        Web UI Farms                                                   Internal Services
                                      Process Orchestration Service Ifaces & Agents

                  Should Biz
                Components be
                                                                                Should Biz
                co-located with                    Services                 Components / BTS
               Web Components?
                                                                            be co-located with
                                                                            Service interfaces
                                                                               and agents?

                                          Deploy BizTalk
Web Service: Definitions & Properties
   Component for Web Programming
   Self-contained, self-describing, modular component that
    can be published, located, and invoked across the Web
   can be used either internally or exposed externally over the
   accessible through a standard interface
   allows heterogeneous systems to work together as a single
    web of computation
   Loosely coupled
   Ubiquitous communication
   Universal data format
Key Benefits of Web Services
   Software   as a service
   Dynamic Business Interoperability
   Accessibility
   Efficiency
   Universally Agreed Specifications
   New Market Opportunities
Service-Oriented Architecture


         Service              Service
         Broker     Find       User
Web Service Scenario
 Provider builds and defines the service in
 Provider registers the service in UDDI
 User finds the service by searching UDDI
 User application binds to the Web service
  and invokes its operations via SOAP
Web Services Stack

Web Service Architecture

 Interactions:   SOAP         Provider
     Data:   XML
Communication:    HTTP

                   Service   UDDI/WSDL   Service
                   Broker      Find       User
           Web Services Protocols
                      Find a Service

                Link to discovery document        UDDI
  Web             HTML with link to WSDL
Consumer      How do we talk? (WSDL)
              http://yourservice.com/?WSDL         Web
              return service descriptions (XML)   Service
            Let me talk to you (SOAP)
               return service response (XML)
Web Services Infrastructure
   Web services encompass a vision of a fully integrated
    computing network
   Requirements for realization
            Physical Medium (The Internet)
            Self-describing (WSDL and UDDI)
            Common Language (XML)
            Internet Protocol (SOAP)
Infrastructure Elements
       central location to locate Web Services provided by other
   organizations (e.g. UDDI registry)

       locating WSDL for a particular Web Service

       defines what interactions the Web Service supports

Wire Formats
       enable universal communication (e.g. SOAP)
Application development using Web services

                                 American Forests

MD    VA     DC                  CBP             FWS

 GIS Coverages                  WQ Data     Habitat Indices


           Projection Service
What Web services mean for
Software Development
   Faster development
       Can use any modern programming language
       Do not need to duplicate code or data
   Integration
       Removes barriers for data sharing and software
       Benefits within an organization and with partners
   Took Kits
Current SOAPs & History
   SOAP 1.1 specifications
   Implementations:
      MS SOAP Toolkit 2.0
      Apache SOAP 2.2  AXIS (= SOAP 3.0)
      SOAP::Lite For Perl
      pocketSOAP
   Apache and MS are working on incompatibilities

   SOAP 0: Developed by UserLand,Microsoft, and
    DevelopMentor in 1998
   SOAP 1.0 in 2000
   W3C (World Wide Web Consortium)
       v1.1 final – May 2000
   W3C v1.2 draft – July 2001
       Specification can be found at:
        http://www.w3.org/TR/soap12/
SOAP (Simple Object Application Protocol)
Wire-protocol based on XML and HTTP that
 consists of:
     an envelope for describing what is in a
      message and how to process it
     a set of encoding rules for expressing
      instances of application-defined data types
     a convention for representing remote
      procedure calls and responses
Sample SOAP request
POST /CurrencyServer/CurrencyExchange.asmx HTTP/1.1
Host: theseus
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: http://di.unipi.it/webservices/Euro

<?xml version="1.0" encoding="utf-8"?>
  <Euro xmlns=http://di.unipi.it/webservices>
Sample SOAP reply
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>

 <EuroResponse xmlns=http://di.unipi.it/webservices>
Architecture using SOAP
The Complete Picture

                      Service Broker
                      UDDI Registry
 inquire service                          publish service
using UDDI API                           using UDDI API
   via SOAP                                 via SOAP

  Service Requester                     Service Provider
                      bind to Service
                        via WSDL
                       using SOAP
Processing inside SOAP Client
                WSDL        WSML


             WSDLOperation object

                   Num. 3
 Add(3, 4)        Num. 4              Serializer               SOAP request
                Num. 7                              SOAP
   Sum                                 Reader
                                                   Connector    SOAP reply
Server-side SOAP
                                               WSDL         WSML

SOAP request   SoapReader                       WSDLReader
                  load()                       ParseRequest | load()

                                      WSDLOperation object
                                  ExecuteOperation | GetOperationParts()

                                                   Num. 3
                                                  Num. 4                   Add(3, 4)
                                                Num. 7
 SOAP reply          Serializer
Reflection in Web Services
   SOAP proxy performs:
      Invoke(m, new object[] {arg1, arg2});
   SOAP message dispatcher:
      parses request
      creates parameter objects
      determines object requested
      instantiates object
      gets requested method
      invokes method with built parameters
WSDL Structure
Types       Data type definitions

Message     Signature of request and reply for each method
            (≈ IDL)
Port Type   <service, protocol>  operations

Operation   method  messages

Binding     Protocol and data-format specification

Service     { Port  binding }

Port        Address (≈ URL)
WSDL example
 Currency Exchange Service
 Methods
    double Rate(String From, String To)
    double Euro(String Currency)
   Service URL
Building A Server & Trust
   Simplicity
      Source file (plain text = notepad accessible)
      Compiled at run-time similar to ASP.NET pages
      Just hit save
      File extension is .asmx
   File can be inline or in separate assembly
Building Trust
   CLR exposes its elements
   Users can create elements directly
   Even when using tools, you can look at their output and
    change it
Building A Server
   <%@ WebService class=“[class]" %>
       Names the class and/or language used

   using System.Web.Services;
       Required namespace

   [WebMethod]
       Method is ‘web callable’

   Optional: WebService base class
       Access ASP.NET intrinsics
 Transition to a
 Web Services Environment
                                                  Web Server
                                        (NetBuddy 4.0 Information Server)
Any client

                  Data and control exchanged
               using XML inside SOAP wrappers

  Web Services                                      Web Services World Mail
 Client Interface                                  Server Interface
                             (UDDI)             Setup, billing,
                                              service description
Web Services Setup                               using WSDL

                     Service Broker

     inquire                             publish


 Service Requester                    Service Provider
Creating Web Service Clients
1.   Grab WSDL from Web Service
2.   Create proxy from WSDL
3.   Execute methods against proxy, passing
     input parameters
          Proxy calls Web Service on your behalf
          Web Service returns results to proxy
4.   Retrieve results from proxy
5.   Display results
ASP.NET Client
   Uses proxy and SOAP protocol to
    communicate with Web Service
   Steps:
    1.   Use wsdl utility to create local proxy
    2.   Compile proxy using vbc or csc
            Place compiled proxy assembly in bin folder of Web
    3.   Create client
            Import proxy namespace, code to proxy’s
             properties and methods
Using SOAP toolkit (no .NET)
// allocate a new SoapClient pointer
 m_pClient = new ISOAPClient;

// create the SoapClient pointer

// initialize it
m_pClient->mssoapinit ("http://www.MyService.com/SoapSamples/CalcVB.wsdl",
   "CalcVB", "CalcVBPortType", NULL);

// perform addition
double ISOAPClient::Add(double dblA, double dblB, DISPID dispid)
   double result;
   static BYTE parms[] = VTS_R8 VTS_R8;
   InvokeHelper(dispid, DISPATCH_METHOD, VT_R8, (void*)&result, parms,
   dblA, dblB);
   return result;
Client Side?
   Use HTTP GET
       handle XML yourself
 Use wsdl.exe, generate client-side
  program, invoke it through Jscript
 Use ActiveX or Java
Deployment Scenario

                  Customer                        DJInterpool
                  performs title


                            Service Broker
   Music Portal

Portal invokes          Service Broker          respond
search                     invokes search       with search
Web Service                services             results
Two-Way Web
Current Web Limitations
   Thin but weak:
       Not real-time
       Not productive
       Not interactive
 Client cannot initiate actions
 Browser pull: waste bandwidth
 Java, ActiveX: maintainability and security
Fitting the Pieces

                                                                  •   ER Metamodel
           UML                              CWM                   •   DB Creation
  Unified Modeling Language      Common Warehouse Metamodel       •   DB Loading
                                                                  •   Rules

                          XMI                               XML
                XML Metadata Interchange        eXtensible Markup Language
                                                Schemas            XML Valuetype
                     Transformation Rules       Instances (doc)

                          MOF                               IDL
                    Meta Object Facility       Interface Definition Language

                                                                         •   Java
                                                                         •   C++
                                                                         •   COBOL
                                                                         •   COM
                                                                         •   Others…
Applying to Verticals

       The opportunity is to
            reuse design & deployment artifacts
            document interface semantics
            support multiple platforms, languages, networks
 Web Services are quite promising
 Still missing:
       some plumbing, interoperability
       2-way interactivity
       unified multistage programming
   Issues:
       no more DLL Hell
       but maybe, Namespace Hell
          Distributed Computing
    Future Research Microsoft Solutions
 Microsoft Shared Source CLI
 Web services are becoming fundamental
  building blocks in the move to distributed

                              D Garg

Shared By: