Thursday, March 7, 2019

Distributed systems

Today we talking about Distributed Systems,

Distributed computing is a field of computer science that studies distributed systems. A distributed system is a system whose components are located on different networked computers, which communicate and coordinate their actions by passing messages to one another. The components interact with one another in order to achieve a common goal. Three significant characteristics of distributed systems are: concurrency of components, lack of a global clock, and independent failure of components. Examples of distributed systems vary from SOA-based systems to massively multiplayer online games to peer-to-peer applications.

A computer program that runs within a distributed system is called a distributed program (and distributed programming is the process of writing such programs). There are many different types of implementations for the message passing mechanism, including pure HTTP, RPC-like connectors and message queues.

Distributed computing also refers to the use of distributed systems to solve computational problems. In distributed computing, a problem is divided into many tasks, each of which is solved by one or more computers, which communicate with each other via message passing.



distributed-computing: Distributed computing is where multiple computing units are connected to achieve a common task. The larger computing power enables a lot more tasks to be performed than in a single unit, and searches can be coordinated for efficiency. Successes usually give the finder credit.

Distributed computing projects include hunting large prime number, and analysing DNA codes.

distributed-system: A distributed system consists of a collection of autonomous computers, connected through a network and distribution middle-ware, which enables computers to coordinate their activities and to share the resources of the system, so that users perceive the system as a single, integrated computing facility.

An element has a name • Element names are case-sensitive • Element names must start with a letter or underscor e • Element names cannot start with the letters xml Element names can contain letters, digits, hyphens, underscores, and periods • Element names cannot contain spaces • Any name can be used, no words are reserved (except xml).


distributed systems - services are specified through interfaces, which are often described in an Interface Definition Language (IDL).

ØInterface definitions written in an IDL nearly always capture only the syntax of services

specify names of the available functions with types of parameters, return values, possible exceptions that can be raised, etc.
allows an arbitrary process that needs a certain interface to talk to another process that provides that interface allows two independent parties to build completely different implementations of those interfaces, leading to two separate distributed systems that operate in exactly the same way.

Properties of specifications:

· Complete - everything that is necessary to make an implementation has been specified.

· Neutral - specifications do not prescribe what an implementation should look like

Lead to:

·         Interoperability - characterizes the extent by which two implementations of systems or components from different manufacturers can co-exist and work together by merely relying on each other's services as specified by a common standard.

·         Portability - characterizes to what extent an application developed for a distributed system A can be executed, without modification, on a different distributed system B that implements the same interfaces as A.


Goals: an open distributed system should also be extensible.

· be easy to configure the system out of different components (possibly from different developers).

· be easy to add new components or replace existing ones without affecting those components that stay in place.

Distributed Multitiered Applications
The Java EE platform uses a distributed multitiered application model for enterprise applications. Application logic is divided into components according to function, and the various application components that make up a Java EE application are installed on different machines depending on the tier in the multitiered Java EE environment to which the application component belongs.

Figure 1-1 shows two multitiered Java EE applications divided into the tiers described in the following list. The Java EE application parts shown in Figure 1-1 are presented in Java EE Components.

Client-tier components run on the client machine.
Web-tier components run on the Java EE server.
Business-tier components run on the Java EE server.
Enterprise information system (EIS)-tier software runs on the EIS server.

Web-based Information system:

Web-based information system is an information system which uses Internet web technologies for delivering information and services to users. This technology is a software system and is used to publish and maintain data by hypertext principle. Web-based information system is the combination of one or more web applications, specific functionality-oriented components. Basically in this type of information system web browser is used as a front end and all the databases are used as a back end.

Key features of web-based Information System:

Web-based information systems have evolved significantly over recent years with its improvement. Web-based applications have several advantages over traditional software based applications. Some of the core features of web-based applications are given below:

Cross platform compatibility:

Most web-based applications are compatible in different platforms than traditional installed software. The minimum requirement would be a web browser (Internet Explorer, Firefox, Netscape etc.). You can use different OS such as Windows, Linux or Mac to run the web applications.

More Manageable:

WBIS only need to be installed on the server placing minimal requirements on the end user workstation, which makes the system easier to maintain and update as usually it can all be done on the server.

Multiple concurrent users:

Web-based applications can indeed be used by multiple users at the same time. It’s not necessary to share screen or send a screenshot when multiple users see and even edit the same document at the same time. Web conferencing and online collaboration companies regulate some key transformations and users only explore what they really need to work effectively and co-edit documents together.

Reduced cost:
Web-based applications can reduce cost due to support and maintenance, lower requirements on the end user system and simplified architecture. It doesn’t require any distribution or marketing infrastructure.

Secure live data:

These applications can decrease the risk of losing data due to an unexpected disk crash or computer virus. Companies of web-based applications provide extensive data backup service either as an integral part or basic service or sometimes as a paid service.

Social aspects of web-based information system:

In the view of Karl Marx, human beings are intrinsically, necessarily and by definition social beings who – beyond being “gregarious creatures” – cannot survive and meet their needs other than through social co-operation and association. Their social characteristics are therefore to a large extent an objectively given fact, stamped on them from birth and affirmed by socialization processes; and, according to Marx, in producing and reproducing their material life, people must necessarily enter into relations of production which are “independent of their will”.

