Middleware analysts are computer software engineers with a specialization in products that connect two different computer systems together. These products can be open-source or proprietary. As the term implies, the software, tools, and technologies used by Middleware analysts sit "in-the-middle", between two or more systems; the purpose being to enable two systems to communicate and share information.
Middleware analysts[1] look at the system of systems.[2] They solve technical problems which involve large scale inter-disciplinary objectives with multiple, heterogeneous, distributed systems that are embedded in networks at multiple levels.[3] Middleware analysts hold and maintain proficiency in middleware technologies. Middleware is computer software that connects software components or applications. A central theme in most middleware analyst roles is being able to articulate why Service Oriented Architecture (SOA) is important to the business.[4]
Middleware best practices promote usability and maintainability among the systems served. A few examples of best practices are included here to provide some insight as to how middleware addresses key principles of standards-based computing. One common problem for middleware is the manner in which user-defined applications are configured so that queue references bypass queue alias definitions referring directly to the queue local or queue remote definition. Such a bypass of queue alias deviates best practices and should be corrected when the administrator and/or programmer can correct it within time and scope parameters. All references from user-defined applications should point to queue aliases. Then the queue aliases should point to the defined queue local or queue remote. Queue aliases[5] allow flexibility for middleware administrators to resolve or relieve production problems quickly. By using queue aliases, middleware administrators can redirect message flow, in the event of a service problem, without changes to the user-defined application. For example, if a queue local were overflowing, a middleware admin could change the queue alias to point to a temporary queue local, thereby allowing the user-defined application to continue its processing without interruption while the underlying root cause is corrected. By pointing all user-defined application references to queue aliases, it preserves the flexibility that middleware admins would have to help with production issues that may occur. If the best practice of queue aliases were not followed, the ability of a middleware admin to help with a production outage would be hindered.
Message queuing (“MQ”) is a middleware technology that greatly simplifies communication between the nodes of a system and between the nodes that connect systems together. Information system consultants use message queuing as their skill base. Upon this base, information system consultants add workflow management, message brokering, and J2EE implementations using java virtual machines (JVMs) and Message Driven Beans (MDBs).
Arguably the most important skill a middleware analyst uses is not technical, it is surely cultural. SOA does require people to think of business and technology differently. Instead of thinking of technology first, middleware analysts must first think in terms of business functions, or services. It is expected that adoption of SOA will change business IT departments, creating service-oriented (instead of technology-oriented) IT organizations. Middleware analysts perform crucial evangelization of this concept.
The enterprise service bus is a core element of any SOA. ESBs provide the "any to any" connectivity between services within a company, and beyond that company to connect to the company's trading partners. Therefore, middleware analysts need to be skilled in SOA and enterprise service bus concepts first and foremost. Middleware analysts rely on an SOA reference architecture to lay out an SOA environment that meets the company's needs and priorities. The ESB is part of this reference architecture and provides the backbone of an SOA but is not considered an SOA by itself.
Because middleware is a cross-platform tool, the sophistication of your middleware analysts are expected to be acute. People that are designing and implementing the middleware message flow need to fully understand how the security model on each target platform works. This may include Windows, Unix, z/OS or IBM i. Middleware protects data in transit through PKI and SSL technology. Security certificates are procured from a certification authority and regularly deployed and updated on servers. This protects data while it is in transit as it leaves one Server and arrives on the next server in the chain. It does not protect data while data is at rest. Supplemental transmission security can augment the primary SSL measures that exist on your server. These are SSL client authentication, DN filtering, CRL check by LDAP, and cryptographic hardware (IPSEC-level encryption). This type of security is called "border-level security" because it only protects the data from when it leaves your borders until it gets to your trading partner's borders. It does not protect data once data has entered the border. IPSEC is the most efficient and least costly protection method. SSL is the middle ground, with a balance between flexibility, resource consumption, and transmission time. When data is at rest in queues, it is not protected by MQ. That is, data is in "plain text". Therefore, if the data contained in messages is sensitive, then it is essential that application-level data encryption be used. Examples of data which could be protected by this strategy include banking data (account numbers, banking transactions, etc.) Application-level transaction security is the most secure form of protection but also the most costly in terms of CPU and I/O bandwidth consumption of both the sending and receiving servers. It is also the least efficient. Middleware data channels can be set up to provide varying degrees of protection. A sender/receiver channel pair could be configured to provide IPSEC transport-level security not using SSL. A second sender/receiver pair could be configured to provide SSL border-to-border level security not using IPSEC. A third sender/receiver channel pair could be set up to provide application-level encryption. Using this scheme, you provision a wide selection of protection mechanisms from which your applications can choose at runtime. This offers applications the ability to achieve best security when needed or more efficient security when data is not quite so sensitive.
If your enterprise handles HIPAA ePHI data, then your middleware analysts need to know and understand the requirements set forth by law.[6] Failure to protect data at-rest may subject your organization to fines and penalties levied by the Federal government or other authority.[7] This requires application-level data encryption prior to delivering the data to the queuing system for transport.[8]
System administrators, including middleware analysts, are not permitted to view unprotected ePHI data. Therefore, whenever ePHI data is present in any information system, it must be protected from the ability of an administrator to view it. It is not permissible to allow ePHI data to be kept in a queue unprotected.