Middleware Technologies

Middleware Technologies
Robert Orfali

MIDDLE WARE TECHNOLOGIES
B.TECH III YR II SEMESTER UNIT 1 PPT SLIDES TEXT BOOKS: 1.Client/Server programming with Java and CORBA Robert Orfali and Dan Harkey, John Wiley & Sons,SPD 2nd Edition 2. Java programming with CORBA 3rd Edition, G.Brose, A Vogel and K.Duddy, Wiley-dreamtech, India John wiley and sons

INDEX UNIT 1 PPT SLIDES S.NO. TOPIC LECTURE NO. PPTSLIDES
1. Introduction to client server computing L L1. 1 TO L1.4 2. Evolution of corporate computing models L L2. 1 TO L2.5 from centralized to distributed computing 3. client server models L L3. 1 TO L3.4 L L4. 1 TO L4.4 Benefits / pitfalls client server computing L L5. 1 TO L5.5 5.. REVISION L6

UNIT1 SYLLABUS Introduction to client server computing: Evolution of corporate computing models from centralized to distributed computing , client server models. Benefits for client server computing, pitfalls of client server programming. lecture 1 slide 2

What is client/server Clients and servers are separate logical
Entitles that work together over a network To accomplish a task lecture 1 slide 1

Client/server characteristics
Service Shared resources Asymmetrical protocols Transparency of location Mix and match Message based exchanges Encapsulation of services Scalability integrity lecture 1 slide 2

Types of client/server architectures
File servers Database servers Transaction servers Groupware servers Object application servers Web application servers lecture 1 slide 3

Monolithic computing Early computing was performed on a single processor Makes use of a single cpu to execute one or more programs for each application Ex: A uni-processor lecture 1 slide 4

Distributed system A distributed system is a collection of independent computers ,interconnected via a n/w. Ex: WWW, ,ftp lecture 2 slide 1

Historical trends Mainframe of 60’s Minicomputer Workstation Pc
Community culture web lecture 2 slide 2

Distributed computer advantages
The affordability of computers and availability of network access Resource sharing Scalability Fault tolerance lecture 2 slide 3

Distributed computer disadvantages
Multiple prints of failure Security concerns lecture 2 slide 4

Specific types of servers
App-servers File servers Mail servers Terminal servers lecture 2 slide 5

Servers can be Stateless servers: do not keep any information b/w requests Ex: http Stateful servers : can remember information Ex: apache tomcat lecture 2 slide 5

Types of clients Fat client Thin clients Hybrid clients
lecture 3 slide 1

Skills required by client/server applications development
Transaction processing Database design Communications experience Gui design Internet server Knowledge of distributed objects and component instructors lecture 3 slide 2

ERP ERP vendors now offer client/server solutions for
Consumer packaged goods Automotive Sales force automotive Online catalogs Retail Oil and gas Supply chain management Banking E-commerce lecture 3 slide 3

Comparison of 2-tier with 3-tier
Security :low Performance :poor Scale :poor Application reuse :poor Ease of development :high Server to server infrastructure :no Legacy application :no Internet support :poor System administrations :complex lecture 3 slide 4

Comparison of 2-tier with 3-tier
Security :high Performance :high Scale :good Application reuse :good Ease of development :low Server to server infrastructure :yes Legacy application :yes Internet support :good System administrations :less complex lecture 4 slide 1

Benefits of client/server programming
You can develop big applications in small steps Applications can reuse components. Clients can access data and functions easily and safely Custom applications can incorporate off-the-shelf components Component environments don’t get older – they only get better lecture 4 slide 2

Vendor independence as compared to the traditional mainframe computing. This includes application development methodologies, programming paradigms, products and architectures Organization have changed from steep hierarchies to flattened hierarchies. Decisions making are carried out by many lower ranked managers across the organization rather than performed only by CEOs in the past. lecture 4 slide 3

Network management is replacing vertical management Faster response and flexibility to changing environment of business world outside The customer has a single point of contact for all business with the organization The time required to complete the work will be minimized lecture 4 slide 4

Better sharing of critical database resources and other application software's among clients through the network. Companies can cut costs on maintenance in employing Client- Server Computing since servers are usually cheaper than mainframe (1/10 of mainframe) and the performance of servers and mainframe are nearly identical. Networked webs of small, powerful machines. If one machine goes down, the organization can still function properly. lecture 5 slide 1

Systems grow easily. It is easy to updated and modernize system, both hardware and software as the companies evolved and has new requirements. Individual client operating environments. You can mix and match computer platforms to suit the needs of individual departments and users. lecture 5 slide 2

Pitfalls of client/server computing
Dependability - when the server goes down, operations cease Lack of mature tools - it is a relatively new technology and needed tools are lacking e.g.. Automated client software distribution Lack of scalability - network operating systems (e.g.. Novell Netware, Windows NT Server) are not very scalable. Higher than anticipated costs Can cause network congestion What some call advantages, others call disadvantages lecture 5 slide 3

Database servers lecture 5 slide 4

File servers lecture 5 slide 5

Unit 2 PPT slides MWT

1. Review of Java concepts - RMI L L1. 1 TO L1.4 2. Review of Java concept RMI API L L2. 1 TO L2.4 3. Review of Java concept JDBC L L3. 1 TO L3.4 4. Client/Server CORBA-style L L4. 1 TO L4.4 5.The object web: L L5. 1 TO L5.5 6. CORBA With Java L L6.1 TO L6.5 7.Benefits of CORBA orb L L7.1 TO L7.5

UNIT2 syllabus Review of JAVA concepts like RMI,
RMI API,JDBC,client/server CORBA-style,the object web,CORBA with java

RMI RMI is the technology is used to invoke remote objects from client
The java RMI is an object-oriented mechanism from sun Microsystems for building distributed client/server applications. Java RMI is an RPC implementation in java lecture1 slide 1

Distributed object systems
Java RMI CORBA DCOM SOAP lecture1 slide 2

Review of Java concepts - RMI
The message-passing paradigm is a natural model for distributed computing – it mimics inter-human communications. It is an appropriate paradigm for network services, where processes interact with each other through the exchange of messages. lecture1 slide 3

But the abstraction (APIs such as Java unicast and multicast socket APIs provide it) provided by this paradigm may not meet the needs of some complex n/w apps for the following reasons: lecture1 slide 4

Basic message passing requires that the participating processes be tightly coupled i.e., throughout their interaction, the processes must be in direct communication with each other. lecture 2 slide 1

The message-passing-paradigm is data-oriented. Each message contains data marshaled in a mutually agreed upon format, and each message is interpreted as a request or response according to the protocol. The receiving of each message triggers an action in the receiving process. lecture 2 slide 2

Message-passing paradigm
The message-passing paradigm is inadequate for complex apps involving a large mix of requests and responses lecture 2 slide 3

Distributed Object paradigm
The dist. Object paradigm provides abstractions beyond those of the message-passing model. It is based on objects that exist in a dist. System. In a OOP language such as Java, objects are used to represent an entity that is significant to an app. Each object encapsulates – The state or data of the entity – In Java, instance variables of each object; The operations of the entity – through which the state of the entity can be accessed or updated – In Java, these are the methods. lecture 2 slide 4

Illustration A process running in Host A makes a method call to a dist. Object residing on host B; passing with the call, the data for the arguments, if any. The method call invokes an action performed by the method on Host B, and a return value, if any is passed from Host B to host A. A process that makes use of a dist. object is said to be a client process of that object and the methods of the object are called remote methods to the client process. The paradigm is known to be action-oriented. lecture 3 slide 1

An archetypal Distributed object architecture
The Object client looks up the registry for a reference to the object. The reference is used by the object client to make calls to the methods of the remote object or remote methods. The call is handled by a S/W component, called a client proxy. The Run-time support is responsible for the IPC (marshaling of argument data). lecture 3 slide 2

An archetypal Distributed object architecture
The Run-time support handles the receiving of messages and the unmarshalling of data and forwards the call to a S/W component called the server proxy. The Server Proxy invokes the method call locally, passing in the unmarshalled data for the arguments. The outcome of the execution of the method, including the marshaled data for the return value is forwarded by the server proxy to the client proxy; via the run-time support and n/w support for both sides. lecture 3 slide 3

Distributed Object Systems:
Most popular toolkits: Java RMI CORBA DCOM and Toolkits and APIs that support the Simple Object Access Protocol (SOAP), which is a web based protocol. lecture 3 slide 4

Steps in a Remote Procedure Call
Proc1 on Host A makes a call to Proc2 on Host B. The Run-time support maps the call to a call to the proxy on Host A. The proxy marshals the data and makes an IPC call to a proxy on Host B. The proxy on Host B unmarshals the data received and issues a call to Proc2. The code in Proc2 is executed and returns to the proxy on Host B. The proxy marshals the return value and makes an IPC call to the proxy on Host A. The proxy receives the return value, unmarshals the data, and forwards the return value to Proc1, which resumes its execution flow. lecture 4 slide 1

note Since its introduction in 1980s, RPC has been widely in use in n/w apps. Two prevalent APIs – The open N/W Computing RPC (Sun Micro – early 80s) and Open Group Distributed Computing Environment (DCE) RPC. Both provide a tool rice, for transforming remote procedure calls to local procedure calls to the sub. RPC APIs employ syntax for procedural or function calls and are suitable for procedural languages such as C. For an object oriented language like Java, RPC is not suitable – Java provides the RMI API; which is object-oriented and has a syntax that is more accessible than RPC. lecture 4 slide 2

RMI RMI is an object-oriented implementation of the RPC model.
It is an API for Java programs only. Using RMI, an object server exports a remote object and registers it with a directory service. The object provides remote methods, which can be invoked in client program. Syntactically, a remote object is declared with a remote interface, an extension of the Java interface. The remote interface is implemented by the object server. An object client accesses the object by invoking its methods; using syntax similar to local method invocations. lecture 4 slide 3

The API for the Java RMI There are three areas to be covered.
The remote interface; The server-side S/w; The client-side S/w The Remote Interface – is the starting point of creating a distributed object. lecture 4 slide 4

Review of JDBC SQL-Level 100% Pure Java Keep it simple
High-performance Leverage existing database technology why reinvent the wheel? Use strong, static typing wherever possible Use multiple methods to express multiple functionality lecture 5 slide 1

JDBC Drivers Type I: “Bridge” Type II: “Native” Type III: “Middleware”
Type IV: “Pure” lecture 5 slide 2

Type I Drivers Use bridging technology
Requires installation/configuration on client machines Not good for Web e.g. ODBC Bridge lecture 5 slide 3

Type II Drivers Native API drivers
Requires installation/configuration on client machines Used to leverage existing CLI libraries Usually not thread-safe Mostly obsolete now e.g. Intersolv Oracle Driver, Web Logic drivers lecture 5 slide 4

Type III Drivers Calls middleware server, usually on database host
Very flexible -- allows access to multiple databases using one driver Only need to download one driver But it’s another server application to install and maintain e.g. Symantec DBAnywhere lecture 5 slide 5

Type IV Drivers 100% Pure Java -- the Holy Grail
Use Java networking libraries to talk directly to database engines Only disadvantage: need to download a new driver for each database engine e.g. Oracle, mSQL lecture 6 slide 1

Client/Server CORBA style
The Common Object Request Broker Architecture (CORBA) is the most ambitious middleware project ever undertaken by our industry. It is the product of a consortium – called the Object Management Group (OMG) that includes over 800 companies. Microsoft has its own competing object broker called the Distributed Component Object Model (DCOM). CORBA was designed to allow intelligent components to discover each other and interoperate an object bus lecture 6 slide 2

