1 / 84

.NET Remoting and Web Services

Explore the concept of service-oriented architecture and the implementation of web services using SOAP protocol. Learn about cross-platform and cross-language benefits, interoperability, and loosely-coupled architectures in Java and .NET environments. Discover steps for creating web services in Weblogic and understand Synchronous vs. Asynchronous messaging.

williewhite
Download Presentation

.NET Remoting and Web Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. .NET Remoting and Web Services

  2. .NET Web Services

  3. What is a Web Service? • Web services are based on the concept of service-oriented architecture (SOA) • Web services implement functionality using an RPC paradigm over the internet using a standard protocol called the Simple Object Access Protocol, or SOAP • Web services are self-describing modular business extensions that expose logic as services over internet protocols • Any service on a web server than can understand a SOAP message can be exposed as a web service

  4. Web Services Introduction • Web Services can be implemented in a variety of languages, including C#, Visual Basic, Java, C++, Perl, Python, etc. • Web services are not meant to interact with users (i.e., in providing HTML output) as a Java Servlet/JSP or ASP .NET application might • Web services deliver XML-based data over defined interfaces to other application components utilizing their services • Web services use industry-standard protocols like HTTP for transports, thus bypassing most firewall problems

  5. Web Services Introduction • Web services are supported on most distributed object platforms, including J2EE, CORBA, and Microsoft .NET and can interoperate with one another • This means that an object written in C# running on NT in .NET can utilize the services of a WS written in Java running on Linux within J2EE • Web services may be dynamically located and invoked from public registries exposed over UDDI (Universal Description, Discovery, and Integration) interfaces

  6. Web Services are based on Open Architecture standards • Web services benefits: • are cross platform • are cross language • are cross operating system • enable interoperability among heterogeneous applications • can be invoked through XML-based RPC mechanisms across firewalls • promote loosely-coupled architectures defined on common interfaces

  7. Java WebServices • A Java Web Service: • Has an implementation hosted by a Java Application Server • Incorporates a standardized way to transmit data in the form of messages from a client to a web service, using an XML-based RPC format known as JAX-RPC as part of a thin client JAR • Uses SOAP as the message format and HTTP as the connection protocol • Uses a standard way to specify the web service, using Web Services Description Language (WSDL) 1.1, and XML-based specification

  8. Sun JAX-RPC Interfaces

  9. Steps in Creating a Weblogic Web Service • Design the Weblogic web service Synchronous vs. Asychronous, backend components • Implement the web service Write backend components and message handlers If the service is based on an existing WSDL file, you can use the Ant wsdl2Service task to autogenerate much of the required server source code • Assemble and package web service Create the deployment descriptor, jar up components, deploy as an EAR (Enterprise Application Archive) file • Create a client to access the web service • Deploy the web service • Optionally publish the web service in a UDDI registry

  10. Synchronous vs. Asynchronous Messaging • Synchronous request-response (default) messaging means that every time a client invocation occurs on a web service operation, it receives a SOAP Response, even if the SOAP operation is defined as having a return type of void • Asynchronous messaging means that the client never receives a SOAP response, even in the case of a fault or exception (requires void return and no out or in-out parameters are allowed) • Specified by the invocation-style attribute of the <operation> element in the web-services.xml descriptor

  11. Web Services are typically Front-Ends! • Web Services are typically front end to: • Existing legacy applications as part of an EAI architectural effort • A method of a Stateless Session EJB (focusing on process-oriented rather than data-oriented capabilities) • A JMS message consumer or producer • A CORBA distributed object

  12. SOAP Message Handlers and Handler Chains • SOAP Message Handlers (called Formatters in .NET Web Services) can implement the Chain of Responsibility pattern and act as message stream modifiers • SOAP Message Handlers intercept SOAP messages outbound and inbound and modify the stream in various ways, including: • encryption and decryption • compression and decompression • protocol translators

  13. Stateless Session EJB Backend Component • Basically nothing new here, except that if you plan on returning a parameter or type from the EJB through the web service interface (i.e., over SOAP protocol), you will have to define a Serializable class to conduct the message • You can use the Ant servicegen or autotype tasks to introspect an existing EJB and automatically generate the serialization class(es) required • These tasks also create the required XML Schema and update your web-services.xml deployment descriptor

  14. Web Service Types • Web Services can either be RPC-oriented or Document-oriented • Document-oriented messages define a SOAP message that contains a document as opposed to an operation call • Methods that implement operations of a DOM (Document-oriented message) must have a single parameter—the document • Methods cannot use out or in-out parameters

  15. Multiple Return Types • Web services can be defined to return multiple values, either by: • Defining a return type that is inherently complex—such as an array or collection of values • Defining multiple out or in-out parameters within the parameter declaration (cf. CORBA IDL) • Use javax.xml.rpc.holders for defining out and in-out parameters: • public String myMethod(javax.xml.rpc.holders.IntHolder retInt);

  16. Java Class Backend Component • You can implement a backend component as a Java class provided you: • Define a no-argument default constructor for any Java classes that will be called by web services • Do not create any threads within the class • Write thread-safe code because although the server will maintain a single instance of the class, each invocation of the web service will multiplex threads through the single instance

  17. Microsoft WebServices • .NET Remoting is a replacement for DCOM • CLR Remoting allows remote objects to be handled as if they were local • A Remote object is an object that derives from System.MarshalByRefObject • A Remote object may be an object that is instantiated in a foreign application domain (AppDomain) and possibly in a separate CLR • WebServices may be exposed over either HTTP (internet for accessibility) or TCP/IP (intranet for speed)

  18. The Five Core Standards • XML • SOAP • WSDL (Web Services Description Language, cf. XDR) • UDDI (Universal Description, Discovery, and Integration) • ebXML (e-business XML)

  19. XML • XML, Extensible Markup Language, is offered by the Worldwide Web Consortium (W3C) • Structured as a self-describing neutral data format based on Unicode that allows self-describing data to be universally parsed • Today, XML is the lingua Franca of electronic data transmission • XML document are tagged structures of name-value paired data

  20. SOAP • SOAP is a standard for a lightweight XML-based messaging protocol • SOAP is the messaging protocol for transport of structured data on top of HTTP, etc. • SOAP is a communication protocol standard similar to other binary protocols like IIOP (CORBA) or JRMP (RMI) or XDR (RPC), but uses a text-based (UNICODE) data representation and definition that is XML-based • SOAP defines a lightweight wire protocol that embeds an encoding format for the representation of data types supporting multiple target languages

  21. WSDL • Web Services Definition Language (WSDL) is an XML format for describing available network services and interfaces • WSDL is used as the metadata language for defining web services • WSDL describes the web services functionalities offered by service providers as well as location services

  22. UDDI • Universal Description, Discovery, and Integration defines standard interfaces in XML for registries serving as location services for web services • UDDI exposes a universal distributed federated database for the naming and location of web-based services

  23. ebXML • Same metaphor but different services: • ebXML registry and repository is used instead of UDDI • ebXML Messaging is used instead of SOAP • ebXML CPP/CPA are used instead of WSDL

  24. Two Communication Models • Synchronous RPC-based Communication Model (SOAP 1.1) • Typical synchronous client-server model which allows a client to make a service request on a listening service embedded within a web server • Follows a Request-Response RPC interaction model • Asynchronous Messaging-based Communication Model • Defines a loosely coupled asynchronous document-driven communication where a client can register with a service provider that acts as a distributed message queue (supported in SOAP 1.2 and ebXML Messaging) • Follows a pub/sub messaging model

  25. SOAP History • SOAP was originally developed by DevelopMentor, Inc. as a platform-independent text transport protocol for accessing services and objects between applications using HTTP-based communication • In 1999, the SOAP 1.0 specification was made public and was supported by vendors including RogueWave, IONA, ObjectSpace, Digital Creations, UserLand (XML-RPC), Microsoft, and DevelopMentor itself • With SOAP 1.1, additional contributions were made by IBM Corporation supporting both RPC and Messaging protocols • SOAP 1.2 is now part of the W3C XML Protocol led by Sun, IBM, HP, BEA, Microsoft, and Oracle, and on 5/7/2003 was promoted to a Proposed Recommendation

  26. Not Supported By SOAP Itself • Garbage Collection • Overloading operations in WSDL • Object by reference • Object activation • Message batching

  27. Anatomy of a SOAP Message • The structural format of a SOAP message contains the following elements: • Envelope • Header (optional) • Body • Attachments (optional)

  28. Example SOAP Message • Hitting a web service attaching ?wsdl to the URL will deliver the WSDL service description for the service http://localhost/IISParamService/IISParamService.asmx?WSDL • Hitting the web service’s asmx file itself will present the default information page for the web service • addEm Example • Example: E:\seminars\src\remoting\params\WebClient

  29. It’s Your Fault • SOAP errors (faults) are wrapped as Exceptions and passed back to the client caller • SOAP faults may either be SoapException objects or plain Exception objects: • throw new Exception(“problem”); • throw new SoapException(“problem”, code, “actor”, detail); • The code is a defined faultcode meaningful to the particular system • The detail is an XmlDocument to provide further information

  30. Microsoft WebMethods public class IISParamService : System.Web.Services.WebService { public IISParamService() { //call is required by the ASP.NET Web Services Designer InitializeComponent(); } [WebMethod(BufferResponse=true, EnableSession=true)] public int addEm(int x) { return x + 1; } }

  31. WebMethod Attributes

  32. Session Management • ASP.NET web services allow the use of Application and Session state objects provided by IIS • A web service will have access to these objects when derived from the System.Web.Services.WebService class • Having access to the Application object allows us to set a custom timeout property in minutes, as in: Application[“appCustomTimeOut”]=15; • Setting the EnableSession method attribute to true enables access to the session state, as in: Session[“mySessionValue”]=“some value”; Session[“intValue”] = 10; int x = (int) Session[“intValue”];

  33. WebConfig File • The Web.Config file contains information related to web settings • Settings include: • default compilation language and debugging support • authentication mode (Windows, Forms) • logging (tracing) support and attributes • session state information (cookies, etc.) • globalization support

  34. Distributed Transaction Support • Transaction Attribute Values: • NotSupported: webmethod operates outside of any particular transactional context • Required: webmethod must always run within the context of a transaction • RequiresNew: webmethod must always have its own new transaction context created, current transaction, if any, is suspended • Supported: webmethod runs in a transaction only if one is already present, but doesn’t require a transactional context • Disabled: webmethod has no current need for transactions (default)

  35. .NET Architectureand Framework

  36. Outline • Common Type System • Common Language Specification • Assemblies • CLR: The Common Language Runtime

  37. The Common Type System

  38. Common Type System • The .NET Framework has two kinds of objects: reference types and value types • Value types are copied when they need to be passed (as in a parameter to a method call), and are stored temporarily on the stack • Reference types are not copied but are passed by a handle that refers back to the single original object, and are allocated on the heap

  39. Comparisons • Value objects are byte-compared, that is, when two objects are compared, the objects themselves are compared byte for byte • Reference objects are pointer-compared, that is, when two objects are compared their references are compared byte for byte—do the respective referencespoint tothe same object? • String objects are tricky, however, because when C# strings are compared, they are compared byte for byte, but they are not value types

  40. Example Value Types • Bool • Char (16-bit Unicode value) • Integers, signed and unsigned (8-, 16-, 32-, 64-bit) • Floating point values (32- and 64-bit) • User-defined value types (C# struct, enum) • Value Types derive from System.ValueType • Value Types are sealed, meaning that the are final—they cannot be inherited (we cannot create a type that is a subtype of an int, for instance)

  41. Example Reference Types • Objects • Strings • Unmanaged Reference Type (pointer) • C#: compile with /unsafe • Typed References (varargs) • C#: compile with /unsafe

  42. Objects in Detail • GetType: returns the Type for the objects, providing access to an object’s metadata (by providing access to its class) • ToString: returns a string representation of the object (namespace and class) [can be overriden] • MemberwiseClone: returns a shallow copy of the object (non-static member variables) [connot be overriden]

  43. Objects in Detail • Finalize: the garbage collector invokes this before an object’s memory is reclaimed [This is not a destructor: DO NOT USE except for operating system resources, like files or sockets or db connections] • ReferenceEquals: returns true if two references are identical (i.e., they point to the same object) • Equals: returns true if two objects are equivalent (comprise the same values)

  44. The Common Language Specification

  45. Common Language Specification • The CLR specifies how various types are to be used in a consistent manner compatible with multiple supported languages

  46. .NET Assemblies Features and Deployment

  47. Assemblies • The assembly is the central unit of versioning and deployment in the .NET framework • The assembly is the common denominator for all languages, meaning that a C# assembly becomes a .NET assembly, a VB assembly becomes a .NET assembly, a C++ assembly becomes a .NET assembly, etc. • .NET assemblies are self-describing, meaning that metadata describing the assembly is available for inspection.

  48. Assembly • The assembly is a logical grouping of one or more managed modules • The assembly is the smallest unit of reuse in .NET • The assembly is stored in a binary format file (.exe or .dll) that is a Portable Executable (PE) file • Each assembly has a manifest that is part of the assembly’s metadata, and details the files that make up the assembly

  49. Portable Executable Format • A PE executable has four main parts: • The PE Header • The CLR Header • The Metadata • Definition Tables • Reference Tables • Manifest Tables • The Intermediate Language (IL) code

  50. Private Deployment of Assemblies • .NET has removed the need for elaborate installations including the registry • .NET assemblies can be simply copied over into a single directory, if they are simple • If other assemblies are referenced, a .config file can be added in the main application directory, which is an .xml file which will contain privatePath directives to assemblies in specified subdirectories • Non-Strongly Named Assemblies can only be deployed privately

More Related