The Question:
Why should Network-Attached Storage (NAS) solutions not be used to do enterprise application integration (EAI)?
I am asking this question from my role as solutions architect. In that role it is my task to help "the business" understand their needs and then advise that business on the most sensible way of meeting these needs. Currently, I believe that connecting two (or more) Enterprise Applications (applications from here on) by using a NAS is not sensible. However, I keep seeing that new NAS based integrations are being implemented. Apparently, there is this myth that it is sensible to deploy NAS based EAI. So I decided to see if I could bust that myth by logic.
Ideally, when application X needs to have a task performed that it can't or should better not do itself, it outsources the task to a contractor. It shouldn't have to care about the type and whereabouts of that contractor. The contractor should just be able to perform the task needed with the agreed Quality of Service (QoS). The contractor itself might subcontract yet other contractors for parts of the task, but application X doesn't know and care as long as the QoS is met. All nice and clean and transparent.
A popular way of integrating applications in that ideal manner is by means of middleware. It has more or less become the default way of application integration. Extremely simply put, middleware is a generic and elastic glue for fixing together applications from different vendors, running on heterogeneous systems (hardware + operating system). Middleware provides the service of matchmaking between clients and servers. Clients require specific services from servers. A service is defined by a formal interface which is the contract both client and server are held by. Middleware provides for dependability by making cross application operations atomic so they can be rolled back when something goes wrong. The elastic properties of middleware allow for flexible and transparent scaling of systems to meet changing QoS requirements. Transparency, dependability and scalability. Well designed integration architecture deploys these properties to increase overall robustness and future stability.
I am thoroughly convinced of the value of middleware. It is a very sensible and proven way of doing EAI. I don't know any better, because I have been brain washed to believe that ever since I graduated. My premise is that NAS based EAI is not sensible. So I need to assess whether a NAS can provide properties of middleware I value most: transparency, dependability and scalability.
The basic purpose of a NAS is to provide file storage and make stored files accessible through the network by means of an operating system level file sharing protocol. So, applications can use it to store files, share files, and retrieve stored or shared files. An application X that needs a service from a contractor could simply store a "job" in a designated folder (OUT) on the NAS and wait until a result is delivered in another folder (IN) on the NAS. The job contains all the information the contractor needs to decide whether it should perform the required task and all information needed for performing the required task, including the terms of service (QoS). Application X does not need to know the performer of the job nor about the inner workings of that performer, assuming the job description adheres to a standard, cross-application format supported by multiple vendors. That is a big assumption.
To scale things up you could line up multiple contractors that actively watch the OUT folders. However, a NAS does not provide an intelligent way of balancing the load between multiple contractors. It also provides no protection for race conditions nor does it provide an integrated means for making cross application operations atomic. The verdict:
transparency: plausible
scalability: busted
dependability: busted
Overall conclusion: Myth busted
Why should Network-Attached Storage (NAS) solutions not be used to do enterprise application integration (EAI)?
I am asking this question from my role as solutions architect. In that role it is my task to help "the business" understand their needs and then advise that business on the most sensible way of meeting these needs. Currently, I believe that connecting two (or more) Enterprise Applications (applications from here on) by using a NAS is not sensible. However, I keep seeing that new NAS based integrations are being implemented. Apparently, there is this myth that it is sensible to deploy NAS based EAI. So I decided to see if I could bust that myth by logic.
Ideally, when application X needs to have a task performed that it can't or should better not do itself, it outsources the task to a contractor. It shouldn't have to care about the type and whereabouts of that contractor. The contractor should just be able to perform the task needed with the agreed Quality of Service (QoS). The contractor itself might subcontract yet other contractors for parts of the task, but application X doesn't know and care as long as the QoS is met. All nice and clean and transparent.
A popular way of integrating applications in that ideal manner is by means of middleware. It has more or less become the default way of application integration. Extremely simply put, middleware is a generic and elastic glue for fixing together applications from different vendors, running on heterogeneous systems (hardware + operating system). Middleware provides the service of matchmaking between clients and servers. Clients require specific services from servers. A service is defined by a formal interface which is the contract both client and server are held by. Middleware provides for dependability by making cross application operations atomic so they can be rolled back when something goes wrong. The elastic properties of middleware allow for flexible and transparent scaling of systems to meet changing QoS requirements. Transparency, dependability and scalability. Well designed integration architecture deploys these properties to increase overall robustness and future stability.
I am thoroughly convinced of the value of middleware. It is a very sensible and proven way of doing EAI. I don't know any better, because I have been brain washed to believe that ever since I graduated. My premise is that NAS based EAI is not sensible. So I need to assess whether a NAS can provide properties of middleware I value most: transparency, dependability and scalability.
The basic purpose of a NAS is to provide file storage and make stored files accessible through the network by means of an operating system level file sharing protocol. So, applications can use it to store files, share files, and retrieve stored or shared files. An application X that needs a service from a contractor could simply store a "job" in a designated folder (OUT) on the NAS and wait until a result is delivered in another folder (IN) on the NAS. The job contains all the information the contractor needs to decide whether it should perform the required task and all information needed for performing the required task, including the terms of service (QoS). Application X does not need to know the performer of the job nor about the inner workings of that performer, assuming the job description adheres to a standard, cross-application format supported by multiple vendors. That is a big assumption.
To scale things up you could line up multiple contractors that actively watch the OUT folders. However, a NAS does not provide an intelligent way of balancing the load between multiple contractors. It also provides no protection for race conditions nor does it provide an integrated means for making cross application operations atomic. The verdict:
transparency: plausible
scalability: busted
dependability: busted
Overall conclusion: Myth busted
Powered by ScribeFire.