Social life is affected by web-based information system in different ways. Some of them are given below:

Online community:

An online community is a virtual community which exist online and can take the form of information system where any one can post content by using bulletin board system or weblogs. Online community is used by various social and professional groups interacting via web-based technology. It’s not necessary to have a strong bond among the members. The social network based online community arrived in early 2000s which is called social networking services contains different category divisions to connect with people. Social networking services allow people to create their own profile. Now Facebook and twitter has been using widely worldwide. More than 30 million and 18 million people are using Facebook and twitter respectively at the end of 2009. Myspace and LinkedIn being most widely used in North America. There are many others social networking website such as hi5, LinkedIn, orkut, tagged etc which is using all over the world. Some social networking sites are created for the benefit of others, such as parents social network service “Gurgle which talks about pregnancy, birth and bringing up children. So social networking services are being popular in society day by day.

Educational Institutions:

Now-a-days WBIS is used by most of the educational institutions for communicating with students. Students can find their course material, class schedules or any updated information through the WBIS. This technology has enabled researchers to access a wider source of information though internet. Moreover it is helpful for distance learning.

News & media organizations:

As WBIS is used to store, manipulate, distribute or to create information, news and media organizations are intimately familiar with each of the elements of information technology. This technology helps us to get the updated news from all over the world. We can also get early information about weather and natural disaster, stock exchange, fashion etc. So this technology is playing an important role in our social and day to day life.

Governments:

The development of WBIS has helped the government to improve their service to their citizens. Citizens can get current and accurate government information from e-government websites. Government can publish different types of information through websites such as budget of the country, tourist spots of the country, results of examinations, vigilance information etc. Income tax department is doing online tax accounting for collecting income tax now. So government can get various advantages from WBIS.

Distributed Multitiered Applications
The Java EE platform uses a distributed multitiered application model for enterprise applications. Application logic is divided into components according to function, and the various application components that make up a Java EE application are installed on different machines depending on the tier in the multitiered Java EE environment to which the application component belongs.

Figure 1-1 shows two multitiered Java EE applications divided into the tiers described in the following list. The Java EE application parts shown in Figure 1-1 are presented in Java EE Components.

Client-tier components run on the client machine.

Web-tier components run on the Java EE server.

Business-tier components run on the Java EE server.

Enterprise information system (EIS)-tier software runs on the EIS server.

Although a Java EE application can consist of the three or four tiers shown in Figure 1-1, Java EE multitiered applications are generally considered to be three-tiered applications because they are distributed over three locations: client machines, the Java EE server machine, and the database or legacy machines at the back end. Three-tiered applications that run in this way extend the standard two-tiered client and server model by placing a multithreaded application server between the client application and back-end storage.

Figure 1-1 Multitiered Applications

Diagram of multitiered application structure, including client tier, web tier, business tier, and EIS tier.
Security
While other enterprise application models require platform-specific security measures in each application, the Java EE security environment enables security constraints to be defined at deployment time. The Java EE platform makes applications portable to a wide variety of security implementations by shielding application developers from the complexity of implementing security features.

The Java EE platform provides standard declarative access control rules that are defined by the developer and interpreted when the application is deployed on the server. Java EE also provides standard login mechanisms so application developers do not have to implement these mechanisms in their applications. The same application works in a variety of different security environments without changing the source code.

Java EE Components
Java EE applications are made up of components. A Java EE component is a self-contained functional software unit that is assembled into a Java EE application with its related classes and files and that communicates with other components.

The Java EE specification defines the following Java EE components:

Application clients and applets are components that run on the client.

Java Servlet, JavaServer Faces, and JavaServer Pages (JSP) technology components are web components that run on the server.

Enterprise JavaBeans (EJB) components (enterprise beans) are business components that run on the server.

Java EE components are written in the Java programming language and are compiled in the same way as any program in the language. The difference between Java EE components and “standard” Java classes is that Java EE components are assembled into a Java EE application, are verified to be well formed and in compliance with the Java EE specification, and are deployed to production, where they are run and managed by the Java EE server.

Java EE Clients
A Java EE client can be a web client or an application client.

Web Clients
A web client consists of two parts:dynamic web pages containing various types of markup language (HTML, XML, and so on), which are generated by web components running in the web tier, and a web browser, which renders the pages received from the server.

A web client is sometimes called a thin client. Thin clients usually do not query databases, execute complex business rules, or connect to legacy applications. When you use a thin client, such heavyweight operations are off-loaded to enterprise beans executing on the Java EE server, where they can leverage the security, speed, services, and reliability of Java EE server-side technologies.

Applets
A web page received from the web tier can include an embedded applet. An applet is a small client application written in the Java programming language that executes in the Java virtual machine installed in the web browser. However, client systems will likely need the Java Plug-in and possibly a security policy file for the applet to successfully execute in the web browser.

Web components are the preferred API for creating a web client program because no plug-ins or security policy files are needed on the client systems. Also, web components enable cleaner and more modular application design because they provide a way to separate applications programming from web page design. Personnel involved in web page design thus do not need to understand Java programming language syntax to do their jobs.

Application Clients
An application client runs on a client machine and provides a way for users to handle tasks that require a richer user interface than can be provided by a markup language. It typically has a graphical user interface (GUI) created from the Swing or the Abstract Window Toolkit (AWT) API, but a command-line interface is certainly possible.

