Unveiling the Enigmatic World of Proxies: Gatekeepers of Access and Control

In the intricate dance of software architecture, there arises a need for gatekeepers—entities that control access to coveted objects. Imagine a scenario where only specific methods of hefty, resource-intensive objects are required. Here, proxies step into the limelight, donning the role of light objects that mimic the heavyweights until the precise moment when their grand entrance is required.

The Dance of Proxies:

Proxies, in this digital ballet, serve as the intermediaries between the user and the resource. They masquerade as the real deal, exposing the same interface as the heavyweight objects but biding their time until the curtain call. The magic happens when, at the opportune moment, proxies summon the actual resource, sparing us the cost and resources until absolutely necessary.

The Tapestry of Control:

Why do we yearn for this control over object access? Picture this—sometimes, the instantiation and initialization of a resource-intensive object are akin to raising the curtains on a grand performance. We desire the ability to dictate when that performance commences, and proxies grant us that control. Moreover, access rights become a nuanced dance, with proxies choreographing who gets to waltz in and partake in the spectacle.

The Symphony of Proxy Servers:

Extend this concept to the vast landscape of computer networks, and you encounter the maestros of access control—the proxy servers. These servers waltz between clients and servers, intercepting requests and orchestrating a seamless exchange of resources. It's a ballet of efficiency, ensuring that clients receive what they seek while maintaining a delicate balance of control.

Examples Unveiled:

Let's bring this concept to life with tangible examples. In the clandestine realm of internet privacy, proxies play the role of concealers. Consider Tor, where the client's IP address is veiled, hidden behind the graceful movements of a proxy. It's a dance of anonymity, a tango of hidden identities.

Now, imagine a bustling internet landscape where speed is of the essence. Proxies emerge as accelerators, speeding up the ballet of internet surfing. They cache resources, minimize latency, and ensure a swift performance, akin to a well-practiced routine that leaves the audience (users) in awe.

Conclusion:

As the curtains draw to a close on our exploration of proxies, we unveil a world where control, access, and anonymity intertwine in a mesmerizing dance. Proxies, whether orchestrating the instantiation of objects or gracefully pirouetting through the digital realm, are the unsung heroes of software choreography. They embody the essence of control, offering a symphony of solutions to the multifaceted challenges in the realm of software architecture.

Remote Procedure Call (RPC)

Remote Procedure Call (RPC) is a protocol that one program can use to request a service from a program located in another computer on a network without having to understand the network's details. A procedure call is also sometimes known as a function call or a subroutine call.

RPC uses the client-server model. The requesting program is a client and the service-providing program is the server. Like a regular or local procedure call, an RPC is a synchronous operation requiring the requesting program to be suspended until the results of the remote procedure are returned. However, the use of lightweight processes or threads that share the same address space allows multiple RPCs to be performed concurrently.

When program statements that use the RPC framework are compiled into an executable program, a stub is included in the compiled code that acts as the representative of the remote procedure code. When the program is run and the procedure call is issued, the stub receives the request and forwards it to a client runtime program on the local computer.

Unraveling the Tapestry of Middleware: The Silent Maestro of Software Communication

In the intricate symphony of software architecture, a silent maestro conducts the harmonious communication between an operating system and the applications gracing its realm. This enigmatic conductor is none other than middleware—a covert force that enables seamless data management and communication for distributed applications. Picture it as the unassuming bridge connecting the ethereal world of applications and the underlying operating system.

The Dance of Translation:

Middleware operates like a hidden translation layer, decoding the complex language of applications and orchestrating a fluent exchange with the operating system. Its prowess lies in facilitating communication between disparate components, ensuring a smooth and synchronized performance. In essence, middleware is the linguistic virtuoso that translates the unique dialects of applications into a universal language understood by the operating system.

Plumbing the Software Landscape:

Often referred to as "plumbing," middleware plays the role of the unsung hero connecting two applications seamlessly, creating a conduit through which data and databases can flow effortlessly. Like the hidden passages in an intricate architectural marvel, middleware forms the backbone of software communication, making the exchange of information as fluid as water through a pipe.

Use Case Ballet:

Imagine a scenario where users interact with a web browser, submitting forms, and expecting a responsive dance of data. This is where middleware takes the center stage. It facilitates requests, allowing users to seamlessly submit forms or enabling dynamic web pages to pirouette onto a user's profile. Middleware is the choreographer of these intricate movements, ensuring a flawless performance in the user experience ballet.

Example Extravaganza:

Middleware comes in various forms, each playing a distinct role in the grand production of software communication. Enter the stage with database middleware, gracefully managing the interactions between databases and applications. Applaud the application server middleware, orchestrating the dynamic performance of applications. Witness the elegance of message-oriented middleware, the web middleware's swift choreography, and the transaction processing monitors ensuring a seamless financial pas de deux.

Conclusion:

As the curtains fall on our exploration of middleware, we unveil a silent maestro orchestrating the intricate ballet of software communication. From decoding the languages of applications to seamlessly connecting their performances, middleware stands as the unseen force ensuring a harmonious symphony in the digital realm. It's the plumbing, the translator, and the choreographer—all rolled into one—a testament to the nuanced dance that is software architecture.

Marshalling

Marshaling is the process of transforming the memory representation of an object to a data format that could be stored or transmitted. It's also called "serialization".

In a very generic sense in programming it simply means taking data in one format and transforming it into a format that is acceptable by some other system.

It is typically used when data must be moved between different parts of a computer program or from one program to another.