Client/Server CORBA style
Services provided – creating and deleting objects, accessing them by name, storing them to persistent stores, externalizing their states, and defining ad hoc relationships between them. CORBA lets us create an ordinary object and then make it transactional, secure, lockable, and persistent by making the object multiply – inherit from the appropriate services. IDL – Interface Definition Language is used to write the specifications. Components written to IDL should be portable across languages, tools, OSs, and n/ws. lecture 6 slide 3

Distributed CORBA Object:
CORBA objects are blobs of intelligence, that can live anywhere on a network. They are packaged as binary components that remote clients can access via method invocations. Both the language and compiler used to create server objects are totally transparent to clients. Location transparency, OS transparency. The interface serves as a binding contract between clients and servers. lecture 6 slide 4

Benefits of CORBA ORB Static and Dynamic method invocations.
2. High-level language bindings. Self-describing system – run-time metadata. Local/Remote transparency. Built-in security and transactions. Polymorphic messaging. Coexistence with existing systems – separation of an object’s definition from its implementation is perfect for encapsulating existing applications. lecture 6 slide 5

Benefits of CORBA ORB Static and Dynamic method invocations:
A CORBA ORB lets you either statically define your method invocations at compile time, or it lets you dynamically discover them at run time. So you either get strong type checking at compile time or maximum flexibility associated with late (runtime) binding. Most other forms of middleware only support static bindings. lecture 7 slide 1

Benefits of CORBA ORB High-level language bindings:
A CORBA ORB lets you invoke methods on server objects using your high-language of choice. It doesn’t matter what language server objects are written in. CORBA separates interface from implementation and provides language-neutral data types that make it possible to call objects across language and OS boundaries. In contrast, other types of middleware typically provide low-level, language-specific, API libraries. And they don’t separate implementation from specification – the API is tightly bound to the implementation, which makes it very sensitive to changes. lecture 7 slide 2

Benefits of CORBA ORB Local/Remote Transparency: An ORB can run in stand-alone mode on a laptop, or it can be interconnected to every other ORB in the Universe using CORBA 2.0’s Internet Inter-ORB Protocol (IIOP) services. An ORB can broker inter-object calls within a single process, multiple processes running across networks and OSs, which is completely transparent to your objects. Note: CORBA can broker among fine-grained objects – like C++ classes – as well as more coarse-grained objects. lecture 7 slide 3

Benefits of CORBA ORB Self-describing system:
CORBA provides run-time meta data for describing every server interface known to the system. Every CORBA ORB must support an Interface Repository that contains the real-time information describing the functions a server provides and their parameters. Metadata is useful for clients to discover how to invoke services at run-time; and tools to generate code “on-the-fly”. The meta data is generated automatically either by an IDL-language pre-compiler or by compilers that know how to generate IDL directly from an OO language. ex: Visigenic/Netscape’s Caffeine generates lecture 7 slide 4

Benefits of CORBA ORB Built-in security and transactions:
The ORB includes context information in its messages to handle security and transactions across machine and ORB boundaries. Polymorphic messaging: An ORB invokes a function on a target object – that is, the same function call will have different effects, depending on the object that receives it. ex: configure-yourself method invocation behaves differently when applied to a database object versus a printer object. Coexistence with existing systems: CORBA’s separation of an object’s definition from its implementation is perfect for encapsulating existing applications. Using CORBA IDL, you can make your existing code look like an object on the ORB, even if it is implemented in stored procedures, CICS, IMS, or COBOL. This makes CORBA an evolutionary solution. You can write your new apps as pure objects and encapsulate existing apps with IDL wrappers. lecture 7 slide 5

INTRODUCING C# AND .NET L L1. 1 TO L1.4 L L2.1 To L2.4 2. UNDERSTANDIG . NET L L3. 1 TO L3.4 L L4. 1 TO L4.4 3. OOP WITH C# L L5. 1 TO L5.4 L L6. 1 TO L6.6 4. CALL BACK INTERFACES L L7. 1 TO L7.6 5. DELEGATES, L L8. 1 TO L8.6 6.EVENTS L L9. 1 TO L9.6 7. REVISION L L10. 1 TO L10.6

UNIT3 SYLLABUS Introduction C# and the NET Platform: Understanding. Net Assemblies; Object-Oriented Programming with C#; Callback Interfaces, Delegated, and Events Lecture 1 slide 2

Introducing c# and the .net platform
C/Win 32 API Programmer: C is a very terse language – manual memory management, ugly pointer arithmetic and ugly syntactical constructs; C is a structured language and lacks the benefits of O-O approach. Combined with the thousands of global functions and data types defined by the raw Win 32 API to an already formidable language, many buggy apps. float around today. Lecture 1 slide 1

C++ / MFC Programmer: C++ is an O-O language built in top of C and at the mercy of the painful aspects – manual memory management, ugly operator arithmetic and ugly syntactical constructs. Microsoft Foundation Classes (MFC) wraps a “sane subset” of the raw Win32 API behind a no. of classes, magic macros and numerous code wizards (App Wizard, Class Wizard etc). C++ Programming remains a difficult and error-prone experience. Lecture 1 slide 2

VB 6.0 Programmer: Ability to build complex user interfaces, code libraries (ex. COM servers) and data access logic with minimum fuss and bother. Also hides the complexities of the raw Win32 API from view, using a no. of integrated code wizards, intrinsic data types, classes and VB-centric functions. Downfall of VB – not a fully O-O language; but rather “Object-aware”. No “is-a” relationship between types (i.e. no inheritance ); no support for parameterized class construction; no support for multi-threaded apps. Lecture 1 slide 3

Java/J2EE Programmer: Completely O-O; Syntactic roots in C++; large no. of predefined “Packages” containing various class and interface definitions. “100% pure Java” apps can be built complete with database connectivity, messaging support, Web-enabled front ends, and a rich user interface. Potential problem – little hope of language independence – Java used front-to-back during the development cycle. Also not appropriate for graphical or numerically intensive apps. (ex. 3D-Video game). Lecture 1 slide 4

COM Programmer: Microsoft’s Component Object Model (COM) – architecture that enables reuse of binary code. COM server – language-independent. C++ Programs can build COM classes that can be used by VB; Delphi programmers can use COM classes built using C, etc. However, there is no support for inheritance. Another benefit of COM is location transparency . Using constructs such as app identifiers (APP IDs) stubs, proxies and the COM runtime environment, programmers can avoid the need to work with raw sockets, RPC calls, and other low-level details. Lecture 1 slide 5

COM Programmer: COM is a dominant object model, but is extremely complex under the hood. Active Template Library (ATL) eases the complexity somewhat. Fragile registration entries, numerous deployment related issues have to be contended with. Lecture 2lide 1

Windows DNA Programmer: Building a complete web app using classic Windows DNA (Distributed internet Architecture) is also very complex. Complexity is due to the fact that DNA requires the use of numerous technologies and languages such as ASP, HTML, XML, JavaScript, VBScript, COM+, ADO etc. Syntactically different, for ex., JavaScript has a syntax much like C, VBScript is a subset of VB. Each language and/or technology has its own type system – for ex., “int” in JavaScript is not the same as “int” in C, which is different from an “Integer” in VB. Lecture 2 slide 2

The .NET Solution – Core features: Full interoperability with existing Win32 Code – Existing COM binaries can inter-op with newer .NET binaries and vice versa. PInvoke (PlatfromInvocation) allows you to invoke raw C-based functions (such as the Win32 API) from managed code. Complete and total language integration – Unlike classic COM, .NET supports cross-language inheritance, cross-language exception handling, and cross-language debugging. A common runtime engine shared by all .NET-aware languages – A well-defined set of types that each .NET-aware language “understands”. A base class library – that provides shelter from the complexities of raw API calls, and offers a consistent object model used by all .NET-aware languages. Lecture 2 slide 3

No more COM plumbing – IClassFactory, Iunknown, Idispatch, IDLCode, and the evil VARIANT – Compliant data types (BSTR, SAFEARRAY etc.) have been dropped in .NET binary. A truly simplified deployment model – No need to register a binary unit into the System registry. Also the .NET runtime allows multiple versions of the same *.dll to exist in harmony on a single machine (“side-by-side execution”). Lecture 2 slide 4

The building blocks of the .NET platform: CLR - .NET is a new runtime environment and a common base class library. The runtime layer is referred to as Common Language Runtime (CLR). CLR’s primary role is to locate, load and manage .NET types on your behalf. It also takes care of a number of low-level details such as automatic memory management, language integration and ensuring type safety. Lecture 2 slide 5

CTS (Common Type System) – fully describes all possible data types and programming constructs supported by the runtime, specifies how these entities can interact with each other and details how they are represented in the .NET metadata format. CLS (Common Language Specification) – is a set of rules that define a subset of a common types and programming constructs that all .NET programming languages can agree on. Lecture 3 slide 1

Understanding .NET Assemblies
A .NET assembly consists of five major elements: 1. A standard Windows file header 2. A CLR header that marks the file as a managed module 3. CIL Code 4. Type metadata 5. The assembly manifest Lecture 3 slide 2

Core Benefits 1. Assemblies promote code reuse. 2. Assemblies establish a type boundary. 3. Assemblies are versionable and self-describing entities. 4. Assemblies define a security context. 5. Assemblies enable side-by-side execution. Lecture 3 slide 3

Single File Assemblies – contain all the necessary CIL, metadata and associated manifest in an autonomous, single, well-defined package. Multi-file assemblies – are composed of numerous .NET binaries, each of which is termed a module. When building a multi-file assembly, one of these modules (termed the primary module) must contain the assembly manifest and possibly CIL instructions and metadata for various types. The other related modules contain a module level manifest, CIL and type metadata. The primary module documents the set of required secondary modules within the assembly manifest. Lecture 3 slide 4

Note: Partitioning an assembly into discrete modules provides a more flexible deployment option. Ex: if a user is referencing a remote assembly that needs to be downloaded into his machine, the runtime will only download the required modules. Thus, an assembly is a logical grouping of one or more related modules that are intended to be deployed and versioned as a single unit. Lecture 4 slide 1