Application clients directly access enterprise beans running in the business tier. However, if application requirements warrant it, an application client can open an HTTP connection to establish communication with a servlet running in the web tier. Application clients written in languages other than Java can interact with Java EE 5 servers, enabling the Java EE 5 platform to interoperate with legacy systems, clients, and non-Java languages.

The JavaBeans Component Architecture
The server and client tiers might also include components based on the JavaBeans component architecture (JavaBeans components) to manage the data flow between an application client or applet and components running on the Java EE server, or between server components and a database. JavaBeans components are not considered Java EE components by the Java EE specification.

JavaBeans components have properties and have get and set methods for accessing the properties. JavaBeans components used in this way are typically simple in design and implementation but should conform to the naming and design conventions outlined in the JavaBeans component architecture.

Java EE Server Communications
Figure 1-2 shows the various elements that can make up the client tier. The client communicates with the business tier running on the Java EE server either directly or, as in the case of a client running in a browser, by going through JSP pages or servlets running in the web tier.


Diagram of client-server communication. Application clients access the business tier directly. Browsers, web pages, and applets access the web tier.
Your Java EE application uses a thin browser-based client or thick application client. In deciding which one to use, you should be aware of the trade-offs between keeping functionality on the client and close to the user (thick client) and off-loading as much functionality as possible to the server (thin client). The more functionality you off-load to the server, the easier it is to distribute, deploy, and manage the application; however, keeping more functionality on the client can make for a better perceived user experience.

Web Components
Java EE web components are either servlets or pages created using JSP technology (JSP pages) and/or JavaServer Faces technology. Servlets are Java programming language classes that dynamically process requests and construct responses. JSP pages are text-based documents that execute as servlets but allow a more natural approach to creating static content. JavaServer Faces technology builds on servlets and JSP technology and provides a user interface component framework for web applications.

Static HTML pages and applets are bundled with web components during application assembly but are not considered web components by the Java EE specification. Server-side utility classes can also be bundled with web components and, like HTML pages, are not considered web components.

As shown in Figure 1-3, the web tier, like the client tier, might include a JavaBeans component to manage the user input and send that input to enterprise beans running in the business tier for processing.


Diagram of client-server communication showing detail of JavaBeans components and JSP pages in the web tier.
Business Components
Business code, which is logic that solves or meets the needs of a particular business domain such as banking, retail, or finance, is handled by enterprise beans running in the business tier. Figure 1-4 shows how an enterprise bean receives data from client programs, processes it (if necessary), and sends it to the enterprise information system tier for storage. An enterprise bean also retrieves data from storage, processes it (if necessary), and sends it back to the client program.



Diagram of client-server communication showing detail of entities, session beans, and message-driven beans in the business tier.
Enterprise Information System Tier
The enterprise information system tier handles EIS software and includes enterprise infrastructure systems such as enterprise resource planning (ERP), mainframe transaction processing, database systems, and other legacy information systems. For example, Java EE application components might need access to enterprise information systems for database connectivity.

When developing a server-side application you can start it with a modular hexagonal or layered architecture which consists of different types of components:

Presentation — responsible for handling HTTP requests and responding with either HTML or JSON/XML (for web services APIs).
Business logic — the application’s business logic.
Database access — data access objects responsible for access the database.
Application integration — integration with other services (e.g. via messaging or REST API).

Despite having a logically modular architecture, the application is packaged and deployed as a monolith. Benefits of Monolithic Architecture
#Simple to develop.
#Simple to test. For example you can implement end-to-end testing by simply launching the application and testing the UI with Selenium.
#Simple to deploy. You just have to copy the packaged application to a server.
#Simple to scale horizontally by running multiple copies behind a load balancer.

In the early stages of the project it works well and basically most of the big and successful applications which exist today were started as a monolith.

Drawbacks of Monolithic Architecture
#This simple approach has a limitation in size and complexity.
#Application is too large and complex to fully understand and made changes fast and correctly.
#The size of the application can slow down the start-up time.
#You must redeploy the entire application on each update.
#Impact of a change is usually not very well understood which leads to do extensive manual testing.
#Continuous deployment is difficult.
#Monolithic applications can also be difficult to scale when different modules have conflicting resource requirements.
#Another problem with monolithic applications is reliability. Bug in any module (e.g. memory leak) can potentially bring down the entire process. Moreover, since all instances of the application are identical, that bug will impact the availability of the entire application.
#Monolithic applications has a barrier to adopting new technologies. Since changes in frameworks or languages will affect an entire application it is extremely expensive in both time and cost.

Microservices Architecture
#The idea is to split your application into a set of smaller, interconnected services instead of building a single monolithic application. Each microservice is a small application that has its own hexagonal architecture consisting of business logic along with various adapters. Some microservices would expose a REST, RPC or message-based API and most services consume APIs provided by other services. Other microservices might implement a web UI.

The Microservice architecture pattern significantly impacts the relationship between the application and the database. Instead of sharing a single database schema with other services, each service has its own database schema. On the one hand, this approach is at odds with the idea of an enterprise-wide data model. Also, it often results in duplication of some data. However, having a database schema per service is essential if you want to benefit from microservices, because it ensures loose coupling. Each of the services has its own database. Moreover, a service can use a type of database that is best suited to its needs, the so-called polyglot persistence architecture.