Used Case of marshaling:
Remote procedure call uses marshaling quite clearly. When invoking remote functions you will have to Marshall the arguments to some kind of standard format so it can be transport across the network.

WSDL Elements

The WSDL file itself can look very complex to any user, but it contains all the necessary information that any client application would require to use the relevant web service.

Below is the general structure of a WSDL file:

• Definition
• TargetNamespace
• DataTypes
• Messages
• Porttype
• Bindings
• service

One key thing to note here is that definition of messages, which is what is passed by the SOAP protocol is actually defined in the WSDL document.

The WSDL document actually tells a client application what are the types of SOAP messages which are sent and accepted by the Web service.

In other words, the WSDL is just like a postcard which has the address of a particular location. The address provides the details of the person who delivered the postcard. Hence, in the same way, the WSDL file is the postcard, which has the address of the web service which can deliver all the functionality that the client wants.

WSDL Elements

The WSDL file contains the following main parts

1. The <types> tag is used to define all the complex datatypes, which will be used in the message exchanged between the client application and the web service. This is an important aspect of the client application, because if the web service works with a complex data type, then the client application should know how to process the complex data type. Data types such as float, numbers, and strings are all simple data types, but there could be structured data types which may be provided by the web service.
   For example, there could be a data type called EmployeeDataType which could have 2 elements called "EmployeeName" of type string and "EmployeeID" of type number or integer. Together they form a data structure which then becomes a complex data type.
2. The <messages> tag is used to define the message which is exchanged between the client application and the web server. These messages will explain the input and output operations which can be performed by the web service. An example of a message can be a message which accepts the EmployeeID of an employee, and the output message can be the name of the employee based on the EmpoyeeID provided.
3. The <portType> tag is used to encapsulate every input and output message into one logical operation. So there could be an operation called "GetEmployee" which combines the input message of accepting the EmployeeID from a client application and then sending the EmployeeName as the output message.
4. The <binding> tag is used to bind the operation to the particular port type. This is so that when the client application calls the relevant port type, it will then be able to access the operations which are bound to this port type. Port types are just like interfaces. So if a client application needs to use a web service they need to use the binding information to ensure that they can connect to the interface provided by that web service.
5. The <service> tag is a name given to the web service itself. Initially, when a client application makes a call to the web service, it will do by calling the name of the web service. For example, a web service can be located at an address such as http://localhost/tajul7777/blog.xml. The service tag will actually have the URL defined as  http://localhost/tajul7777/blog.xml., which will actually tell the client application that there is a web service available at this location.

Why WSDL file?

We already know that WSDL is an XML standard document, is used to describe a web service. This description is required so that the client applications are able to understand what the web service  actually does.

WSDL describes: 

• How to call a web service (Using SOAP or HTTP protocol) 
• All the available operations which are exposed by the web service and their input and output structures. 
• Location of the web service or we can say the end point of the web service (Location where the service is running)

The WSDL file itself can look very complex to any user but it contain all the necessary information that any client application would require to use the relevant web service.

Why WSDL File?

The WSDL file is written in plain XML. So that the file can be read  by any programming language. But now with the WSDL file which is an XML , which can be understand by any programming language, we can now easily have a Java class consume the .NET , SAP, Python web service and vice versa. Hence the amount of coding effort is greatly reduced.

Uniform Addressing

Uniform Resource Identifier (URI) generic terms for all textual names and addresses. A URI can be a URL or URN or URC.

A uniform resource identifier is a string of characters that unambiguously identifies a particular resource. To guarantee uniformity, all URIs follow a predefined set of syntax rules, but also maintain extensibility through a separately defined hierarchical naming scheme (e.g. http://).

Such identification enables interaction with representations of the resource over a Network, typically the world wide web using specific protocols. Schemes specifying a concrete syntax and associated protocols define each URI. 

The most common form of URI is the uniform resource locator (URL) frequently referred to informally as a web address. More rarely seen in usage is the uniform resource name (URN) which was designed to complement URLs by providing a mechanism for the identification of resources in particular namespaces.

Uniform Resource Name (URN) a URI that has an institutional commitment to availability. A particular scheme intended to identify resources.  

A Uniform Resource Name (URN) is a URI that identifies a resource by name in a particular namespace. A URN may be used to talk about a resource without implying its location or how to access it. For example, in the International Standard Book Number (ISBN) system, ISBN 0-486-27557-4 identifies a specific edition of Shakespeare's play Romeo and Juliet. The URN for that edition would be urn:isbn:0-486-27557-4. However, it gives no information as to where to find a copy of that book.

Uniform Resource Locator (URL) the set of URI schemes that have explicit instructions on how to access the resource over the internet. 

A Uniform Resource Locator (URL) is a URI that specifies the means of acting upon or obtaining the representation of a resource, i.e. specifying both its primary access mechanism and network location. For example, the URL http://example.org/wiki/Main_Page refers to a resource identified as /wiki/Main_Page, whose representation, in the form of HTML and related code, is obtainable via the Hypertext Transfer Protocol (http:) from a network host whose domain name is example.org.

A URN may be compared to a person's name, while a URL may be compared to their street address. In other words, a URN identifies an item and a URL provides a method for finding it.

Uniform Resource Characteristic (URC) provides meta information

What Is WSDL?

Web Services Description Language (WSDL)

To consume a web service from a web service provider a service consumer needs to know:

                                        

                         1. What are the services available?

                         2. What are the request and response parameters?

                         3. How to call web service?

To Enable this every service provider publishes an interface for his web services that describes all attributes of the web services. This is an XML based interface and it's known as WSDL.