Role of CIL: CIL is a language that sits above any particular platform-specific instruction set. Regardless of which .NET – aware language you choose, (C#, VB .NET, Eiffel .NET, and so forth); the associated compiler emits CIL instructions. Lecture 4 slide 2

Benefits of CIL: Language integration – Each .NET-aware language produces the same underlying CIL. Therefore, all languages are able to interact within a well-defined binary arena. Platform agnostic – the .NET runtime is poised to become a platform-independent architecture, providing the same benefits as Java. Lecture 4 slide 3

The role of .NET Type Metadata: Describes each and every type – class, structure, enumeration, and so forth defined in the binary, as well as the members of each type – properties, methods, events, and so on. The role of the Assembly Manifest: A valid .NET assembly contains metadata that describes the code library itself (technically termed a manifest). Like type metadata, it is always the job of the compiler to generate assembly’s manifest. Lecture 4 slide 4

Compiling CIL to Platform-specific Instructions: Since the assemblies contain CIL and metadata, the CIL must be compiled on the fly before use. The entity that does this is JIT (Just-In-Time compiler) or popularly known as “Jitter”. The .NET runtime environment leverages a JIT compiler for each CPU targeting the CLR, each of which is optimized for the platform it is targeting. Note: JIT – applications deployed on Hand-held devices – have low-memory and automatically adjust to that environment. JIT – Back end Server – have high-memory and again automatically adjust to that environment. Caching of results – CIL instructions into corresponding machine code. On first invocation, the CIL instructions are compiled into platform-specific instructions of the machine and later reused on subsequent invocations. Lecture 4 slide 5

CTS (Common Type System): In .NET, a type is a generic term used to collectively refer to any entity from the set {class, structure, interface, enumeration, delegate). CTS Class Types: Is the class “sealed” or not? Sealed Classes – cannot function as a base class to other types. Does the class implement any interfaces? Zero or more. Is the class abstract or concrete? Abstract classes cannot be directly created. What is the “visibility” of this class? Visibility attribute. Lecture 5 slide 1

CLS is a set of guidelines that describe in detail, the minimal and complete set of features a given .NET-aware compiler must support to produce code that can be hosted by the CLR, while at the same time be accessed in a uniform manner by all languages that target the .NET platform. CLS can be viewed as a physical subset of the full functionality defined by the CTS. Lecture 5 slide 2

CLR The workflow that takes place between your source code (which is making use of base class library types), a given .NET Compiler, and the .NET execution engine is shown in the following diagram. Lecture 5 slide 3

Object-Oriented Programming with C#
Pillars of OOP: Encapsulation – hide object’s internal implementation. Inheritance – code reuse – “is-a” and “has-a” relationships. Exs: Object  Shape  Hexagon(“is a”) and Car  radio (“has a”) Polymorphism – treat related objects in a similar way. Classical – Object  Shape  Hexagon  Circle Ad hoc – late binding is used; no common base class. Encapsulation in C#: “public” fields may get corrupted; so “private” data fields have to be used, which can be manipulated as follows: Define a pair of accessor and mutator fields. Define a named property. Special key word “read-only” delivers an additional form of data protection. Lecture 5 slide 4

Ex: for accessors and mutators: public class Employee { private string fullName; … //accessor pubic string getfullName(){return fullName;} //mutator public void setfullName(string n) { fullName=n;} Class Property: .NET Classes (as well as structures and interfaces) can also define properties. Ex: public static int Main(string[] args) { Employee p = new Employee(); p.EmpID = 81; Console.WriteLine(“Person ID is: {0}”, p.EmpID); return 0; } Lecture 6 slide 1

//custom property for the EmpID data point. public class Employee { … private int EmpID; public int EmpID { get { return EmpID;} set { EmpID = value;} } Note: Properties make your types easier to manipulate. Ex: accessors & mutators: Employee joe = new Employee(); joe.setAge(joe.getAge() + 1); properties joe.Age++; A C# property maps to a get_/set_ pair. So care must be taken to see that get_/set_ property methods are not redefined. Lecture 6 slide 2

Read-only and Write-only properties: Build a property without a corresponding set block for read-only and without a get block for write-only properties. Static properties: are supported in C#. Properties are bound to a given class; but not an instance (object) of that class. Static constructors are also supported in C# - useful for assigning initial values to static data. Read-only fields, static Read-only fields – are also supported. Inheritance: Employee SalesPerson  Manager public class Manager : Employee { … } public class SalesPerson : Employee Note: A child class cannot directly access private members of its parent class. Lecture 6 slide 3

Protected: data and methods can be accessed directly by any descendant. Sealed classes: prevent inheritance. Ex: public sealed class PTSalesPerson : SalesPerson { … } Useful for creating stand-alone utility classes like System.String. Containment/Delegation (“has-a” relationship): public class Radio public class Car { … private Radio theMusicBox; } Nested classes – are permitted. Lecture 6 slide 4

Polymorphism: Base class – “virtual” method. Sub class – “override” base class’s virtual method. Abstract classes: Ex: abstract public class Employee { … } Abstract methods: can be used, when a concrete definition is not supplied. Versioning class members: method hiding – opposite of method overriding. Key word: new Ex: public class oval : Circle { public oval {base.petName = “Joe”; } public new void Draw() Casting: between “types” permitted. “Type-of” – key word “is” Lecture 7 slide 1

Callback Interfaces, Delegates and Events
Objects can talk back to the entity that created them. “Two-way” conversation is common for objects in a system through the use of events, callback interfaces and other programming constructs. C# Key word “delegate”. Interfaces – used to define common behaviors. Callback interfaces: ex: //The callback interface public interface IEngineEvents { void AboutToBlow(string msg); void Exploded(string msg); } Lecture 7 slide 2

Event interfaces are not implemented directly by the client executable, but rather by a helper sink object; upon which the sender of the events (the Car type in our ex.) will make calls. Assume the client-side sink class is called CarEventSink. When the Car type sends the event notification to the sink, it will print the messages to the console. //CarEventSink public class CarEventSink : IEngineEvents { private string name;//Diagnostic member to identify sink. public CarEventSink() { } public CarEventSink(string sinkName) { name = sinkName; } public void AboutToBlow(string msg) {Console.WriteLine(“{0}reporting:{1}”,name,msg); } public void Exploded(string msg) } Lecture 7 slide 3

Now, a reference to this sink has to be passed to the Car type. The Car holds onto the reference and makes calls back on the sink, when appropriate. To obtain a reference to the sink, Advise() method can be used – similar to COM paradigm. Similarly, to detach from the event source, another custom method Unadvise() can be used – again similar to COM paradigm. Lecture 7 slide 4

To register multiple event sinks, let us assume that the Car maintains an ArrayList to represent each outstanding connection. //This car does not make any use of the //C# delegate or event key word, but can //still send events to the caller. public class Car { //The set of connected sinks ArrayList itfConnections = new ArrayList(); //Attach or disconnect from the source of events. public void Advise(IEngineEvents itfClientImpl) { itfConnections.Add(itfClientImpl); } public void Unadvise(IEngineEvents itfClientImpl) { itfConnections.Remove(itfClientImpl); } } Lecture 8 slide 1

Car.SpeedUp() method is used to send the events. The method iterates over the list of connections and fires the correct notification when appropriate. //Interface-based event protocol! Class Car {… public void SpeedUp(int delta) { //If the car is dead, send exploded event to each sink. if(carIsDead) { foreach(IEngineEvents e in itfConnections) e.Exploded(“Sorry, this car is dead …”); } else {currSpeed += delta; if(10 == maxSpeed – currSpeed) { foreach(IEngineEvents e in itfConnections) e.AboutToBlow(“Careful! Going to blow!”); if(currSpeed >= maxSpeed) CarIsDead = true; else Console.WriteLine(“\tcurrSpeed={0}”,currSpeed); }} Lecture 8 slide 2

Client-side code: //Make a car and listen to the events. public class CarApp { public static int Main(string[] args) { Car c1 = new Car(“SlugBug”, 100, 10); //Make sink object CarEventSink sink = new CarEventSink(); //Pass the Car a ref. to the sink. c1.Advise(sink); //Speed up (this will generate the events) for(int i = 0; i < 6; i++) c1.Speedup(20); //Detach from events. c1.Unadvise(sink); } return 0; Lecture 8 slide 3

Note: Unadvise() method is very helpful in allowing the caller to selectively detach from events at will. Ex: The following app registers two sinks, dynamically removes a particular sink during the flow of execution, and continues to process the program. public static int Main(string[] args) {Car c1 = new Car(“SlugBug”, 100, 10); //Make sink objects Console.WriteLine(“***Creating sinks***”); CarEventSink sink = new CarEventSink(“First sink”); CarEventSink myOtherSink = new CarEventSink(“Other sink”); //Hand sinks to car Console.WriteLine(“Sending 2 sinks into Car”); c1.Advise(sink); c1.Advise(myOtherSink); Lecture 8 slide 4

//Speed up (this will generate the events) Console.WriteLine(“\n***Speeding up***”); for(int i=0; i < 6; i++) c1.SpeedUp(20); //Detach first sink from events Console.WriteLine(“\nRemoving first sink”); c1.Unadvise(sink); //speed up again (only “other sink” will be called.) Console.WriteLine(“\n***Speeding up again***”); for(int I=0; I < 6; I++) //Detach other sink from events. Console.WriteLine(“\n***Removing second sink***”); c1.Unadvise(myOtherSink); return 0; } Lecture 8 slide 5

.NET Delegate Type: Windows API – C-Style function ptrs – callback functions (or callbacks). The approach is not safe, as no. & type of args. infn. is not stored; only address is stored. .NET provides a safer, more Obj. Oriented manner, using delegates. A delegate maintains name, arguments and return value of the method. .NET supports both synchronous, and asynchronous delegates. Defining a delegate in C#: ex: 1. Public delegate void PlayAcidHouse (Person theDJ, int volume); The C# compiler dynamically produces a new sealed class named PlayAcidHouse deriving from System.MultiCastDelegate. Lecture 8 slide 6

The dynamically generated sealed class: Sealed class PlayAcidHouse : System.MultiCastDelegate {public PlayAcidHouse(object target, uint functionAddress); public void Invoke(Person theDJ, int volume); public IAsyncResult BeginInvoke(Person theDJ, int volume, AsyncCallback cb, object state); public void EndInvoke(IAsyncResult result); } Invoke() – core method, may be called to inform the delegate it is time to call the method it is currently pointing to. It is a synchronous method. BeginInvoke() & EndInvoke() – provide ability to call the current method asynchronously. Ex 2: public delegate string TakeSomeBools(bool a, bool b, bool c); Lecture 9 slide 1

Ex 3: public delegate string TakeSomeBoolsByRefAndAsOut (out bool a, out bool b, ref bool c); In this case the EndInvoke() method will have these three (out & ref) parameters also in its args list. System MultiCastDelegate: derives from System.Delegate and implements two standard interfaces. public abstract class MultiCastDelegate : Delegate, ICloneable, ISerializable {public MethodInfo Method {get;} … } Lecture 9 slide 2

A simple delegate example: namespace SimpleDelegate {class DelegateApp {//This is the method that will be called by the delegate public static void PlainPrint(string msg) {Console.WriteLine(“Msg is:{0}”, msg);} //Define a delegate type public delegate void AnyMethodTakingAString(string s); public static void Main() {//Make the delegate AnyMethodTakingAString del; del = new AnyMethodTakingAString(PlainPrint); //AnyMethodTakingAString.Invoke() called here! del(“Hello there …”); //Dump info about the delegate Console.WriteLine(“I just called:{0}”,del.Method); } }} Lecture 9 slide 3

Output: Msg is: Hello there … I just called: void PlainPrint(System.string) Note: The target method can be changed dynamically. Multicasting with .NET delegates is also possible. A more elaborate delegate ex: Two new boolean variables for the Car class – isDirty(due for a wash) and shouldRotate (tire rotation). Additional properties and an updated constructor are included. Lecture 9 slide 4

Callback interfaces, delegates and events
public class Car { … private bool isDirty; private bool shouldRotate; public Car(string name, int max, int curr, bool dirty, bool rotate) isDirty = dirty; shouldRotate = rotate; } public bool Dirty { get{return isDirty;} set (isDirty = value;} public bool Rotate { get{return shouldRotate;} set (shouldRotate = value;} }} Lecture 9 slide 5

//This delegate is actually a class encapsulating a //function pointer to ‘some method’, taking a Car //as a parameter, and returning void. public delegate void CarDelegate(Car c); Note: A more enlightened alternative is to define CarDelegate directly within the Car class (Delegate as nested type) public class Car {//This is represented in CIL as //Car$CarDelegate (i.e. a nested type) … } Lecture 9 slide 6

Using the CarDelegate: New class Garage maintains a collection of Car types contained in an ArrayList (on creation, filled with some initial car types). ProcessCars() method – takes a single arg of type Car.CarDelegate. In the implementation of ProcessCars(), you pass each car in your collection as a parameter to the “function pointed to” by the delegate. Lecture 10 slide 1

//The Garage class has a method that makes use //of the CarDelegate. Using System.Collections; … Public class Garage { //A list of all cars in the Garage. ArrayList theCars = new ArrayList(); //creates the cars in the Garage. public Garage() {theCars.Add(new Car(“Viper”,100,0,true,false)); theCars.Add(new Car(“Fred”,100,0,false,false)); theCars.Add(new Car(“BillyBob”,100,0,false,true)); theCars.Add(new Car(“Bart”,100,0,true,true)); theCars.Add(new Car(“Stan”,100,0,false,true)); } Lecture 10 slide 2

//This method takes a Car.CarDelegate as a parameter. //Therefore, ‘proc’ is nothing more than a function //pointer! public void ProcessCars(Car.CarDelegate proc) { //Diagnostics: Where are we forwarding the call? C.W.(“Calling: {0}”, d.Method.ToString()); //Diagnostics: Are we calling an instance method or a //static method? if(proc.Target!=null) C.W.(“->Target:{0}”,proc.Target.ToString()); else C.W.(“->Target is a static method”); //Real work: Now call the method, passing in each car foreach(Car c in theCars) proc(c);}} Lecture 10 slide 3

When the object user calls ProcessCars(), it will send in the name of the method that should handle this request. Let us assume, these are static members named WashCar() and RotateTires(). Usage: //The garage delegates all work orders to these static functions public class CarApp { //A Target for the delegate. public static void WashCar(Car c) { if(c.Dirty) C.W.(“Cleaning a Car”); else C.W.(“The Car is already clean …”); } public static void RotateTires(Car c) { if(c.Rotate) C.W.(“Tires have been rotated”); else C.W.(“Don’t need to be rotated …”); Lecture 10 slide 4

public int Main(string[] args) { Garage g = new Garage(); //Wash all dirty cars g.ProcessCars(new Car.CarDelegate(WashCar)); //Rotate the tires. g.ProcessCars(new Car.CarDelegate(RotateTires)); return 0; } Lecture 10 slide 5

Asynchronous Delegates: Threading concepts – word doc printing 1000 pages; basic user input requests to be serviced. BeginInvoke() and EndInvoke() methods. Events: event key word. GUI – Button, Text Box etc. Non-GUI – apps also handle events public static event EngineHandler Exploded; public static event EngineHandler AboutToBlow; Where EngineHandler is declared as a delegate. Each event internally represented as the following members – a private class; an add_XXX() method and a remove_XXX() method. Lecture 10 slide 6

S.NO. TOPIC LECTURE NO. PPTSLIDES
INDEX UNIT 4 PPT SLIDES S.NO TOPIC LECTURE NO. PPTSLIDES 1. BUILDING C# APPLICATIONS L L1.1 TO L1.4 2. TYPE REFLECTIONS L L2. 1 TO L2.4 3. LATE BINDING L L3. 1 TO L3.5 4. ATTRIBUTE BASED PROG L L4. 1 TO L4.5 5. OBJECT SERIALIZATION L28 L5. 1 TO L5.5 6. REMOTE LAYER L29 L6. 1 TO L6.4 7. ADO .NET L30 L7. 1 TO L7.4 8. WEB SERVICES L31 L8. 1 TO L8.5

UNIT4 SYLLABUS Building C# applications: Type Reflection, Late Binding, and Attribute-Based programming; object Serialization and the NET Remoting Layer; Data Access with ADO.NET;XML Web Services.

BUILDING C# APPLICATIONS
The necessity of type meta data ability to fully qualify the definition of types Numerous .NET technologies Cross language interoperability .Net type is any member from the set . Net type is the vehicle used to describe internal composition Using ildasm.exe we can view assemblies lecture 1 slide 1

The Role of the Command Line Compiler (csc.exe) The most obvious reason is the simple fact that you might not have a full copy of Visual Studio .NET (but do have the free .NET SDK). Another reason is this very important fact: Design time editors, code Wizards, and configuration dialogs do little more than save you typing time. The more you understand what happens "under the hood" the stronger your programming muscle becomes. As you use VS .NET to build applications, lecture 1 slide 2

To equip your development machine to compile *.cs files from any subdirectory, follow these steps (which assume a Windows XP installation; WinNT/Win2000 steps will slightly differ): Right-click the My Computer icon and select Properties from the pop-up menu. Select the Advanced tab and click the Environment Variables button. Double click the Path variable from the System Variables list box. lecture 1 slide 3

To equip your development machine to compile *.cs files from any subdirectory, follow these steps (which assume a Windows XP installation; WinNT/Win2000 steps will slightly differ): Right-click the My Computer icon and select Properties from the pop-up menu. Select the Advanced tab and click the Environment Variables button. Double click the Path variable from the System Variables list box. lecture 1 slide 4

TYPE REFLECTIONS System reflection name space Assembly Assembly name
contains a number of methods that allow to load Assembly name to discover version iformation Event info Holds information for a given field Member info Abstract base class that defines common behaviours lecture 2 slide 1

TYPE REFLECTIONS Method info Module Parameter info Property info
Contains information for a given method Module Allows you to access given module Parameter info Holds information for a given parameter Property info Holds informtion for a given property lecture 2 slide 2

TYPE REFLECTIONS Type Member Meaning in Life
IsAbstract IsArray IsClass IsCOMObject IsEnum IsInterface IsPrimitive IsNestedPublic IsNestedPrivate IsSealed IsValueType These properties (among others) allow you to discover a number of basic traits about the Type you are referring to (e.g., if it is an abstract method, an array, a nested class, and so forth). lecture 2 slide 3

TYPE REFLECTIONS GetConstructors() GetEvents() GetFields() GetInterfaces() GetMethods() GetMembers() GetNestedTypes() GetProperties() These methods (among others) allow you to obtain an array representing the items (interface, method, property, etc.) you are interested in. Each method returns a related array (e.g., GetFields() returns a FieldInfo array, lecture 2 slide 4

TYPE REFLECTIONS GetMethods()
returns a MethodInfo array, etc.). Be aware that each of these methods has a singular form (e.g.GetMethod() GetProperty()) that allows you to retrieve a specific item by name, rather than an array of all related items. FindMembers() Returns an array of MemberInfo types, based on search criteria. GetType() This static method returns a Type instance given a string name. InvokeMember() This method allows late binding to a given item. lecture 3 slide 1

LATE BINDING A Sampling of Members of the System.Reflection Assembly
This class (in addition to numerous related types) contains a number of methods that allow you to load, investigate, and manipulate an assembly. AssemblyName This class allows you to discover numerous details behind an assembly's identity (version information, culture information, and so forth). EventInfo Holds information for a given event. FieldInfo Holds information for a given field. lecture 3 slide 2

LATE BINDING A Sampling of Members of the System.Reflection
Member Info This is the abstract base class that defines common behaviors for the Event Info, Field Info, Method Info, and Property Info types. Method Info Contains information for a given method. Module Allows you to access a given module within a multifile assembly. Parameter Info Holds information for a given parameter. Property Info Holds information for a given property. lecture 3 slide 3

LATE BINDING CSharpSnapIn.dll: VbNetSnapIn.dll: MyPluggableApp.exe:
A simple snap-in written in C#, which leverages the types of CommonSnappableTypes.dll. VbNetSnapIn.dll: A simple snap-in written in VB .NET, which leverages the types of CommonSnappableTypes.dll. MyPluggableApp.exe: This Windows Forms application will be the entity that may be extended by the functionality of each snap-in. Again, remember! This application will make use of reflection, late binding, and custom attributes to dynamically gain the functionality of assemblies it has no foreknowledge. lecture 3 slide 4

LATE BINDING The Activator Class
The System.Activator class is the key to .NET late binding. Beyond the methods inherited from Object, Activator only defines a small set of members. Activator.CreateInstance() is one core method that creates an instance of a type at runtime. This method has been overloaded numerous times to provide a good deal of flexibility. lecture 3 slide 5

LATE BINDING // Create a type dynamically. public class LateBind {
public static int Main(string[] args) // Assume the CarLibrary is in the app directory. Assembly a = null; try { a = Assembly.Load("CarLibrary"); } catch(FileNotFoundException e) { Console.WriteLine(e.Message);} // Specify the fully qualified name of the Minivan type. Type miniVan = a.GetType("CarLibrary.MiniVan"); // Create the Minivan on the fly. object obj = Activator.CreateInstance(miniVan); } lecture 4 slide 1

ATTRIBUTE PROGRAMMING
IDL is the official metlanguage of the com (Computer ObjectModel). IDL makes use of “attributes”, which are IDL keyword, placed in square load etc. Ex.: [object, unid (4CB8B79A-E991-4AA4….), oleautomation] parameters can be passed with [in],[int], [in,int], and [out, retral] attributes. C# and other.NET-aware languages have inteprated attributes as official aspects of the language. .NET attributes (predefined or custom) are classes, all of which extend System. Attribute lecture 4 slide 2

Predefined .NET Attribute Meaning 1. CLSCompliant Enforces that all types in the assembly conform to the CommonLanguageSpecification (CLS). 2. DllImport Used to make calls to the native OS. 3. StructLayout Used to configure the underlyingrepresentation of a Structure. 4. Dispid Specifies the DISPID for a member in a com dispinterface. 5. Serializable Marks a class or structure as being serializable. 6. Nonserialized Specifies that a given field in a class or structure is not serializable. 7. WebMethod Marks a method as being invokable Via HTTP requests. lecture 4 slide 3

Object Graphs: The chain of related objects serialized to a stream is collectively referred to as an object graph. Object graphs provide a simple way to document how a set of objects refer to each other. To establish the relations among objects in a graph, each object is assigned a unique numeral value, followed by a graph of all related items. lecture 4 slide 4

Ex. : // This class can be saved to disk. [Serializable] – class itself is serializable public class Motorcycle { bool hasRadioSystem; bool hasHeadSet; bool has SissyBar; // but when you do, don’t bother with this field. [NonSerialized] – need not be saved. Float weightofCurrentPassengers; } lecture 4 slide 5

OBJECT SERIALIZATION Serialization: Process of converting the state of an object to a linear sequence of data is termed as Serialization. This data sequence contains all necessary information needed to reinstruct (or deserialize) the state of the object for use later. The .NET serialization services are quite sophisticated: When a given object is serialized to a stream, any associated object references required by the root object are automatically serialized as well. lecture 5 slide 1

OBJECT SERIALIZATION Once a set of objects has been saved to a stream, the data pattern can be relocated as necessary. For ex., if you have serialized an object group into memory location using the system.IO.MemoryStream type. This stream could be forwarded to a remote Computer, the Windows Clipboard, burned to a CD, or simply written to a physical file. lecture 5 slide 2

OBJECT SERIALIZATION Configuring Objects for Serialization:
1. To make an object available to .NET serialization services, decorate each class with the [serializable] attribute. 2. If you have some member data in a given class that should not participate in the serialization scheme, you can mark such fields with the [Non Serialized] attribute – applicable for ex., for constants, transient data etc. lecture 5 slide 3

OBJECT SERIALIZATION Ex. // The Radio class can participate in the .NET serialization [Serializable] public class Radio { // this member will not be persisted. [Non Serialized] private int objectIDNumber = 9; //Other Serialized state data. … public Radio( ) {} public void On (bool state) { if (state = = true) MessagBox.Show(“Music is on …”); else MessageBox.Show (“No tunes…”); } lecture 5 slide 4

OBJECT SERIALIZATION Choosing a serilization formatter
The system run time serialization fromatters namespace contains two additional nested namespaces (* Binary *soap). The binary formatter type serializes your object graph to a stream using a compact binary format. The soap formatter type represents your graph as SOAP (single object Access Protocol) message that is expressed using XML data representation. The system.Runtime.Serilization.Formatters.Binary.Binary Formatter type is define within mscorlit.dll; Ex: //persist object graph using a binary format! lecture 5 slide 5

OBJECT SERIALIZATION Choosing a serilization formatter
Using system.runtime.serizlization.formatters.binary; The systm.runtime. Serilization.Formatters. Soap.Formatter type is defined in a separate assembly. To format your object graph in to a SOAP message, you must set a reference to system.runtime. Serilization.Formatters.Soap.all and make the following C++ using directive. Ex: //persist object graph using a SOAP format! Using system. runtime.serizlization.formatters.Soap; lecture 6 slide 1

REMOTE LAYER .NET Remoting
An application domain is a logical boundary for a .NET assembly which is itself contained within a process type. In the context of distributing computing under .NET, remoting is the act of two pieces of s/w communicating across app.domains. Possible scenarios for the app.domains: Two app. domains in the same process (and thus on the same machine). Two app.domains in separate process on the same machine. Two app.domains in separate process on difference machines. Regardless of the distance between two softwares entities, it is common to refer to each agent using the terms client and server. client is a piece of software that attempts to interact with a remote object. server is the software agent that provides remote access to select objects. lecture 6 slide 2

REMOTE LAYER The .NET Remoting namespaces:
The .NET base class libraries provide numerous namespaces that allow you to build dist.apps. The bulk of the types found with in these namespaces are contained with in mscorlib.dll. The system.Runtime.Remoting .dll assembly does complement and extend the basic type set. lecture 6 slide 4

REMOTE LAYER Remoting – Centric Namespace Meaning
System.Runtime.Remoting Cure n/s, you must use when building any sort of app. Using the .NET Remoting layer System.Runtime.Remoting Activation Small n/s, to fine- tune the process activating a remote object. System.Runtime.Remoting Channels Types to represent channels and channel links. System.Runtime.Remoting Channels.Http Types that use the HTTP protocol to transport messages and objects to and from remote locations. System.Runtime.Remoting Channels tcp Types that use the TCP protocol to transport messages and objects to and from remote locations. lecture 7 slide 1

REMOTE LAYER System.Runtime.Remoting contexts to configure the details of a object’s context. System.Runtime.Remoting. lifetime to manage the lifetime of remoting objects. System.Runtime.Remoting. Messaging to create and transmit message object. System.Runtime.Remoting. Metadata to customize the generation and processing of SOAP formatting. System.Runtime.Remoting. Metadata types that represent the XML scheme def. System.Runtime.Remoting.metadata useful for soapsuds.exe command line tool services. to convert.NET metadata to and from XML schema for the remoting infrastructure. System.Runtime.Remoting.Proxies provide functionality for proxy objects lecture 7 slide 2

REMOTE LAYER The .NET Remoting Framework:
When clients and servers exchange information. across app. Boundaries, the CLR makes use of several low-level primitives to ensure the entities in question are able to communicate with each other as transparently as possible. The .NET Remoting layer revolves around a careful orchestration that takes place between four key players: Proxies, Messages, Channels and Formatters. lecture 7 slide 3

REMOTE LAYER Proxies & Messages:
Like Java RI, CORBA and DCOM, the role of a .NET Proxy is to fool the client into believing it is communicating with a local object in the same app.domain. A proxy has the identical interface (i.e., members, properties, fields etc) as the remote type it represents. The proxy invoked directly by the client is termed the transparent proxy. It is generated by CLR and ensures that the client has provided the current no.of and type of parameters to invoke the remote method. Transparent proxies cannot be modified or extended programmatically. The incoing args. Infn. is packaged up into another CLR generated type termed the message object lecture 7 slide 4

ADO .NET lecture 8 slide 1

ADO .NET Interfaces IDb Connection IDb Transaction IDb Command
IDb Data Parameter IData Parameter IDb Data Adapter I Data Adapter I Data Reader I Data Reused lecture 8 slide 2

ADO .NET ADO .NET Namespaces: System Data System Data. common
System Data. OleDb System Data. Odbc System Data .Oracle client System Data .Sql client System Data .Sql server System Data .Sql types lecture 8 slide 3

ADO .NET Key members of System.Data
Data Column collection, Data Column Constraint collection, constraint Data Row collection, Data row Data Row view, Data View Data set Foreign key constraint, unique constraint Data Relation Collection, Data relation Data Table collection, Data table lecture 8 slide 4

ADO .NET Mapping type enumeration: Enum value Col. is mapped to
Attribute - XML attribute Element - XML element (default) Hidden - internal structure Simple content - text lecture 8 slide 5

Web Service A programmable application logic accessible by all the internet users just-like components represents a new platform on which developers can build the same distributed applications they've always built with interoperability as the highest priority. .NET uses standard internet protocols like HTTP, SOAP and XML whereas other components uses DCOM, RMI or Internet Inter-ORB (IIOP) protocols Widely required for Enterprise Application Integration (EAI) and Business-to-Business Integration (B2Bi) applications. lecture 8 slide 6

Two types of Client/Server invocations L L1.1 TO L1.5 L L2.1 TOL 2.5 2.The static CORBA L L3. 1 TO L2.5 3. CORBA program L L4. 1 TO L3.5 4. ORB lets with Applets L L5. 1 TO L4.5 5. Dynamic CORBA L L6. 1 TO L5.5 6. The portable count L L7. 1 TO L6.5 7. dynamic count L39 L8. 1 TO L7.5 8. multi count L L9.1 TO L9.4

UNIT5 SYLLABUS Core CORBA / Java: Two types of Client/Server invocations-static, dynamic. The static CORBA, first CORBA program, ORB lets with Applets, Dynamic CORBA—The portable count, the dynamic count multi count. Lecture 1 slide 1

What is CORBA 1.CORBA is a specification for the distributed object bus architecture defined by OMG 2.It is a product of a consortium called the OMG 3.OMG includes 800 compinies representing the entire spectrum of computer industry. Lecture 1 slide 1

CORBA services Lifecycle services Persistence service Naming services
Event services Concurrency services Transactional services Relationship services Externalization Lecture 1 slide 2

CORBA services Query services Licensing service Properties services
Time service Security service Trader service Collection service Lecture 1 slide 3

Web services 1.SOAP(simple object access protocol)
2.WSDL(web service description language) 3.UDDI(universal description ,discovery integration) Lecture 1 slide 4

What is SOAP SOAP is a communication protocol SOAP is based on XML
SOAP is a simple and extensible SOAP will be developed as a W3C standard SOAP allowed you to get around firewalls SOAP is a format for sending messages The basic web services platform is XML plus HTTP Lecture 1 slide 5

What is WSDL WSDL is written in XML WSDL is an XML document
WSDL is used to describe web services WSDL is also used to locate Web services WSDL is not yet a W3C standard Lecture 2 slide 1

Benefits of SOA Better reuse Well defined interfaces
Easier to maintain Better flexibility Lecture 2 slide 2

DCOM DCOM is an extension to COM
DCOM uses a protocol called the object remote procedure call (ORPC) CORBA uses internet-inter ORB protocol DCOM using MIDL Lecture 2 slide 3

middleware's RMI RPC CORBA SOA WEB SERVICES Lecture 2 slide 4

Four main elements of CORBA
Object request broker CORBA services CORBA facilities Application objects Lecture 2 slide 5

CORBA facilities Are collections of IDL-defined frameworks
That provide services of direct use to application Categories -Horizontal -Vertical Lecture 3 slide 1

Core CORBA/java Advantages (of static Vs dynamic)
It is easier to program – remote method name, parameters. It provides more robust type checking – complete time checks. It performs well – a single API. It is self documenting Dynamic: m.i.is more flexible; allows to add new classes at runtime, useful for tools. Steps of CORBA static m.i: Create your IDL defs. build the interface defs. to the interface repository. Lecture 3 slide 2

Core CORBA/java pre compile – generates Add the servant impl.code.
client states server skeleton language specific example class, (CORBA 3.0 calls it a servant class) Add the servant impl.code. Compile the code. (ref. language compiler) Register the run-time objects with the Impl. Repository. Lecture 3 slide 3

Core CORBA/java Module counter { Interface count {attribute long sum;
Long increment ( ); }; Mapping CORBA IDL to Java Prompt > idl2java count.idl – no – comments – no-tie –no-tie-specifies not to generate extra delegation class. Still, it generates a Java package counter, which consist of 5 java classes & 1 Java interface. Counter.-Count Impl base – server side skeleton Counter.-st-count : client side stub Counter.Count Helper – provides useful helper for count clients. Counter.Count Holder: public instance member of type Package Counter; Lecture 3 slide 4

Core CORBA/java Counter.Count
Public interface count extends org.orng.CORBA.object. { Public int sum ( ); Public void sum (int – vol); Public int increment ( ); } Counter.-Example-Count-Example class for count obj.impl.VisiBroken’s Output: Package counter; Public class-example-count extends counter-count ImplBase Public – example – count (java.lang.string name) Super (name;) Lecture 3 slide 5

Core CORBA/java Public-example-count ( ) { Super ( ); }
Public int increment ( ) //implement operation public void sum (int sum) //implement attribute writer . . . Public int sum ( ) Lecture 4 slide 1

Core CORBA/java // implement attribute reader . . . . }
Server side of Count: // count Impl.Java : The count Implementation Class Count Impl Base extends Counter-Count Impl Base { Private int sum; Count Impl (string name) Super (name); S.O.P. (“count object created”); Sum = 0; Lecture 4 slide 2

Core CORBA/java Public int sum ( ) { Return sum; }
Public void sum (int val) Sum = val; Public int increment ( ) Sum ++ Return sum Lecture 4 slide 3

Core CORBA/java Main server program: Class count server {
Static public void main (string [ ] ays) { try { org.umg.CORBA.ORB orb = org.umg.CORBA.ORB. init (ays,null); org.umg.CORBA.BOA boa = cob.BOA – init ( ); count Impl count = new count Impl (“my count”); roa.obj-is-ready (count); boa.impl-is-ready ( ); Catch (org.umg.CORBA.Systm Exception e) System.error.print ln(e); } Lecture 4 sllide 4

Core CORBA/java Client side of Count: Class Count Client {
Public static void main (string [ ] ays) Try S.O.P (“initializing the ORB”); org.umg.CORBA.ORB orb = org.umg.CORBA.ORB init (ays, null); S.o.p (“building to count object”); Counter.count counter = counter.count helper.build (orb,”my count”); S.o.p. (“setting sum to o”); Counter.sum ((int)o); //calc.st.time. Long start Time = sytem.current Time millis ( ); //Increment 1000 times s.o.p (“incremtning”); Lecture 4 slide 5

Core CORBA/java for (int i=0, i<1000; i++) { Counter.increment ( );
} //calc.strp.time; print statistics Long step Time = system.current Time millis ( ); s.o.p. (“Avg ping = “+((stop Time-start Time)/1000t)+msecs”); s.o.p (“sum=”+counter.sum ()); Catch (org.umg.CORBA.system Exception e) System.err.printh (“system Exception”); System.err.printh(e); Lecture 5 slide 1

Core CORBA/java } O/p 1. Local static Remote static (10mbit/s Ethernet) 3.9 msecs 3.6 msecs 2. Symantic visual caf JIT sum JDK Local msec 6.7 msec Remote 3.6 msec 5.6 msec Lecture 5 slide 2

Core CORBA/java Orblets with Applets
Applets let you create component – sized apps that serves can ship to clients via ordinary HTML pages. Applets become an instant front-end to the remote services, you provide; so applets are “just-in-time” shippable clients. Applet life cycle: init, start, paint, action, handler Event, stop, destroy The HTML Applet Tag: CODE, WIDTH, HEIGHT, CODEBASE,ALGIN,PARAM Lecture 5 slide 3

Core CORBA/java CORBA-enabled Applet:
To create applet version of the COUNT client, enabled it inside an HTML page, download using web browser, invoke methods on the count server. The count IDL – Use count server, as is – so IDL remains unchanged. Our applet can use both the Counter.-st-count and Counter.counter Helper,as Server capture of the Java Count Applet Count client Applet Lecture 5 slide 4

Core CORBA/java The client applet code:
//count client Applet.java Applet client, visiBroker for Java. Import Java.awt.*; Public class Count client Applet extends java.applet.Applet. { Private Text Fields, count field, ping Time Field; Private button run Count; Private Counter.Count.counter; Public.void init ( ); //create a 2 by 2 grid of widgets Set Layout (new Grid Layout (2,2,10,10)); //Add the from widgets, initialize where add (new Label (“count”)); add (count Field = new Text Field ( )); Lecture 5 slide 5

Core CORBA/java count field.set Text (“1000”);
add (run count = new Button (“run”)); add (ping time field = new Text Field ( )); ping Time field.set Editable (false); try { //Init.the ORB. Show Status (“Initializing the ORB”); Org.omg.CORBA.ORB orb = org.umg.CORBA.ORB.init (this,null); //Build to the count object Show Status (“Binding to count object”); Counter = Counter.CountHelper.build(orb,”mycount”); } Catch (org.umg.CORBA.System.Exception) Show status (“applet Exception “+e);} Lecture 6 slide 1

Core CORBA/java } Public broken action (Event ev, object avg) {
If (ev.target = = run count) Try // set sum to initial value of 0 Show status (setting sum to 0”); Counter.sum((int)o); //get data from ad set value of applet fields. Show status (“Incrementing”); Int stop count = Integer.parse Int (count field.get Text( )); Ping Time Field .set Text (“ “); //calculate start time. Long start Time = system.current Time millis( ); Lecture 6 slide 2

Core CORBA/java //increment stop count time
For (int i = 0; i< stop Count; i ++) Counter.increment ( ); //calculate stop time; show statistics Long stop time = System.current Time millis( ); Ping Time Field.set Text (“avg ping = “+float.to String (float) (stop time-start time)/stop -count)+”msecs); Show status (“sum=”+counter.CORBA sum() ); } catch (org.umg.CORBA.System Exception e) { show status (“system exception “+e); return time; return false; Lecture 6 slide 3

Core CORBA/java Completion
Prompt . Java c– d\ count client applet.Java Create a web page Count .html <h1> count client Applet </h1> <hr> <center> <applet code = count client applet.class width = 300 height = 60 CODE BASE = classes> Lecture 6 slide 4

Core CORBA/java <paramname = org.umg.CORBA.ORB Class
Value = com.visigenic.vbroken.orb.DRB> </applet </count> <hr> Results: Local Vs Remote : Java applet/CORBA count server. Local static count Remote static count JIT compiled 17.6msecs msecs Interpreted msecs msecs Applets Vs Apps Java applet Java app JIT compiled msec msec Interpreter msec msec Lecture 6 slide 5

Dynamic CORBA The Portable Count
Make count portable by replacing the visigenic – specific bind with the CORBA naing semic. Rylau BOA-specific code in count with PoA semantics. CORBA Naming Semic: Generic structures to compose compound names – so it can work with global naming conventions such as URLs, domain names, DCE, JNDI, LDAP, NDS, Unix files, NTfiles etc. CORBA N.S.in the Tel.white.pages for objects, it lets you find objects by name. Name binding – name to obj.ref. Name context – newspace Lecture 7 slide 1

Dynamic CORBA ex: Each named component is a structure with two attributes – identifier – object name string kind – string to put a descriptive attribute – ex.file type. IDL Def. try a CORBA name: //IDL Type of sequence ,Name component>name; Struct name component {Istring id; Istring kind;}; Lecture 7 slide 2

Dynamic CORBA The object naming service interfaces:
Naming context – resolve, list, destroy, new-context, unbind, bind, rebind, bind-context, rebind-context, bind-new-context. Binding Instructor: next-one, next-n, destroy C/S Naming Scenarious: A Server invokes link to associate a logical name with an obj.ref. The N.S.adds this obj.ref from binding to its namespace database. client app. Invokes resolve to obtain an obj.ref. to this name. The client uses the obj.ref. to invoke methods on the target object. Scenarios 1: Creating the NS. resolve – initial – references (ORB) bind-new-context (Root context) – Results context bind-new-context (Results context) – client made context bind (client med context) – cascum. bind (client med context) – PlayeBonce Lecture 7 slide 3

Dynamic CORBA org.umg.CORBA.object obj ref = orb.resolve – initial – refernces (“name service”); org.umg.Cosnaming,naming context root context = org.umg.cosnaming.naming context helper.maxrow (obj ref); Scenario 2: Finding objects: resolve-initial –reference (ORB) create the name resolve (Root context) root.value – obj ref Invoke methods Portable count: Count portable client class The current IDL The current portable Impl class The current portable server class Lecture 7 slide 4

Dynamic CORBA The Dynamic Count
In static m.i., a pre compiled stub is required for each interface the client used. It is true even in the case of applets, through the stub’s byte codes are downloaded at run-time. Dynamic Invocation Interface (DII) is a stub-less binding approach. The client can invoke any operation on any object without repairing precompiled stubs i.e., the client discovers interfaces – related infn. at invocation time, it requires no compile – time knowledge. To discover remote objects, the mechanisms available are ‘string field’ object reference is provided to the client; which is converted into a live object reference an the connection is made. Clients can look up objects by using the CORBA naming service. Clients can discover objects by using the CORBA’s yellow pages – The Trader service. Lecture 7 slide 5

Dynamic CORBA The CORBA dyn. invocation process:
Obtain the Interface name get – interface ( ) returns a ref. to interface ref. object Obtain method Description Look up – name ( ) Describe ( ) To obtain the method’s full IDL def. Create Argument list: Create – list ( ) Add-item ( ) add item ( ). . add-item ( ) Create the request Lecture 8 slide 1

Dynamic CORBA Create-request (object reference, method, arguments list) Invoke the Remote method Using RPC Invoke ( ) send/receive send-deformed ( ) deferred get-response ( ) Data of ram one way send-one way ( ) Dyn. Invocation Interfaces – four Interfaces: CORBA : : object – pseudo object interface that defines opens that every CORBA object must support. Lecture 8 slide 2

Dynamic CORBA Methods: get-intefaces; create-request; - request.
CORBA::Report ;- pseudo object interface that defines the operation on a remote object. Method ; add-ary, invoke, send-oneway, send-defered, get response, pill.response, delete, add-item, add-value, get-count, remove, free, free-memory. CORBA::ORB: Gen. purpose ORB methods – create-list, create - operation- list, send – multiple-request-one-way, send-multiple-requests-defered, pill-next-response, get -next-response CORBA ::NVList: To help constant parameters – NV List object – maintains a list of self describing data items called Namedvalues. IDL- Street-Namedvalue { Identifier name; // my name any argument;//argument long len;//length/count of my value flys-modes//in,int, or inout Dynamic Invocation Scenarios: So it Yourself : Lecture 8 slide 3

Dynamic CORBA Client Object Interfaces def. Operationdef. ORB
get.interface ( ) look up name describe create – list add – item create – request Invoke delete free a variation of first method Lecture 8 slide 4

Dynamic CORBA The ORB-Can-Help scenario:
Client Object Interfaces def. Operationdef. ORB In place of steps 3,4, and 5 above issue 1 & 2 same as above 3. create – operation list 4. add-value 5. Create-request 6. invoke 7. delete 8. free Dyn. Invocation – the yet – another-way scenario: Lecture 8 slide 5

Dynamic CORBA The Dynamic Count: Test Results:
in stead of adding your arguments to an NVList, you add them to the request object. The Dynamic Count: Count server class, as is; so the IDL remains unchanged. No stubs for a dynamic client, however a mixed client is created that does both static and dynamic invocations. Count cliendDii.Java Test Results: Local Dyn. Count ping Remote Dyn.Count ping Invokenly 3.9msec msec Prepared invoke msec msec Note: Choices of method invocation: Static precompiled stubs Dynamic invocations using DII. Downloadabale stubs – Java – download both client & stubs, (applet). Lecture 9 slide 1

Dynamic CORBA When to use what Usage Pattern Recommendation
1. Client – Server frequent; use static precompiled stubs Server obj.doesn’t chage 2. Client – server ingrequent use DII 3. client – server object runtime use DII 4. Client runs with in browser; use downloadable applet and static if discovers new object stubs. Applet becomes the client for this object. Lecture 9 slide 2

Dynamic CORBA Multi – Count
Multi client – multiple clients, call backs,; reversely C&S roles. VisiBroken for Java CORBA ORB is both a C&S Multi Threaded client – client using Java’s threads Coordinator – a new server – uses callbacks to remotetly control clients. Applet as a front-end to the coordinator – called multi console. Lecture 9 slide 3

Dynamic CORBA The Multi count CORBA interfaces: Methods – start, stop
Client control interface – client call back Methods – start, stop Coordinator interface - server Methods – start, stop, register count interface - server method – increment A Multi count callback Scenario Lecture 9 slide 4

INDEX UNIT 6 PPT SLIDES S.NO TOPIC LECTURE NO. PPTSLIDES 1.CORBA initialization protocol L L1.1 TO L1.4 L L2.1 TOL 2.4 2.CORBA activation services L L3. 1 TO L3.3 L L4. 1 TO L4.3 3. CORBAIDL mapping L L5. 1 TO L5.3 4. java-to-IDL mapping L L6. 1 TO L6.3 L L7. 1 TO L7.3 5. The introspective L L8. 1 TO L8.3 CORBA/Java object L L9. 1 TO L9.4

UNIT6 SYLLABUS Existential CORBA: CORBA initialization protocol, CORBA activation services, CORBAIDL mapping CORA java-to-IDL mapping. The introspective CORGA/Java object. Lecture 1 slide 1

EXISTENTIAL CORBA A new service provider will first register its service with the trader and then provide An object reference – which can be used by clients to comment The service type name – methods, parameters, ret-type etc The properties the service – name value pairs The trader maintains a repositiing of service types – ex: restaurant. The Trader stores type descriptions in its service type repositing. Lecture 1 slide 1

EXISTENTIAL CORBA Federations – Traders groups – electronic basers.
The traders service lets you prove a search via policies, constraints and preferences. Policies – Scope of the search. Ex: hop-count to limit the no.of trader links traversed. Constraints – Search criteria – language can be specified. Ex: <<SQL>. Preferences – order in which the matching offers are returned. Ex: first (default), max, min, random, with constraint layers- <<SQL>>etc Lecture 1 slide 2

EXISTENTIAL CORBA Prestarting server objects before clients connect to them, is a costly exercise, since there could be millions of server objects. The server side of the ORB has to provide an automatic startup function. The ORB should be able to either prestart an object or start it on demand, when clients invoke it. It must also cooperate with a persistent service to save and restore the state of your server objects. Topics covered: ORB activation and deactivation policies by BOA; Visibroken for java activation policies, CORBA 3.0 POA; POA-EOB. Lecture 1 slide 3

EXISTENTIAL CORBA The CORBA::BOA interface:methods: to create or destroy obj.ref., to query or update the infn. The BOA maintains for an obj. Create, change-implementation, get-id, dispose,get-principal,set-exception, impl-is-realy,obj-is-ready,deactivate-impl,deactivate-obj. Infn to be supplied – a) Interface name b) Implementation name 3) Some unique ref data (or ID) persistent ID (PID). Activation policies : CORBA 2.0 defines 4 activation policies a) shared server b) unshared server c) server-per-method and d) persistent server a) BOA shared server: Lecture 1 slide 4

EXISTENTIAL CORBA BOA activates the server the first time a request is invoked on any obj. implemented by that server. The server initializes itself & notifies the BOA – impl – is – ready. All subsequent requests are then diverted to this process. when the process is ready to terminate, it notifies BOA – deactivation-impl. All the objects that are running with in the process are deactivated automatically. you can also deactivate an individual object, by issuing deactivate object. Lecture 2 slide 1

EXISTENTIAL CORBA Threads are used to run multiple objects concurrently with in the process. you can even use multiple threads to represent the same object to multiple clients – serialize the access to state (data base) or treat it as a Java synchronized method. Note: make sure your ORB is thread – safe visibroker for java is thread-safe. Lecture 2 slide 2

EXISTENTIAL CORBA BOA Unshared server:
Each object in a differ.server process. new server activated first time a request is invoked the object. It notifies BOA object-is-ready. A new server object remains active, until deactivate object. usage – dedicated object to represent provides, but on a manufacturing line etc. Lecture 2 slide 3

EXISTENTIAL CORBA c) BOA server-per-method:
New server for each new request. Server runs only for the deviation of the particular method. Several server processes for the same object- or even the same method of the same object-may be concurrently active. No notification to BOA, when an object is activate or deactivated. Most infrequent usage – useful for running objects or d) BOA Persistant Server Lecture 2 slide 4

EXISTENTIAL CORBA Servers are activated by means outside BoA.
impl-is-ready call is used to notify BoA. Usage : it is just a special case of shared server Server activation is not by BoA DBMS, ODBMS, TPMonitor or web server of all the time. So there are good candidate apps. For the persistent server policy. Shared server activation scenario Lecture 3 slide 1

EXISTENTIAL CORBA The visibroker Activation Daemon CORBA 3.0’s PoA
CORBA 2.0 – client side portable; but nor server side; resulting in ORB to look after and diff. vendors have diff. standards. CORBA 3.0 – PoA – June implemented is Visibroker for Java3.1 orbix web 3.0, and the JDK 1.2 version of java IDL. BoA & PoA can consist. obj. is ready replaced by connect. deactivate-obj replaced by disconnect. Lecture 3 slide 2

EXISTENTIAL CORBA PoA : Transparent activations of objects, like BoA.
Like BoA, PoA can start server prog. for each method, separate prog. for each object, thread prog. for all instances of an obj.type. Like BoA, PoA supports both IDL-generates static skeletons & DSI. PoA supports transient or persistent objects. New concepts – servant mangers – call back objects, object maps etc. Server Lecture 3 slide 3

EXISTENTIAL CORBA PoA policies Policy Type Policy Desc. & Choices
1. Thread ORB-CTRL-MODEL-ROOT-PoA Default SINGLE-THREAD-MODEL. 2. Life span TRANSIENT – default PERSISTENT 3. Obj.id uniqueness UNIQUE – ID-default; MULTIPLE ID 4. Id.Assignment USER-ID;SYSTEM-ID-default 5. Servant Retention RETAIN-default; NON-RETAIN 6. Activation IMPLICIT – ACTIVATION-default; No- IMPLICIT ACTIVATION 7. Request Processing USE-ACTIVE-OBJECT-MAP-ONLY-default, USE-DEFAULT-SERVANT; USE-SERVANT-MANAGER Lecture 4 slide 1

EXISTENTIAL CORBA Different Policies Combinations :
1. RETAIN and USE-ACTIVE-OBJECT-MAP-ONLY - good for serves that manage finite no.of pre-started objects. 2. RETAIN and USE –SERVANT – MANAGER - ideal for large no.of persistent objects. 3. RETAIN and USE-DEFAULT-SERVANT - ideal for situations where one servant is used per method call. PoA creating object References: can be exported to clients 1. By explicitly invoking the PoA’s factory methods. - Create-reference and create-reference with id methods. Lecture 4 slide 2

EXISTENTIAL CORBA 2. Explicitly at obj. activation
- activate – object and activate-object-with-id methods. 3. Implicitly at obj.activation – policy declaration. Object Activation 1. Explicitly, is a calls to the PoA. 2. On-demand, using a servant manager. 3. Implicitly – policy declaration PoA interfaces: org.omg.CoRBA, servant manager, servant activator, servant locator, Adapter Activator. PoA interface etc. Lecture 4 slide 3

EXISTENTIAL CORBA The CoRBA IDL to Java Mappings: CoRBA IDL Java
To support multiplatform and Multilanguage world of distributed clients and servers, we need IDL-to –Java mapping. The IDL-to-Java language mapping also defines an interface for portable stubs and skeletons that CoRBA vendors must support. The CoRBA IDL to Java Mappings: CoRBA IDL Java General Constructs 1. Module Package 2. User exceptions java class – extends org.omg.CoRBA user exception, which in twin extends java.long exception 3. System exceptions Java class – org.omg.CoRBA.System Lecture 5 slide 1

EXISTENTIAL CORBA Exception-extends java.long.RuntimeException.
4. in parameters normal java parameters 5. out and inout parameters Java holder classes (IDL generated and then instantiated by client side) 6. Type casts (or narrow) java helper classes 7. Attributes Java overloaded accessor and modifier methods with the same name as the attribute. Lecture 5 slide 2

EXISTENTIAL CORBA CoRBA IDL Java Primitive Types
1. Const Public static final field 2. Boolean, TRUE,FALSE Boolean. True. False 3. char, wchar char 4. octet byte 5. string, wstring java.long.string 6. short, unsigned short short 7. long, unsigned long int 8. long long, unsigned long long long 9. float float 10. double double Lecture 5 slide 3

EXISTENTIAL CORBA Constructed Types 1. interface interface
2. sequence array 3. array array 4. struct java class with same name as struct type (includes instances variables and constructors for each field) 5. enum java class with same name as enum type. 6. union java class with same name as union type class with get/set methods for fields. 7. type def java does not have a type def construct. Mapped to simple IDL types or user defined IDL types. 8. ary java class org.omg.CoRBA.ary (the ORB is the factory) Lecture 6 slide 1

EXISTENTIAL CORBA CoRBA IDL Java Server.side Mapp
1. Server implementation using write an implementation class that extends inheritance the IDL-generated-<interface-name>Impl base class. 2. Server implementation using IDL-generated –tie-<interface.name>class using delegation (i.e, Tie) that delegates calls to the implementation Lecture 6 slide 2

EXISTENTIAL CORBA class you provide. The implementation class implements one or more IDL-defined interfaces (each represented by an IDL-generated <interface-name> operations interface) 3. PoA root servant class java class org.omg.CoRBA.portable.object Impl.pseudo.objects to java classes (only most frequently used are tested). Lecture 6 slide 3

EXISTENTIAL CORBA 1. CoRBA::ORB Java class org.umg.CoRBA.ORB
2. CoRBA::Object Java class org.umg.CoRBA.Object 3. CoRBA::Named value Java class org.umg.CoRBA.Named value 4. CoRBA::NVList Java class org.umg.CoRBA.NVList 5. CoRBA::Request Java class org.umg.CoRBA.Request (and DSI mapping) Lecture 7 slide 1

EXISTENTIAL CORBA 6. CoRBA::Server Request(and DII) Java class org.umg.CoRBA.server request 7. CoRBA::Type code Java class org.umg.CoRBA.Type code 8. CoRBA::TCKind Java class org.umg.CoRBA.TCKind Lecture 7 slide 2

EXISTENTIAL CORBA Feature CoRBA comp. JavaBeans Events
1. Add/remove event listeners yes yes 2. Event object yes yes 3. Event listener yes yes 4. Too many listeners yes yes (Multicast/Unicast) Simple properties 5. get/set single value yes yes 6. get/set indexed yes yes 7. is/set Boolean yes yes Lecture 7 slide 3

EXISTENTIAL CORBA Bound properties 8. Property change event yes yes
9. Property change listener yes yes 10. Property change support yes yes Constrained properties 11. Property change Event yes yes 12. Vetuable change listener yes yes 13. Vetoable change support yes yes 14. Property Vector Exception yes yes 15. Asynchronous Veta notification yes No Lecture 8 slide 1

EXISTENTIAL CORBA Customization 16. Property editor yes yes
17. Customizer yes yes 18. HTML help yes yes Lecture 8 slide 2

EXISTENTIAL CORBA MetaData 19. Interface Reposting/IDL yes i/o
20. Introspector yes yes 21. BeanInfo yes, comp.Info yes 22. Feature Descriptor yes yes 23. Property Descriptor yes yes 24. Method Descriptor yes yes (Derived from the CoRBA IR’s operation Def) 25. Event set Descriptor yes yes 26. Vensin Descriptor yes No Lecture 8 slide 3

EXISTENTIAL CORBA Packaging 27. Serialization yes yes 28. JARs yes yes
(Called Component Archive or CAR) Lecture 9 slide 1

EXISTENTIAL CORBA 29. Manifest yes yes
30. Deployment Descriptor yes yes 31. Installation Support yes No Composition and containment 32. Container yes yes, JDK 1.2 Bean Context 33. Containee yes yes, with JDK 1.2 34. Container Listener yes yes, with JDK 1.2 35. Multiple Interfaces yes, aggregation yes, Beans.getInstance of Lecture 9 slide 2

EXISTENTIAL CORBA Comp. Life Cycle 36. Factories yes yes, with EJB
37. Activate/deactivate yes yes, with EJB 38. Persistent object refs yes yes, with EJB 39. Move yes No 40. Remove yes No CoRBA Remote Events: Lecture 9 slide 3

EXISTENTIAL CORBA Like JavaBean, CoRBA listeners must implement on Event xxx listener that extends the event listener interface. Similarly add/remove xxx listener. Added.adv – CoRBA event objs. Can be transmitted over the n/w – done by pass-by-value semantics. Dist.Event – channel CoRBA Containers : Container & containee Useful for maintaining comp. hierarachy. Ability to assemble components inside a container. Lecture 9 slide 4

B.TECH III YR II SEMESTER UNIT 7 PPT SLIDES TEXT BOOKS 1.Client/Server programming with Java and CORBA Robert Orfali and Dan Harkey, John Wiley & Sons,SPD 2nd Edition 2. Java programming with CORBA 3rd Edition, G.Brose, A Vogel and K.Duddy, Wiley-dreamtech, India John wiley and sons

Events L L1.1 TO L1.3 L L1.1 TO L1.3 properties L L1.1 TO L1.3 L L1.1 TO L1.3 Persistency L L1.1 to L1.3 L L1.1 to L1.3 Introspective of beans L L1.1 TO L1.4 CORBA Beans L L1.1 TO L1.5

UNIT 7 SYLLABUS Java Bean Component Model: Events, properties, persistency , Introspective of beans, CORBA Beans Lecture 1 slide 1

Bean Java beans are the software components that has been designed to be reusable in a variety of different environments Lecture 1 slide 1

Java bean is basically a java class with the following rules
1.All the instance variables must be private 2. Access to the instance variables should be provided by using setXXX() and getXXX() methods 3.There should be a zero parameter constructor in the class Lecture 1 slide 2

Bean program Ex: class Mybean { private int htno; Mybean() }
void setHtno( int x ) { htno = x; int getHtno() { return htno; Lecture 1 slide 3

BDK Beans are two types BDK stands for BEAN DEVELOPEMENT KIT
Executing the Existing Beans Executing the User-Defined Beans For Executing the JavaBeans Using BDK Compulsory You Have To Install JDK Lecture 2 slide 1

BDK components BDK Contains 3 types of Components: 1) Tool Box
2) Bean Box 3) Property Sheet Lecture 2 slide 2

Bean development kit Lecture 2 slide 3

Executing existing beans
Position the cursor on the tool box entry labeled juggler and click left mouse button. Move the cursor to the bean box area and click the left mouse button. labeled Our Button and click left mouse button. Go to the properties window and change the label Lecture 3 slide 1

By selecting the button, go to the menu bar of the Bean Box and select Edit – Events – action- action Performed. You should see a line extending from the button to the cursor Move the cursor so that the line drop inside the display area of juggler, and click left mouse button. Now you should see the Event Target Dialog Box. The dialog box allows you to choose a method that should be invoked when the button is clicked Lecture 3 slide 2

Lecture 3 slide 3

Lecture 4 slide 1

Lecture 4 slide 2

Procedure to executing user defined bean
For Executing the User Defined Beans with BDK we require 2 files 1. JAR File 2. Manifest File Lecture 4 slide 3

JAR JAR File stands for JAVA ARCHIEVE FILE
JAR Files are Java’s Version of zip Files There are Two main uses for JAR files 1) The first use is to compress (make a smaller size) a number of files into one file (archiving) 2) It makes easy to download Lecture 5 slide 1