#Some APIs are also exposed to the mobile, desktop, web apps. The apps don’t, however, have direct access to the back-end services. Instead, communication is mediated by an intermediary known as an API Gateway. The API Gateway is responsible for tasks such as load balancing, caching, access control, API metering, and monitoring.


MVC stands for Model–view–controller. It is a software architectural pattern for implementing user interfaces on computers. It divides a given software application into three interconnected parts, so as to separate internal representations of information from the ways that information is presented to or accepted from the user.


Components of MVC

1) Model: It specifies the logical structure of data in a software application and the high-level class associated with it. It is the domain-specific representation of the data which describes the working of an application. When a model changes its state, domain notifies its associated views, so they can refresh.

2) View: View component is used for all the UI logic of the application and these are the components that display the application’s user interface (UI). It renders the model into a form suitable for interaction. Multiple views can exist for a single model for different purposes.

3) Controller: Controllers act as an interface between Model and View components. It processes all the business logic and incoming requests, manipulate data using the Model component, and interact with the Views to render the final output. It receives input and initiates a response by making calls on model objects.


Advantages of MVC

1) Faster development process: MVC supports rapid and parallel development. With MVC, one programmer can work on the view while other can work on the controller to create business logic of the web application. The application developed using MVC can be three times faster than application developed using other development patterns.

2) Ability to provide multiple views: In the MVC Model, you can create multiple views for a model. Code duplication is very limited in MVC because it separates data and business logic from the display.

3) Support for asynchronous technique: MVC also supports asynchronous technique, which helps developers to develop an application that loads very fast.

4) Modification does not affect the entire model: Modification does not affect the entire model because model part does not depend on the views part. Therefore, any changes in the Model will not affect the entire architecture.

5) MVC model returns the data without formatting: MVC pattern returns data without applying any formatting so the same components can be used and called for use with any interface.

6) SEO friendly Development platform: Using this platform, it is very easy to develop SEO-friendly URLs to generate more visits from a specific application.


Disadvantages of MVC

1) Increased complexity
2) Inefficiency of data access in view
3) Difficulty of using MVC with modern user interface.
4) Need multiple programmers
5) Knowledge on multiple technologies is required.
6) Developer have knowledge of client side code and html code.


When to use MVC pattern architecture
 Go to
MVC pattern architecture gives us the idea of separation of concern, it helps us to implement the separation of concern among the model, view and controller classes within applications.

Separation of concern makes it easy for us to test our application as relation among different components of application is clearer and coherent. MVC help us to implement a test-driven development approach, in which we implement automated test cases before we write the code. These unit test cases help us predefine and verify requirements of new code before writing it.

If we are making an application with enough serious stimulating on the client side to refuse to go along with JavaScript alone. If we are developing an application which have a very high lifting on the server side and a little communication on the client side then we should not use the MVC pattern architecture, instead we should use simple setup such as web-based form model. The following are some characteristics that will help us whether to use MVC architecture in our application or not:

i. Our application needs asynchronous communication on the backend.
ii. Our application has a functionality which results in not to reload a full page for example commenting on a post while using Facebook or scrolling infinitely etc.
iii. Manipulation of data is mostly on the client side (browser) rather than server side.
iv. Same type of data is being delivered in different ways on a single page (navigation).
v. When our application has many insignificant connections that are used to modify data (button, switches).

Advantages of MVC architecture

a. MVC architecture helps us to control the complexity of application by dividing it into three components i.e. model, view and controller.
b. MVC does not use server-based forms, that’s why it is ideal for those developers who want full control over their application behavior.
c. Test driven development approach is supported by MVC architecture.
d. MVC use front controller pattern. Front controller pattern handles the multiple incoming requests using single interface (controller). Front controller provides centralized control. We need to configure only one controller in web server instead of many.
e. Front controller provides support rich routing communications to design our web application.

Features of MVC framework

As we divide the logic of our application into three tasks (input logic, business logic, interface logic), testing of these components would become very easy. Testability is very fast and flexible, as we can use any unit testing framework compatible with MVC framework. It is an extensible and pluggable framework. We can design the components of our application in such a way that these are easily replaceable or can be modified easily. We can plug our own view engine, URL routing strategy, action method constraint serialization. Instead of depending on class to create objects we use a technique dependency injection (DI) which enable us to inject object into classes. Another technique inversion of control (IOC) is used to show dependency among objects, it specifies that which object need other which object. MVC provide URL mapping component that helps us to build using understandable and searchable URLs. Instead of using file name extensions MVC support URL naming patterns that are very useful for search engine optimization (SEO) and representational state transfer (REST) addressing. Some frameworks of MVC such as ASP.NET MVC framework provide us some built in features such as form authentication, session management, transactional business logic, web application security, object relational mapping, localization, membership and roles and URL authorization etc. The most popular frameworks available today are backbone.js, ember.js; angular.js and knockout.js.

I. Backbone. Js- Backbone.js framework is useful when our application need flexibility, we have uncertain requirements. Also, we want to accommodate change during application development.
II. Ember.js- When we want that our application should interact with JSON API than we should use ember.js framework in our application.
III. Angular.js- If we want more reliability and stability in our application, we want extensive testing for our application then we should use angular.js framework.
IV. Knockout.js- if we want to make a complex dynamic interface of application then knockout.js framework will be very useful for us.

