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.