jar JAR files can be opened with WinZip or Winrar. In terms of Java applications, the ability to archive any number of source or class files into one single archive represents the biggest advantage - distributing one file containing hundreds of files is so much easier than distributing hundreds of files separately Lecture 5 slide 2

Creation of jar Creating a Jar file:
The syntax of utility used to create jar file is Jar options (list of files) List of Options: c: Create a new archive (jar) f : The first element in the file list is the name of the jar that is to be created or accessed m: The second element in the file list is the name of the external manifest file t : Tabulate the contents of jar u: Update the jar file x: Extract the files from jar 0: Do not use compression v: Generate verbose output on standard output file Lecture 5 slide 3

creating a jar file with name MT.jar that contains all the
Multiple options can be used together. They all must appear after the "jar" command with no white space separating them. Examples: creating a jar file with name MT.jar that contains all the .class and .gif files of the current directory Jar cf MT.jar *.class *.gif And with the above if we have a manifest file that is to be added Then the above statement will become Jar cfm MT.jar Manf.mf *.class *.gif Lecture 6 slide 1

Example Manifest file:
A developer must provide a manifest file to indicate What are the components of a jar file and Which of these components in a jar file are java beans Ex : name: sunw\demo\slides\fig1.gif name: sunw\demo\slides\fig2.gif name: sunw\demo\slides\slide.class Java-bean: true Lecture 6 slide 2