Each framework has its own advantages and disadvantages. Developers can use any of the frameworks according to his requirements, which suit their web application.

Tools and technologies used with MVC
There are many tools and technologies which can be used to developed web application with the help of MVC architecture. Depending upon the interest of developers, they can use any of the tools and technologies to develop web application. Here are some tools and technologies which can be used to develop web application using MVC architecture:

Tools
Visual Studio: Visual studio is not just only a tool but a complete development environment which provide us facility to create different kinds of application. When we want to develop application using ASP.NET MVC framework then visual studio is very helpful for us.

1) MYSQL Server- relational database management server to maintain the database.
2) SQL Server- a database engine to maintain database just like MYSQL server.
3) MYSQL Workbench- a database design tool.
4) Net Beans- IDE (integrated development Environment) provide complete environment to develop different application.
5) Glassfish Server: Java EE application server.

Technologies
A. HTML, CSS, JQUERY, AJAX for designing
B. Servlet and Java server pages (JSP) used with Net beans
C. EJB (Enterprise Java beans) technologies
D. JSTL (Java server pages standard tag libraries)
E. JPA (Java persistence API)
F. JDBC (Java database connectivity)
G. ASP.NET MVC used with Visual studio


THE WEB HAS RADICALLY TRANSFORMED THE WAY we produce and share information. Its international ecosystem of applications and services allows us to search, aggregate, combine, transform, replicate, cache, and archive the information that underpins today’s digital society. Successful despite its chaotic growth, it is the largest, least formal integration project ever attempted—all of this, despite having barely entered its teenage years.

Today’s Web is in large part the human Web: human users are the direct consumers of the services offered by the majority of today’s web applications. Given its success in managing our digital needs at such phenomenal scale, we’re now starting to ask how we might apply the Web’s underlying architectural principles to building other kinds of distributed systems, particularly the kinds of distributed systems typically implemented by “enterprise application” developers.

Why is the Web such a successful application platform? What are its guiding principles, and how should we apply them when building distributed systems? What technologies can and should we use? Why does the Web model feel familiar, but still different from previous platforms? Conversely, is the Web always the solution to the challenges we face as enterprise application developers?

These are the questions we’ll answer in the rest of this book. Our goal throughout is to describe how to build distributed systems based on the Web’s architecture. We show how to implement systems that use the Web’s predominant application protocol, HyperText Transfer Protocol (HTTP), and which leverage REST’s architectural tenets. We explain the Web’s fundamental principles in simple terms and discuss their relevance in developing robust distributed applications. And we illustrate all this with challenging examples drawn from representative enterprise scenarios and solutions implemented using Java and .NET.

The remainder of this chapter takes a first, high-level look at the Web’s architecture. Here we discuss some key building blocks, touch briefly on the REpresentational State Transfer (REST) architectural style, and explain why the Web can readily be used as a platform for connecting services at global scale. Subsequent chapters dive deeper into the Web’s principles and discuss the technologies available for connecting systems in a web-friendly manner.

Architecture of the Web
Tim Berners-Lee designed and built the foundations of the World Wide Web while a research fellow at CERN in the early 1990s. His motivation was to create an easy-to-use, distributed, loosely coupled system for sharing documents. Rather than starting from traditional distributed application middleware stacks, he opted for a small set of technologies and architectural principles. His approach made it simple to implement applications and author content. At the same time, it enabled the nascent Web to scale and evolve globally. Within a few years of the Web’s birth, academic and research websites had emerged all over the Internet. Shortly thereafter, the business world started establishing a web presence and extracting web-scale profits from its use. Today the Web is a heady mix of business, research, government, social, and individual interests.


Thinking in Resources
Resources are the fundamental building blocks of web-based systems, to the extent that the Web is often referred to as being “resource-oriented.” A resource is anything we expose to the Web, from a document or video clip to a business process or device. From a consumer’s point of view, a resource is anything with which that consumer interacts while progressing toward some goal. Many real-world resources might at first appear impossible to project onto the Web. However, their appearance on the Web is a result of our abstracting out their useful information aspects and presenting these aspects to the digital world. A flesh-and-blood or bricks-and-mortar resource becomes a web resource by the simple act of making the information associated with it accessible on the Web. The generality of the resource concept makes for a heterogeneous community. Almost anything can be modeled as a resource and then made available for manipulation over the network: “Roy’s dissertation,” “the movie Star Wars,” “the invoice for the books Jane just bought,” “Paul’s poker bot,” and “the HR process for dealing with new hires” all happily coexist as resources on the Web.





What is CORBA?
See also: What is Real-time CORBA?

#The Common Object Request Broker Architecture (CORBA) is a standard developed by the Object Management Group (OMG) to provide interoperability among distributed objects. CORBA is the world's leading middleware solution enabling the exchange of information, independent of hardware platforms, programming languages, and operating systems. CORBA is essentially a design specification for an Object Request Broker (ORB), where an ORB provides the mechanism required for distributed objects to communicate with one another, whether locally or on remote devices, written in different languages, or at different locations on a network.

#The CORBA Interface Definition Language, or IDL, allows the development of language and location-independent interfaces to distributed objects. Using CORBA, application components can communicate with one another no matter where they are located, or who has designed them. CORBA provides the location transparency to be able to execute these applications.

