NET Remoting and Web Services

. NET Remoting and Web Services

. NET Web Services

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

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

Web Services Introduction • Web services are supported on most distributed object platforms, including J 2 EE, 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 J 2 EE • Web services may be dynamically located and invoked from public registries exposed over UDDI (Universal Description, Discovery, and Integration) interfaces

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

Java Web. Services • 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

Sun JAX-RPC Interfaces javax. xml. rpc Interface or Class Description Service Main client interfaces used for both static and dynamic calls Service. Factory class for creating Service instances Stub Client proxy for invoking remote operations of a web service as defined in the WSDL for that service Call Used to dynamically invoke a web service JAXRPCException Base exception thrown in the case of a web service fault

Steps in Creating a Weblogic Web Service 1. 2. 3. 4. 5. 6. 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 wsdl 2 Service 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

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

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

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

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

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

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 inout parameters: • public String my. Method(javax. xml. rpc. holders. Int. Holder ret. Int);

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

Microsoft Web. Services • . 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. Marshal. By. Ref. Object • A Remote object may be an object that is instantiated in a foreign application domain (App. Domain) and possibly in a separate CLR • Web. Services may be exposed over either HTTP (internet for accessibility) or TCP/IP (intranet for speed)

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

XML • XML, Extensible Markup Language, is offered by the Worldwide Web Consortium (W 3 C) • 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 namevalue paired data

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

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

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 webbased services

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

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 documentdriven communication where a client can register with a service provider that acts as a distributed message queue (supported in SOAP 1. 2 and eb. XML Messaging) – Follows a pub/sub messaging model

SOAP History • SOAP was originally developed by Develop. Mentor, 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 Rogue. Wave, IONA, Object. Space, Digital Creations, User. Land (XML-RPC), Microsoft, and Develop. Mentor 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 W 3 C XML Protocol led by Sun, IBM, HP, BEA, Microsoft, and Oracle, and on 5/7/2003 was promoted to a Proposed Recommendation

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

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

Example SOAP Message • Hitting a web service attaching ? wsdl to the URL will deliver the WSDL service description for the service http: //localhost/IISParam. Service. asmx? WSDL • Hitting the web service’s asmx file itself will present the default information page for the web service • add. Em Example • Example: E: seminarssrcremotingparamsWeb. Client

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

Microsoft Web. Methods public class IISParam. Service : System. Web. Services. Web. Service { public IISParam. Service() { //call is required by the ASP. NET Web Services Designer Initialize. Component(); } [Web. Method(Buffer. Response=true, Enable. Session=true)] public int add. Em(int x) { return x + 1; } }

Web. Method Attributes Attribute Name Significance Buffer. Response=[true|false] Tells ASP. NET to buffer entire response (default=true) before sending it to the client; otherwise, buffers in 16 k packets Cache. Duration=numseconds Enables caching of results for method (default=false) Description=“description” Supplies a description for the web services help page Enable. Session=[true|false] Enables session state for the method validating HTTPContext. Current. Session or the Web. Serbice. Session property Message. Name=“alias” Allows you to set an alias for overloaded web methods Transaction. Option=option Disabled(default), Not. Supported, Required, Requires. New

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. Web. Service class • Having access to the Application object allows us to set a custom timeout property in minutes, as in: Application[“app. Custom. Time. Out”]=15; • Setting the Enable. Session method attribute to true enables access to the session state, as in: Session[“my. Session. Value”]=“some value”; Session[“int. Value”] = 10; int x = (int) Session[“int. Value”];

Web. Config 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

Distributed Transaction Support • Transaction Attribute Values: – Not. Supported: webmethod operates outside of any particular transactional context – Required: webmethod must always run within the context of a transaction – Requires. New: 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)

. NET Architecture and Framework

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

The Common Type System

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

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 references point to the 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

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. Value. Type 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)

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

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

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] • Reference. Equals: 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)

The Common Language Specification

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

. NET Assemblies Features and Deployment

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.

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

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

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 private. Path directives to assemblies in specified subdirectories • Non-Strongly Named Assemblies can only be deployed privately

Global Deployment of Assemblies • Strongly-Named Assemblies have a publisher’s public/private key pair that uniquely identifies the publisher • Only Strongly-Named Assemblies can be globally deployed (they can also be privately deployed) • A Strong Name includes the assembly filename (no extension), a version number, a culture identity (en-US), and a public key