Example import java.awt.*; import java.awt.event.*;
public class Colors extends Canvas { private Color color; private boolean rectangular; public Colors() addMouseListener(new MouseAdapter() public void mousePressed(MouseEvent me) change(); } }); Lecture 6 slide 3

Example rectangular=false; setSize(200, 100); change(); }
public boolean getRectangular() { return rectangular; public void setRectangular(boolean flag) this. rectangular = flag; repaint(); Lecture 7 slide 1

Example public void change() { color = randomColor(); repaint(); }
private Color randomColor() int r = (int)(255*Math.random()); int g = (int)(255*Math.random()); int b = (int)(255*Math.random()); return new Color(r,g,b); Lecture 7 slide 2

Example public void paint (Graphics g) { Dimension d = getSize();
int h = d.height; int w = d.width; g.setColor(color); if(rectangular) g.fillRect(0, 0, w-1, h-1); } else g.fillOval(0, 0, w-1, h-1); Lecture 7 slide 3

Compile the Colors. java file using Command Prompt Create The Manifest file Create Jar File Load The Jar File into Bdk Lecture 7 slide 4

Creating manifest file
Name: Colors. class Java-Bean: True Save this file in the form of “manifest.mft” Lecture 8 slide 1

Creating jar file Start Command Prompt.
Navigate to the folder that holds your class files: C:\>rams Compile your classes: C:\rams> javac *.java Then create Manifest file Create a jar file: C:\rams> jar cvfm bdk.jar manifest.mft *.class Lecture 8 slide 2

MVC MVC ( Model View Controller)
The MVC design pattern is the basis for the most web-application frameworks today Ex: Struts, JSF, Spring are all implementations of MVC design concept The new programming environment called Ruby on rails is entirely based on MVC design pattern In MVC the Controller is implemented by using a servlet View is implemented by JSP and the Model by Java beans Lecture 8 slide 3

MVC A servlet is a Java programming language class that is used to extend the capabilities of servers that host applications access via a request-response programming model Java Server Pages (JSP) is a technology based on the Java language and enables the development of dynamic web sites. JSP was developed by Sun Microsystems to allow server side development. JSP files are HTML files with special Tags, containing Java source code that provide the dynamic content Lecture 8 slide 4

JSP tags There are four main tags: 1. Declaration tag ( <%! %> )
2. Expression tag ( <%= %>) 3. Directive Tag ( directive … %>) 4. Scriptlet tag ( <% … %> ) 5. Action tag (<jsp : usebean ----%> ) Lecture 8 slide 5

Object transaction monitors L L1.1 to L1.4 L L2.1 TO L2.4 2. EJB and CORBA OTM’s L L3.1 TO L3.3 L L4.1 TO L4.2 3. session and Entity Beans L L5.1 TO L5.2 4. The EJB client/server development L L6.1 TO L6.2 5. EJB container protocol L L7.1 TO L7.2 6. EJB packing L L8.1 TO L8.2

UNIT8 SYLLABUS EJBS and COBRA:
Object transaction monitors CORBA OTM’s EJB and CORBA OTM’s EJB container frame work, session and Entity Beans, The EJB client/server development processes the EJB container protocol, support for transaction EJB packing EJB design Guidelines.

IS A STNDARD SPECIFICATION WHICH
EJB DEFINITION EJB IS A STNDARD SPECIFICATION WHICH ALLOWS US TO DEVELOP A DISTRIBUTED TRANSACTIONAL SECURE COMPONENTS IN JAVA Lecture 1 slide 1

EJB COMPONENT IS A COMBINATION OF SOMECLASSES AND INTERFACES DESIGNED FOLLOWING THE EJB SPECIFICATION STANDARDS. Lecture 1 slide 2

EJB CONTAINER is a readymade platform which is a rich of all the low-level services which can provide runtime environment for ejb components. Lecture 1 slide 3

EJBS AND CORBA Enterprise JavaBeans and CORBA
Object transaction monitors, CORBA OTM’s, EJB and CORBA OTM’s, EJB container F/W, session and Entity beans, The EJB C/S development process, The EJB container protocol, support for transaction, EJB packaging, EJB design guidelines. OTMs An OTM is a morph of TP monitor with an ORB. Or, in other words, it is a TP monitor built on top of an ORB. An ORB is simply an object bus, with an object bus, anytime goes, in contrast, an OTM provides a framework, for running server-side components. Lecture 1 slide 4

EJBS AND CORBA Procedural Vs F/W Appraches to Developing code
Advantages of OTM’s approach: Yours objects become managed transactional, robust , persistent and high-performing. Functions of OTM: Activates and deactivates your components Coordinates distributed transactions. Notifies your component of key events during its life style. Lecture 2 slide 1

EJBS AND CORBA Automatically manages the state of your persistent component. CORBA OTM’s : from four groups TP Monitor vendors moving to ORB-based middleware. ex: BEA Iceberg, IBM component broker. DBMS Vendors moving from 2-tier to 3-tier. ex: oracle app. Server 4.0, Gene stone/J, Sybase/jaguar. ORB vendors moving from pipes to TP – based app. servers. ex: Iona orbix OTM, Visigenic/Borland ITS Web server vendors moving to TP-based app. servers ex: Net Dynamics App. server 4.0, Netscape Enterprise server 4.0/kiva, sapphire/web 4.0 Lecture 2 slide 2

EJBS AND CORBA EJBs and CORBA OTMs:
EJB defines a server side component model and a comp. coordinator f/w that is totally compatible with CORBA. The EJB Container F/W The major functions a server-side container (or OTM) provides to the EJBs that run within it. Packaging Dist.obj.infrastructure Comp.packaging and deployment Declarative trans. Mgnt. Lecture 2 slide 3

EJBS AND CORBA Factory support Bean activation and persivation
Bean state mgnt. Container metadata Security Session and Entity Beans: Characteristics of a session bean Lecture 2 slide 4

EJBS AND CORBA Executes on behalf of a single client
Can be transaction – aware Updates data in an underlying data base. Relatively short-lived, life time is that of its client. Destroyed when the EJB server crashes; client has to a new session Does not represent data that should be stored in a data base. Lecture 3 slide 1

EJBS AND CORBA Characteristics of an Entity bean
Supports shared access from multiple users. Participates in transactions Represents data in the data base. Can be ling-lived (as long as the data base). Survives crashes of the EJB server; crash transparent to the client Has a persistent obj.ref. Lecture 3 slide 2

EJBS AND CORBA EJB Packaging
Extends the existing javabeans packaging technology to take car of the needs of server side beans. EJB packaging can be used to distribute a single enterprise bean or to distribute an entire server-side application built of multiple enterprise beans. EJB-JAR and manifest – list-java file contains EJB’s class files Deploy base Manifest that identifier the enterprise bean included in the JAR. Lecture 3 slide 3

EJBS AND CORBA The manifest is named META-INF/MANIFEST.MF.
EJB Design Conditions: Your remote interface must follow the CoRBA/MI/IDL subset. Define a remote interface. Dont mess around threads Don’t issue commits or roll backs. Give your containers a full EJB-jar package. Lecture 4 slide 1

Middleware Technologies

Similar presentations

Presentation on theme: "Middleware Technologies"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Middleware Technologies

Similar presentations

Presentation on theme: "Middleware Technologies"— Presentation transcript:

Similar presentations

About project

Feedback