#CORBA is often described as a "software bus" because it is a software-based communications interface through which objects are located and accessed. The illustration below identifies the primary components seen within a CORBA implementation.

CORBA Implementation



Data communication from client to server is accomplished through a well-defined object-oriented interface. The Object Request Broker (ORB) determines the location of the target object, sends a request to that object, and returns any response back to the caller. Through this object-oriented technology, developers can take advantage of features such as inheritance, encapsulation, polymorphism, and runtime dynamic binding. These features allow applications to be changed, modified and re-used with minimal changes to the parent interface. The illustration below identifies how a client sends a request to a server through the ORB:

Client Sending Request to Server Through ORB










Interface Definition Language (IDL)
#A cornerstone of the CORBA standards is the Interface Definition Language. IDL is the OMG standard for defining language-neutral APIs and provides the platform-independent delineation of the interfaces of distributed objects. The ability of the CORBA environments to provide consistency between clients and servers in heterogeneous environments begins with a standardized definition of the data and operations constituting the client/server interface. This standardization mechanism is the IDL, and is used by CORBA to describe the interfaces of objects.

IDL defines the modules, interfaces and operations for the applications and is not considered a programming language. The various programming languages, such as Ada, C++, or Java, supply the implementation of the interface via standardized IDL mappings.

Application Development Using ORBexpress
#The basic steps for CORBA development can be seen in the illustration below. This illustration provides an overview of how the IDL is translated to the corresponding language (in this example, C++), mapped to the source code, compiled, and then linked with the ORB library, resulting in the client and server implementation.

Application Development Using ORBexpress

The basic steps for CORBA development include:

#Create the IDL to Define the Application Interfaces
The IDL provides the operating system and programming language independent interfaces to all services and components that are linked to the ORB. The IDL specifies a description of any services a server component exposes to the client. The term "IDL Compiler" is often used, but the IDL is actually translated into a programming language.

#Translate the IDL
An IDL translator typically generates two cooperative parts for the client and server implementation, stub code and skeleton code. The stub code generated for the interface classes is associated with a client application and provides the user with a well-defined Application Programming Interface (API). In this example, the IDL is translated into C++.

#Compile the Interface Files
Once the IDL is translated into the appropriate language, C++ in this example, these interface files are compiled and prepared for the object implementation.

#Complete the Implementation
If the implementation classes are incomplete, the spec and header files and complete bodies and definitions need to be modified before passing through to be compiled. The output is a complete client/server implementation.

#Compile the Implementation
Once the implementation class is complete, the client interfaces are ready to be used in the client application and can be immediately incorporated into the client process. This client process is responsible for obtaining an object reference to a specific object, allowing the client to make requests to that object in the form of a method call on its generated API.

#Link the Application
Once all the object code from steps three and five have been compiled, the object implementation classes need to be linked to the C++ linker. Once linked to the ORB library, in this example, ORBexpress, two executable operations are created, one for the client and one for the server.

#Run the Client and Server
The development process is now complete and the client will now communicate with the server. The server uses the object implementation classes allowing it to communicate with the objects created by the client requests.

In its simplest form, the server must perform the following:

  • Create the required objects.
  • Notify the CORBA environment that it is ready to receive client requests.
  • Process client requests by dispatching the appropriate servant.


CORBA Programming Definitions
Within a CORBA development process, there are a number of unique terms specific to a CORBA implementation. Developers may find our Glossary of Terms helpful in understanding a full CORBA implementation.

#Interoperability
The first version of CORBA provided the IDL and standard mappings to just a few languages, and as the CORBA standard has matured, CORBA 2.0 added more language bindings (particularly C++ and Java) as well as General Inter-ORB Protocol (GIOP). When a client calls a CORBA operation, the client ORB sends a GIOP message to the server. The server ORB converts this request into a call on the server object and then returns the results in a GIOP reply. This standard transfer syntax, specified by the Object Management Group, allows the interoperability of ORB-to-ORB interaction and is designed to work over any transport protocol meeting a minimal set of assumptions.

When GIOP is sent over TCP/IP, it is called Internet Inter ORB Protocol (IIOP). IIOP is designed to allow different ORB vendors to interoperate with one another. An example of this interoperability occurs when there is communication between an enterprise designed ORB, and a smaller real-time application, utilizing a real-time ORB.

#Object Management Group (OMG)
The OMG is a non-profit consortium created in 1989 to promote the theory and practice of object technology for the development for distributed operating systems. The goal is to provide a common architectural framework for object-oriented applications based on widely available interface specifications. With a membership of over 800 members, representing large and small companies within the computer industry, OMG leads the specification development efforts of CORBA, OMG IDL, IIOP, OMA, UML, MOF, and CWM specifications.

The OMG does not produce software or implementation guidelines, only the specifications to which OMG members respond to in Request For Information (RFI) and Requests for Proposals (RFP). By managing these specifications, the OMG supports the adoption process for the member companies interested in advancing the uses and applications of distributed object-oriented computing.

XML stands for Extensible Markup Language. It is a text-based markup language derived from Standard Generalized Markup Language (SGML).

XML tags identify the data and are used to store and organize the data, rather than specifying how to display it like HTML tags, which are used to display the data. XML is not going to replace HTML in the near future, but it introduces new possibilities by adopting many successful features of HTML.