Assembly Versioning • With private assemblies, versioning is easy, because new versions simply overwrite existing ones (you upgrade “everything”) • For global assemblies, versions are kept under the GAC subdirectory, and an application that was built against version 1. 0. 43. 234 of a particular assembly version will always run against that version (it is retained), even if a new version is installed (it will be installed into a separate GAC subdirectory (code. Base element) • In general, you want to deploy assemblies privately unless the assembly needs to be shared among many applications

Metadata • Metadata is bound in the managed assembly with the actual code, making the two inseparable. • Metadata removes the need for header and library files when compiling since all the information is readily available in the form of metadata in assemblies (i. e. , DLLs) • Metadata allows a class to be serialized and remotely delivered to a foreign CLR

Metadata includes: • name (assembly name, including version, culture, strong name (public key id), GUID, etc. ) • type (information about the types contained in the assembly) • method (information about each method in the assembly) • assembly (information about the number of methods, constants, strings, other assemblies referenced, etc. )

Execution • When a PE managed assembly is created, the compiler/linker puts in some special code in the file’s. TEXT section, which details this file as a PE file • When a managed assembly portable executable is executed at the command prompt, the operating system automatically starts the CLR (via the MSCor. EE. dll library) in which the PE will run • The PE’s Main function is then compiled by the jit compiler and the code pointer JMPs to that execution context

Just In Time Compilation • When a C# source file is first compiled, it is compiled into Intermediate Language (IL) • At runtime, every method that is called (including Main) must be compiled from IL into native machine code (for the particular processor architecture at runtime) • Once a particular method has been compiled within a single run of a CLR, that method remains compiled and is never recompiled during the same execution runtime

Intermediate Language (IL) • All supported languages in. NET are translated into Intermediate Language (IL) • The actual IL generated between different. NET languages are in not identical but semantically equivalent • IL is stack-based, meaning there is no assembly code to “store data onto registers”—all storage commands are to store on the stack • In this sense, IL abstracts away the details of individual CPU architectures

The Common Language Runtime: CLR

Common Language Runtime • The CLR is a managed environment for running programs written in multiple source languages

CLR Features • Automated memory management (GC. Collect() manual call) • Security (role-based and code-based) • Just-in-time compilation of IL • Support for multiple languages • Versioned Deployment (no DLL Hell) • Metadata and Reflection • Multithreaded execution • Networking

Son of COM • The CLR is implemented in. NET as a standard COM server component deployed in a DLL, with a standard COM interface for the CLR and assigned GUIDs for the interface and COM server implementation • Two different versions of the CLR exist, a workstation version tuned for a monoprocessor, and a server version tuned for a multiprocessor environment

App. Domains • When the CLR COM server loads, it creates a default App. Domain • An App. Domain is a logical container for assemblies • App. Domains may be individually created by a managed assembly or an operating system process which loads the proper DLL (hosting) • App. Domains may contain multiple assemblies, and my be loaded and unloaded at will • App. Domains may have separate security policies, which all assemblies in the AD share

App. Domains • Multiple App. Domains can run in the same operating system process • Each App. Domain is given its own separate loader heap for types • An App. Domain may host many separate assemblies, and if (for example) System. Net is needed by several App. Domains, a separate copy of the System. Net assembly is stored, so that App. Domains are not dependent on one another at all (and therefore can be removed on request)

An Example • When the first ASP. NET application is run (ASP. NET is in an ISAPI DLL) in MS IIS, ASP. NET creates a new process to host the CLR COM server • When a client makes a request on a new web application, ASP. NET tells the CLR to create a new App. Domain to host the new web application • Subsequent requests for the same web application are routed to the existing App. Domain for handling

Remoting • Objects in one App. Domain can access objects in another App. Domain by a process called. NET Remoting • We’ll talk about this when we talk about Web Services.

Garbage Management • Generational Management – Generation 0, 1, 2 – As GC takes place, if an object in G 0 is still referenced, it is moved to G 1. If an object in G 1 is still referenced, it is moved to G 2. – The theory is that some objects are “longlived” and most objects are “short-lived” – When the GC needs memory, it starts with G 0, and will probably find enough dereferenced objects in G 0 to not even have to bother examining G 1 or G 2

Memory Management • There are two separate heaps: the small object heap and the large object heap (for objects > 20 K in size) • The small heap has 3 generations and compacts the heap to avoid fragmentation • The large heap also has 3 generations, but does not compact the heap and therefore can become fragmented but the cost for compaction is considered too high

Networking with Sockets • . NET supports multiple levels of socket interfaces, all resolving to Berkeley TCP/IP socket connectivity • A raw Socket is available for lowlevel IP traffic analysis • A Socket abstraction is available to support UDP and TCP transports • Tcp. Listener, Tcp. Client, and Udp. Client abstractions sit on top of Socket and further simplify application programming • Example: sockets/*. cs

Multithreaded Programming in. NET • The CLR and FCL (Framework Class Library) allows multithreaded applications to be written • The Thread concept wraps up a method in a thread and allows for prioritization, joining, and detaching of threads, along with thread pools • Example: threads/*. cs

Common Language Runtime Remoting

CLR Object Remoting • CLR Object Remoting enables: – Distributed references – Activation—remote objects can be activated using the new keyword – Lifetime management—lease based lifetime management – Call context—within the SOAP header, additional contextual information can be passed with every method call

High Level Data Flow

Proxies • Proxies are client-side stand-ins for remote objects. • They are interfaces that have an associated delegatory implementation • The client proxy delegates the call out through any number of client-side formatters

Client Formatters • Formatters translate a method call into a stream of bytes • Currently there are two formatters available: – Binary. Client. Formatter. Sink • used for high-speed transfer of binary data (serialized. NET objects) from one App. Domain to another – Soap. Client. Formatter. Sink • used to transfer data (serialized. NET objects) as a stream of bytes that is SOAP 1. 1 compliant • Formatters implement the Chain of Responsibility pattern and perform specific translations on the stream, such as security and synchronization

Channels • The. NET architecture by default implements two different channels: – http channel • useful for generic use and to cross firewalls – tcp channel • useful for high-speed socket connections on a port direct basis • You can define and add your own channel (i. e. , for network analysis, etc. )

Low-Level Data Flow

Remoting Types • In. NET, a remoted object can be passed by value or by reference – Pass by Reference: derive from Marshal. By. Ref. Object – Pass by Value: mark with the Serializable. Attribute • The objects passed can be arrays, structs, or datasets • Any type supported by SOAP can be transported

Hosting • A remote object may either be hosted by a direct server (which you write) or the object may be hosted by IIS • A direct server host usually processes the configuration file and reads it with Remoting. Configuration. Configure() • Clients can use the configuration file as well and simply create a new local proxy by calling new

Configuration with Direct Servers • . NET is based on the concept of high leverage of metadata • Channel definitions are stored in a configuration file (generally) and stored with the assembly • As metadata, the config file is defined in XML in a certain format • Channels are defined in machine. config under the. NET framework

Server Configuration ur l • In client and server code, the metadata can be read from the config file with code such as (activated for the client): Se rv er <configuration> <system. runtime. remoting> <application name = “Server"> <service> <activated type="com. betzold. My. Param. Object, My. Param. Object"/> </service> <channels> <channel ref = “tcp server” port=“ 9001”/> </channels> pr </application> ot oc </system. runtime. remoting> ol </configuration> Assembly Classname

Client Configuration ur l • In client and server code, the metadata can be read from the config file with code such as (activated for the client): Se rv er <configuration> <system. runtime. remoting> <application name = “Client"> <client url = "tcp: //localhost: 9001/Server"> <activated type="com. betzold. My. Param. Object, My. Param. Object"/> </client> <channels> <channel ref = "tcp client"/> </channels> pr </application> ot oc </system. runtime. remoting> ol </configuration> Assembly Classname

Hosting within IIS • Two things are required for hosting within IIS: – the assembly containing the remoted object – a configuration file • An object can be either client-activated or serveractivated • Usually, direct server hosting is usually serveractivated, whereas IIS hosting is usually clientactivated

Well-known Remote Objects • Well-known remote objects are stateless—every client call is equivalent and creates a new server object • For well-known objects, the client must know the endpoint (location) of the remote object (hence the name well-known) • Well-known objects may be either Single. Call or Singleton – Single. Call mode creates an object instance for the client with every method call – Singleton mode only one object is ever created and all clients share it • The mode may be set within the config file or programmatically

Client-Activated Remote Objects • Client-activated objects use the type of the class to activate the remote object • Client-activated objects are instantiated on the server only when the client creates it, and not with every method call • Client-activated objects may hold state for individual client conversations • Client-activated objects hold state for a given client connection for as long as the client holds a reference to the proxy