Middleware Technologies III Sem. M.Sc., CS UNIT 1 Dr.K.Prakash Assistant Professor Kristu Jayanti College Bengaluru
Introduction Software Architecture Two-tier architecture T he client and server layers communicate directly with each other. The client sends requests to the server, and the server processes those requests and responds back to the client. The server is responsible for handling the business logic, data processing, and data storage. Advantages It is scalable upto 100 clients User-friendly interface Flexible
Disadvantages Fails when user exceeds 100 Not suitable for batch processing Limited flexibility
Three-tier architecture Presentation Tier (also known as the User Interface or Client Tier): This is the topmost layer and is responsible for interacting directly with the users or clients. It handles user input and displays the information to users in a human-readable format. In web applications, this tier is usually implemented using technologies like HTML, CSS, JavaScript, and frontend frameworks. Application Tier (also known as the Business Logic Tier or Middleware): The middle layer, responsible for processing user requests and managing the application's business logic. It processes the data received from the presentation tier and interacts with the data tier to retrieve or update information as needed. This tier is where the application's core functionality and business rules are implemented. Data Tier (also known as the Database Tier or Backend Tier): The bottommost layer, responsible for managing and storing data. It handles data storage, retrieval, and manipulation operations. Typically, this tier includes a database or data storage system like SQL databases (e.g., MySQL, PostgreSQL) or NoSQL databases (e.g., MongoDB, Cassandra).
Features Modularity : The separation of concerns into different tiers makes it easier to modify, update, or replace individual components without affecting the entire system. Scalability : Each tier can be scaled independently to handle increased demand, improving performance and responsiveness. Security : By isolating the data tier from the other layers, sensitive data can be protected more effectively. Reusability : Components in each tier can be reused in other parts of the application or in different applications altogether. Maintainability : The clear division of responsibilities makes it easier to troubleshoot issues and maintain the codebase.
Three-tier architecture with ORB Client-server systems uses distributed object technologies that facilitates interoperability across languages and platforms. It enhances maintainability and adaptability. This has led to middleware technology – ORB [Object Request Broker]. ORB supports a network of clients and servers It is transparent and it knows the availability of services between the clients and servers ORB – Middle tier acts as a broker Interoperability Strengths maintainability and adaptability
Components Component is a like an application – CBSD. It is composed of interfaces and explicit context dependencies. It deploys independently and subject to third parties. It is a bundle of binary codes that is compiled, linked and ready-to-use.
Component architecture is defined as the architecture to develop an application using components. It facilitates rapid application development and distribution of components. It includes dynamic linking, encapsulation, interfaces, binary format, transparency and language independence. CBSD, writing code is replaced with building a system by assembling and integrating existing components.
Features of components Information hiding Context Independence Implicit invocation Interoperability Component models Simplicity Reliability Flexibility
Components and Objects Components and objects are mixed up. It can be viewed as collection of classes. Components are like black box whereas OOP are white box. Components may be object oriented or non-object oriented. A component can contain multiple classes. One class contains a single component.
Advantages of Components Combination of small parts Easy to build Uniform interfacing Built from variety of technologies Can be changed Better quality Reliability Easy to transfer to other systems because of contextual dependencies Interaction protocols can be reused
Supports modularity in Software development Architecture Phases such as, requirements design and implementation Satisfying engineering goals such as, reusability time-to-market quality viability
Modules Modularization is the process of grouping similar functionalities together. Module is viewed as logical collection of objects and classes. Modularity is the property by which a system can be decomposed into set of cohesive and loosely coupled modules. Modules form a complete executable program. Modularity deals with the partitioning of a program into individual components to reduce the complexity of the system developed.
Modules versus Classes Modules Classes Do not have Instantiation Has Instantiation Viewed as components Cannot be Plug-and-play Not feasible Collection of methods and constants Construct of defining an object
Interfaces Interfaces are the means by which the components connect. Interface is a set of named operations that can be invoked by clients. It specifies the semantics of the operations. They are immutable. Types – Direct or Procedural Indirect or Object Direct Interface – Directly provided by a component corresponds to procedural interfaces of traditional libraries. Indirect Interface – Provided indirectly by objects made available by the component.
Direct and Indirect Interfaces ATM Services ATM card authentication interface Bank Services Authentication Component
Callbacks Callbacks are functions that are set up by the programmer to react to signals emitted by widgets. The function to be called is connected with the signal. Callbacks are pre-defined or user-defined signal handlers. Callback is a procedure that is registered with a library at one point.
Definition In programming, a callback is a function or a piece of code that is passed as an argument to another function. The purpose of a callback is to specify what should happen once a certain task or event is completed. Callbacks are commonly used in asynchronous programming, where tasks are executed independently of the main program flow.
Example program function delayedExecution ( callback , delay) { setTimeout ( callback , delay); } function greet() { console.log ("Hello, world!"); } delayedExecution (greet, 1000);
Directory services It is a part of simple file system Used to provide a visual representation of the directory to the clients It provides the following facilities: Lookup for the required file Addition of named files Deletion of named files Registration of callbacks Deregistration of callbacks There are 2 interfaces in this module, Directory and DirectoryDisplay .
Directory interface and DirectoryDisplay interface Operations Operations performed by interfaces with pre and post conditions SearchFile AddFile DelFile RegisterNotifier UnRegisterNotifier InNotifier
Component Architecture Component-based architecture decides on the platforms, frameworks and interoperability design for the frameworks. Component framework specifies the mechanism and policies at the component level. A component is a set of atomic components. An atomic component is a module and a set of resources. Components based systems follows a layered architecture.
CA with several layers and three tiers CI – Component Instance CSI – Component System Instance CFI – Component Framework Instance A Component Instance refers to a specific occurrence or instantiation of a software component within a larger system A Component System Instance is an instantiation of an entire system that is built using a component-based architecture A Component Framework Instance refers to a particular implementation or usage of a component framework. A component framework is a set of tools, libraries, and conventions that facilitate the development and integration of software components.
CBSD Component-Based Software Development Component-based software development advocates developing software systems by selecting reliable, reusable and robust software components and assembling them within appropriate software architectures. By promoting the use of software components that commercial vendors or in-house developers build, the component-based software development approach promises large-scale software reuse. Component-based software engineering offers an attractive alternative for building Web-based enterprise application systems.
CBSD Life Cycle
Activities Component Qualification Component Adaptation Component Assembly System Evolution(Upgradation)
Component Qualification Components are Discovered with its ‘fitness for use’ using ISO, IEEE and other standards (Property, Functionality, reliability and evaluation) Component Adaptation White box, Gray box and Black box approaches Component Assembly Database, Blackboard, Message bus and ORB-mediated System Evolution(Upgradation) Locating erroneous components, repairing and replacing defective components
Advantages of CBSD
UNIT 2
Java-Based Component Models JavaBeans, RMI, RMI-IIOP and EJB RMI facilitates distributed object computing brought by Sun Microsystems RMI communicates only among Java objects RMI-IIOP facilitates among objects written in different programming languages JavaBeans is a client-side component model EJB is a server-side component model
JavaBeans Java bean is a self-contained software component. It provides a platform-neutral component architecture Java beans is run in JVM Bean instances behaves differently when run on the server. Features Presence of introspection Customization of appearance and behavior Availability of events to facilitate communication between source and listener
Providing security features Supports persistence Providing full access to Java API Network access mechanism 1. Remote Method Invocation(Java platforms) 2. Interface definition Language (CORBA objects) 3. JDBC (SQL databases)
Aspects of bean model Events Properties Introspection Customization Persistence
Events Events in JavaBeans are a way for a component to notify other components about certain occurrences or changes. They follow the Observer design pattern, where one component (the "listener" or "observer") registers itself with another component (the "source" or "subject") to be notified when a specific event occurs. Interface UserListener extends java.util.EventListener { void user( UserEvent e); }
Types JavaBeans architecture uses events composed of three parts, source events and listener Source : It is an object that originates or fires the event. Listener : It is an object that indicates that it is be notified by events of a particular type. Events : Event objects are actions notifies one component to the other.
Properties Properties are attributes that affects bean instances or behavior. A programmer can get or set the value of a property through method calls. An application developer can manipulate the value of attribute using a visual development tool. Java beans allows four types of properties, Simple Indexed Bound Constrained
Simple Takes single value as a string or number. Public void setsize ( int s) { Size=s; } Indexed It get or set an array. X[] getPropertyName () void setPropertyName (X[] x)
Bound This property notifies listeners that their values have changed. Example – size is a bound property, that changes and notifies automatically. void addPropertyChangeListener ( PropertyChangeListener listener) void removePropertyChangeListener ( PropertyChangeListener listener)
Constrained A property that can be vetoed is called constrained. Any listener can reject any changes then it is said to be veto. VetoableChangeEvent Customization It provides facility to modify the appearance and behavior of a bean within an application builder to suit the developer needs. This is like a visual development tool with user interface (GUI).
Property editors and customizers Property editors and customizers helps to customize the bean’s appearance and behavior. Property editors is a tool for customizing particular property type. It activates in property window. “ PropertyEditor ” Customizers supports GUIs to control over beans. Java.awt.Component (Class using package) Java.beans.Customizer (interface) BeanInfo.getBeanDescriptor (method)
Introspection It is the theory of internal inspection. This is useful at both run-time and at design time. ‘ BeanInfo ’ class provides descriptive information about its associated bean explicitly. It is also used to provide a clear description of a complex bean. Introspection facilities are: Portability and reuse Portability – Java components can be written once and used in different platforms. Introspection helps to inspect the properties of these components when they are used in another platform. Reuse – JavaBeans conventions, interfaces and classes be reused because they are proper, appropriate and suitable.
Example The getBeanInfo method of i ntrospector class BeanInfo used b y builder tool to provide detailed information bout a bean. A call to getBeanInfo results in the introspection process analyzing the bean’s classes and the super classes. BeanInfo Interface BeanDescriptor FeatureDescriptor EventSetDescriptor MethodDescripptor PropertyDescriptor ParameterDescriptor
Reflection Introspection uses Java’s Reflection API. Reflection is used by programs which requires the ability to examine or modify the run-time behavior of applications running in JVM. Services inspecting classes and interfaces construction of new class instances and arrays access to and modification of fields of objects and classes access to and modification of elements of an array invocation of methods on objects and classes
Reflection also used in Application E xtensibility, Class browsers and Visual development Environments, Debuggers and test tools. Drawbacks Slower performance Security restrictions (Security manger won’t allow reflections) Exposure of internals (Breaks abstractions)
Persistence Persistence is the property that saves and retrieves the properties, fields and state information. Beans supports storage mechanism called Java Object Serialization . Automatic mechanism for saving an restoring the state of an object. Object serialization means converting an object into a data stream and writing it to the storage. It may ‘reconstitute’ by deserialization (turns to its original state). This ensures that the beans are portable. Externalization mechanism is used for a bean to use other file formats and its mechanisms.
Serialization levels Automatic – implemented using Serializable interface. Customized – should not be serialized automatically. Only by Serializable classes having methods readObject () and writeObject (). Customized file formats – Externalization mechanism facilitates to read and write external file formats. readExternal and w riteExternal methods are used.
JAR Files All the class files used by bean code are packaged into a J ava Ar chive File (JAR). This makes a bean useful in a builder tool. A JAR file needs a M anifest file . Manifest files specifies the class files that beans are utilized in the tool box. Manifest files contains the bean classes. Example – ex.mf
Creation of Manifest file e x.mf Manifest – Version: 1.0 Name: ex1Bean.class Java-Bean: True Name: ex2Bean.class Java-Bean: True Here, ex1Bean and ex2Bean are bean classes.
Creation of JAR file j ar cfm JarFile ManifestFile *.class Example, j ar cfm ex.jar ex.mf *.class BDK – Bean Development Kit Three windows, ToolBox BeanBox Properties window
ToolBox window displays currently installed beans which comes in BeanBox demo. When BeanBox starts, it automatically loads its toolbox with the beans in JAR files. BeanBox window appears as empty window. It is used as a “form” for building applications. Properties window displays the current properties for the selected bean. If no bean selected then it displays the BeanBox properties.
jar cfm JarFile ManifestFile *.class jar : This is the Java Archive tool, which is part of the Java Development Kit (JDK). It's used to create and manipulate JAR files. cfm : These are command-line options for the jar tool: c : This option indicates that you want to create a new JAR file. f : This option specifies the JAR file's name, followed by the JAR file's name ( JarFile in your example). m : This option is followed by the manifest file ( ManifestFile in your example). JarFile : This is a placeholder for the name you want to give to your JAR file. You should replace it with the desired name of your JAR file. ManifestFile : This is a placeholder for the name of the manifest file you want to include in the JAR. You should replace it with the actual name of your manifest file. *.class : This is a wildcard that includes all .class files in the current directory in the JAR file.
Remote Method Invocation (RMI) RMI is the action of invoking a method of a remote interface on a remote object. Normally java uses sockets for flexible communication between client and server. For encoding and decoding, it requires application level protocols, for this it needs RPC. RPC is a communication mechanism between functions and not objects. To overcome this object invocation, Java uses RMI.
Facilities of RMI Integration of distributed object model Seamless remote invocation Usage of applets on client side Transparency of invocation between local and remote objects Ease of communication between distributed applications Reliable communication Ease of use
Java and CORBA Java: A versatile, object-oriented programming language known for its platform independence and wide usage in various applications. CORBA (Common Object Request Broker Architecture ): A middleware specification that enables communication between objects in a distributed system, regardless of the programming languages they are written in.
IDL The Interface Definition Language, commonly known as IDL, serves as a bridge that connects various programming languages in a distributed system. Its primary role is to define interfaces for objects, facilitating communication between components written in different languages. IDL acts as a mediator, enabling developers to transcend the language barrier and create interconnected, interoperable systems.
Usage The primary purpose of IDL is to provide a clear and unambiguous definition of the interfaces that objects expose in a distributed environment. This definition is independent of any specific programming language , allowing developers to focus on the functionality of their code. The significance of IDL becomes evident in scenarios where systems are composed of components written in diverse languages, such as Java, C++, or Python.
Key Features of IDL Language Neutrality: IDL allows developers to describe interfaces without tying them to a particular programming language. This neutrality is crucial for promoting interoperability in heterogeneous systems. Abstraction: IDL provides a level of abstraction that separates the interface definition from the implementation details. This abstraction ensures that developers can focus on the functionality of the system without being concerned about the underlying programming language. Data Types: IDL supports a range of data types, including primitive types, structures, and sequences. This flexibility allows developers to model complex data structures and ensure their consistency across different languages.
Applications and Samples CORBA IDL Example: Consider a simple example where we define an interface for a bank account using CORBA IDL. The account has methods to check the balance and withdraw money : // BankAccount.idl module Bank { interface Account { float getBalance (); void withdraw(in float amount); }; };
In this example, module “Bank” encapsulates the interface. interface “Account” defines the methods ‘ getBalance ’ and ‘withdraw’. ‘float’ is a data type representing a floating-point number. ‘in’ indicates that the amount parameter of the withdraw method is an input parameter.
Simple IDL-like description for a web service that provides weather information: // WeatherService.idl interface WeatherService { string getWeather (in string city, in int day); };
ORB Introduction: The complexity of modern software applications often demands a distributed architecture, where components reside on different machines and communicate over a network. However , achieving effective communication in such a heterogeneous environment can be a daunting task. This is where the Object Request Broker comes into play, providing a standardized mechanism for objects to request and receive services from one another in a distributed setting.
Key Concepts of Object Request Broker: Middleware for Object Communication: The ORB acts as middleware, facilitating communication between objects distributed across a network. It abstracts the complexities of network communication, allowing objects to make requests and receive responses without being burdened by the intricacies of low-level network protocols. Interface Definition Language (IDL): The ORB relies on a standardized Interface Definition Language (IDL) to define the interfaces of objects. IDL ensures that objects written in different programming languages can interact seamlessly by providing a common ground for interface specifications. Request and Response Mechanism: The ORB operates on a request-response model. When an object needs a service from another object, it sends a request to the ORB. The ORB then determines the appropriate object to fulfill the request, forwards the request, and returns the response to the requesting object. Location Transparency: One of the key strengths of the ORB is its ability to provide location transparency. Objects interact with each other without being aware of their physical location. This abstraction allows for flexibility in the deployment of distributed systems. Heterogeneous Language Support: The ORB is designed to support objects implemented in different programming languages. This ensures that developers can choose the most suitable language for a specific component without sacrificing interoperability.
The architecture of an Object Request Broker typically involves several key components: ORB Core: At the heart of the ORB is its core, responsible for managing the fundamental aspects of communication, including object location, request dispatching, and response handling. IDL Compiler: The IDL compiler translates interface definitions specified in IDL into language-specific stubs and skeletons. These components play a crucial role in the communication between objects written in different languages. Object Adapter: The Object Adapter is responsible for connecting objects to the ORB. It plays a crucial role in managing the lifecycle of objects, including their activation and deactivation. Protocol Adapters: Protocol adapters handle the conversion of data between the ORB and the underlying network protocols. They ensure that communication is secure and efficient.
Introduction: The System Object Model (SOM) is a framework that provides a standardized approach to building and integrating software components in a distributed environment. Rooted in the principles of object-oriented design, SOM encapsulates the complexity of component interaction, allowing developers to focus on building modular and reusable software.
Key Concepts of System Object Model: Object-Oriented Principles: At the core of SOM is the embrace of object-oriented principles such as encapsulation, inheritance, and polymorphism. These principles provide a foundation for creating modular and extensible software components. Interface-Based Design: SOM adopts an interface-based design, where components expose well-defined interfaces. This ensures that components can interact seamlessly, promoting interoperability across different programming languages and platforms. Dynamic Binding: SOM supports dynamic binding, allowing method calls to be resolved at runtime. This flexibility enables late binding, making it possible to extend and modify the behavior of components without altering their source code. Component Reusability: SOM emphasizes component reusability by providing a framework for developing self-contained, independent components. This modularity facilitates the creation of scalable and maintainable software systems.
Examples of System Object Model in Action: OpenDoc: OpenDoc, an early example of a software framework based on SOM, aimed to create a common container for compound documents. Developers could create reusable components that could seamlessly integrate into various applications, regardless of the programming language they were written in. This exemplified SOM's goal of fostering interoperability and extensibility. Lotus Notes: IBM's Lotus Notes, a collaborative software application, employed SOM to build modular and extensible components. The use of SOM allowed developers to extend the functionality of Lotus Notes through plug-ins and custom components, showcasing the power of the SOM framework in supporting diverse functionalities within a single software ecosystem.
Architecture of System Object Model: Object Managers: SOM introduces the concept of Object Managers, responsible for managing the creation, destruction, and invocation of objects. These managers provide a layer of abstraction, simplifying the process of interacting with objects. Class Libraries: SOM includes class libraries that encapsulate common functionalities and behaviors. Developers can leverage these libraries to build upon existing components, reducing development time and promoting consistency across different applications. Language Neutrality: SOM supports language neutrality, enabling components written in different programming languages to seamlessly interact. This feature is particularly valuable in heterogeneous environments where multiple languages may be employed.
Significance of System Object Model: Interoperability Across Platforms: SOM's focus on interfaces and language neutrality facilitates interoperability across diverse platforms. This is particularly crucial in modern software development, where applications often need to run on different operating systems and devices. Adaptability and Extensibility: SOM's dynamic binding and support for late binding contribute to the adaptability and extensibility of software systems. Developers can introduce new features or modify existing ones without disrupting the overall architecture. Component-Based Development: SOM promotes component-based development, allowing developers to create independent, reusable components. This approach enhances code maintainability, accelerates development cycles, and encourages collaboration across development teams.