#There are three important characteristics of XML that make it useful in a variety of systems and solutions −

  • XML is extensible − XML allows you to create your own self-descriptive tags, or language, that suits your application.
  • XML carries the data, does not present it − XML allows you to store the data irrespective of how it will be presented.
  • XML is a public standard − XML was developed by an organization called the World Wide Web Consortium (W3C) and is available as an open standard.



#Tags and Elements
An XML file is structured by several XML-elements, also called XML-nodes or XML-tags. The names of XML-elements are enclosed in triangular brackets < > as shown below −

<element>

#Syntax Rules for Tags and Elements
Element Syntax − Each XML-element needs to be closed either with start or with end elements as shown below −

<element>....</element>
or in simple-cases, just this way −

<element/>

#Nesting of Elements − An XML-element can contain multiple XML-elements as its children, but the children elements must not overlap. i.e., an end tag of an element must have the same name as that of the most recent unmatched start tag.

The Following example shows incorrect nested tags −

<?xml version = "1.0"?>
<contact-info>
<company>TutorialsPoint
<contact-info>
</company>
The Following example shows correct nested tags −

<?xml version = "1.0"?>
<contact-info>
   <company>TutorialsPoint</company>
<contact-info>

#Root Element − An XML document can have only one root element. For example, following is not a correct XML document, because both the x and y elements occur at the top level without a root element −

<x>...</x>
<y>...</y>
The Following example shows a correctly formed XML document −

<root>
   <x>...</x>
   <y>...</y>
</root>


#Case Sensitivity − The names of XML-elements are case-sensitive. That means the name of the start and the end elements need to be exactly in the same case.


##The Pros And Cons Of XML
XML is a long-established language that still holds pertinence today. Several older technologies you perceive on the market employ it. Therefore, if you need to manage an API that’s been around for over ten years, the likelihood that you’ll need to work with XML remains high. Older APIs don’t provide you a choice in the format that you may employ.

XML is beneficial when you possess abundant amounts of properties, procedures, and attributes that you require to implant into one record. Assume you possess a file that delineates an object, and you have to construe that object’s attributes within the data set. You may deploy XML, and it’s ‘HTML-like’ syntax to parse every property and attribute implanted within the record.

You cannot escape XML if you decide to use XSLT. Although sporadically utilized today, XSLT continues to reside in various front-end web design projects. XSLT is a markup that interprets the attributes of an XML record and converts it to a layout for users to absorb. You can compare XSLT to CSS for HTML scripts. CSS communicates to the browser how to design and display an HTML document to the user whereas XSLT explains the way the user should perceive an XML document.

Another benefit is that XML readers parse and validate an XML message. Provided that it’s incorrectly formatted, the developer encounters an error message. This alert assists the developer to evade poorly structured XML that results in ‘cluttered’ presentation of data. Since the message can be denied and sent back to the user, data is continually guaranteed to hold the correct structure when you work with API systems.

Another justification you require XML is if you use third-party APIs to produce data in your system. If they don’t present a way to transmit and receive messages in JSON, then you’re compelled to work with XML whether you like to or not. You may still work with JSON in your internal applications. However, alternating between JSON and XML can be dull and build additional overhead in your programming that isn’t essential.

In general, XML is still a genuine language for developers who have considerable volumes of data with numerous attributes to transfer between API messages. Nevertheless, the majority of developers dislike working with it since the format is complex and adds to the overhead for data processing.



##The Pros And Cons Of JSON
When coders lost enthusiasm in XML, JSON became the format of choice for transmitting messages across platforms. Both JSON and XML are platform independent. However, JSON is a considerably plainer language than XML. For this reason, JSON possesses some benefits over employing XML when you construct an API.

Since JSON is simple, it renders it more straightforward to parse. You don’t need to possess all of the tags and attributes of XML. Therefore, it’s awesome when you hold uncomplicated data objects that you require to transmit between two platforms. For example, if you solely require to shift a customer object with all of it’s associated data, then JSON permits you to structure your object in a format that is simple to read and effortless to pinpoint errors.

One concern surrounding JSON is that formatting errors aren’t validated. This renders it arduous to guarantee that users transmit the correct data to your API. Several languages hold predefined classes and modules that render it effortless to serialize and deserialize JSON data. Conceive of this procedure as a way to package a message and withdraw it inside your application. Complicated structures like XML are challenging to package whereas JSON is considerably simpler for both developers and the fundamental modules that work with the data.

Numerous APIs utilize JSON, however, it’s also a newer format than XML. If you’re constructing a new API, you ought to work with JSON unless you possess complicated data structures. All developers that work with your API will assume that JSON is the default since it has emerged as a standard in the industry. If you construct a new API with XML, the developers might not be enticed to yours over your competitors. Remember that enticing the developers to an API is how technological corporations expand their fascination in software products.

If you require a way to format JSON, you have to deploy your own parsing and design tools. JSON doesn’t contain a design language the way XML has XSLT. You may load JSON data into particular design components sold by third-parties, but you will have to take considerable data sets and show them in a browser.


1. Browsers
Browsers are the interpreters of the web. They request information and then when they receive it, they show us on the page in a format we can see and understand.

Google Chrome - Currently, the most popular browser brought to you by Google

Safari - Apple’s web browser

Firefox - Open-source browser supported by the Mozilla Foundation

Internet Explorer - Microsoft’s browser. You will most often hear web developers complain about this one.

2. HTML
HTML is a markup language. It provides the structure of a website so that web browsers know what to show.

3. CSS
CSS is a Cascading Style Sheet. CSS let’s web designers change colors, fonts, animations, and transitions on the web. They make the web look good.

LESS - a CSS pre-compiler to make working with CSS easier and add functionality

SASS - a CSS pre-compiler to make working with CSS easier and add functionality

4. Programming Languages
Programming languages are ways to communicate to computers and tell them what to do. There are many different programming languages just like there are many different lingual languages (English, Spanish, French, Chinese, etc). One is not better than the other. Developers typically are just proficient at a couple so they promote those more than others. Below are just some of the languages and links to their homepages

Javascript - used by all web browsers, Meteor, and lots of other frameworks

Coffeescript - is a kind of “dialect” of javascript. It is viewed as simpler and easier on your eyes as a developer but it complies (converts) back into javascript

Python -used by the Django framework and used in a lot of mathematical calculations

Ruby - used by the Ruby on Rails framework

PHP - used by Wordpress

Go - newer language, built for speed.

Objective-C - the programming language behind iOS (your iPhone), lead by Apple

Swift - Apple’s newest programming language

Java - Used by Android (Google) and a lot of desktop applications.

5. Frameworks
Frameworks are built to make building and working with programming languages easier. Frameworks typically take all the difficult, repetitive tasks in setting up a new web application and either does them for you or make them very easy for you to do.

Meteor - a full-stack (front and back end) javascript framework
Node.js - a server-side javascript framework
Ruby on Rails - a full-stack framework built using ruby
Django - a full-stack framework built using python
Ionic - a mobile framework
Phonegap / Cordova - a mobile framework that exposes native api’s of iOS and Android for use when writing javascript
Bootstrap - a UI (user interface) framework for building with HTML/CSS/Javascript
Foundation - a UI framework for building with HTML/CSS/Javascript
Wordpress - a CMS (content management system) built on PHP. Currently, about 20% of all websites run on this framework
Drupal - a CMS framework built using PHP.

.NET - a full-stack framework built by Microsoft
Angular.js - a front-end javascript framework.
Ember.js - a front-end javascript framework.
Backbone.js - a front-end javascript framework.
6. Libraries 
Libraries are groupings of code snippets to enable a large amount of functionality without having to write it all by yourself. Libraries typically also go through the trouble to make sure the code is efficient and works well across browsers and devices (not always the case, but typically they do).

jQuery

Underscore

7. Databases
Databases are where all your data is stored. It’s like a bunch of filing cabinets with folders filled with files. Databases come mainly in two flavors: SQL and NoSQL. SQL provides more structure which helps with making sure all the data is correct and validated. NoSQL provides a lot of flexibility for building and maintaining applications.

MongoDB - is an open-sourced NoSQL database and is currently the only database supported by Meteor.

Redis - is the most popular key-value store. It is lighting fast for retrieving data but doesn’t allow for much depth in the data storage.

  • PostgreSQL - is a popular open-sourced SQL database.
  • MySQL - is another popular open-sourced SQL database. MySQL is used in Wordpress websites.
  • Oracle - is an enterprise SQL database.


SQL Server - is an SQL server manager created by Microsoft.

8. Client (or Client-side)
A client is one user of an application. It’s you and me when we visit http://google.com. Client’s can be desktop computers, tablets, or mobile devices. There are typically multiple clients interacting with the same application stored on a server.

9. Server (or Server-side)
A server is where the application code is typically stored. Requests are made to the server from clients, and the server will gather the appropriate information and respond to those requests.

10. Front-end
The front-end is comprised of HTML, CSS, and Javascript. This is how and where the website is shown to users.

11. Back-end
The back-end is comprised of your server and database. It’s the place where functions, methods, and data manipulation happens that you don’t want the clients to see.

12. Protocols
Protocols are standardized instructions for how to pass information back and forth between computers and devices.

HTTP - This protocol is how each website gets to your browser. Whenever you type a website like “http://google.com” this protocol requests the website from google’s server and then receives a response with the HTML, CSS, and javascript of the website.

DDP - is a new protocol created in connection with Meteor. The DDP protocol uses websockets to create a consistent connection between the client and the server. This constant connection lets websites and data on those websites update in real-time without refreshing your browser.

REST - is a protocol mainly used for API’s. It has standard methods like GET, POST, and PUT that let information be exchanged between applications.

13. API
An API is an application programming interface. It is created by the developer of an application to allow other developers to use some of the application’s functionality without sharing code. Developers expose “end points” which are like inputs and outputs of the application. Using an API can control access with API keys. Examples of good API’s are those created by Facebook, Twitter, and Google for their web services.

14. Data formats
Data formats are the structure of how data is stored.

  • JSON - is quickly becoming the most popular data format
  • XML - was the main data format early in the web days and predominantly used by Microsoft systems
  • CSV - is data formatted by commas. Excel data is typically formatted this way.











No comments:

Post a Comment

Client Side Development 2- RIWAs

                   A rich Internet application (RIA) is a web application that is designed to deliver the same features and features tha...