The importance of UNIX in SOA environments

These are exciting times in solution architecture—days of Web 2.0, SOA, Web services, mash-ups, and the full integration of technical solutions derived from business models integrating with old and new systems alike. Discover how and why existing systems and applications with which you are already familiar deployed on operating systems that you know well are so critical to the present and future of Web-based computing, particularly in the area of SOA.       These are exciting times in solution architecture . . . that is, if you embrace the challenges of learning and implementing technologies such as Service-Oriented Architecture (SOA), Web services, mash-ups, portals, and the like. For business executives, project managers, sales execs, and various resource managers, SOA and the myriad of new tools and technologies about which you must make immediate business decisions may seem impossible to keep up with. The goal of this article is to explain how and why existing systems and applications with which you are already familiar deployed on operating systems that you know are so critical to the present and future of Web-based computing, particularly in the area of SOA. This article provides: A brief history of the UNIX® operating system in enterprise environments. A high-level overview of the IBM SOA. IBM® SOA solution architecture scenarios. Information about implementation components for SOA in UNIX. The evolution of business and IT As businesses have evolved from mainframe computing to applications built on open standards platforms and from independent, proprietary, and complex enterprise systems to open, integrated, reusable, services-based, platform-independent systems, it's important not only to understand the vague concepts behind such a model but actually see how systems you're familiar with integrate with this modern-day approach to information technology (IT). In addition, it's extremely helpful to see what software is used on what platforms to deliver on SOA's promises. This is where UNIX comes into play. Regardless of what the future may bring—virtualization; complete services-, mash-up-, or portlet-based application front ends with shared computing hosting and database environments—somewhere out there you will still have UNIX servers doing what they do best: providing a reliable operating system to host a variety of Web computing needs. This article's high-level explanation of the history of UNIX servers in the enterprise and how important they are to the SOA puzzle drills into and exposes which technologies are used for each SOA implementation and the platforms on which they perform best.     UNIX in the enterprise environment UNIX was created in the 1970s by AT&T's Bell Laboratories and has gone through design evolutions by both universities and companies. After more than 30 years of use, the UNIX operating system is still regarded as one of the most powerful, versatile, and flexible operating systems in the computer world. Its popularity hinges on its simplicity, open standards design, its ability to run on a wide variety of machines, and its portability. The bottom line is that UNIX was and is a reliable, secure, multi-user operating system that continues to dominate the enterprise Web- and application-hosting landscape. Many large organizations funded UNIX development platforms, and they remain loyal to the platform to this day. This loyalty is to some extent the result of cost and support. Many experts agree that UNIX is the operating system of choice for Web hosting, with the only real alternative being Linux®, which IBM and others now are strongly backing.     Service-Oriented Architecture If you're new to SOA, review the following developerWorks document, New to SOA and Web services. This document accurately explains in great detail the foundation of the five entry points to an SOA system that I summarize below. Entry points Note that these are "technical" executive summaries. They should help the tech-minded readers who get confused with all the SOA jargon when all they really want to know are the technical details of each entry point along with which software you can use to implement these solutions: People: Dynamic portal/portlet front end, proxy, access managers, and process flows. Information: Managing multiple data sources and harvesting business value from the data. Connectivity: Connecting Web services and existing systems through standard protocols, adapters, and buses. Process: Business process modeling and monitoring along with content management and collaboration. Reuse: Integrating existing applications or new Web services. Figure 1 illustrates these SOA entry points. Figure 1. SOA entry points   The IBM SOA solution architecture IBM has made great strides in standardizing a common SOA model to better help IT professionals logically understand the multiple components and layers of a true SOA. In Figure 2, you can see five main top-layer components, with the consumers being the system that needs a service provided by the referenced operational systems. These available services are sometimes defined by the consumer through business process models or straight service naming references and sometimes by the provider. As I show below, most of the time, this process is routed through the Enterprise Service Bus (ESB) at the service components layer. This whole process is governed by security and management layers, which I don't discuss here. Figure 2. IBM SOA solution architecture   As you study the architecture diagrams here, you'll see UNIX-based and UNIX-like (Linux) systems spread through the enterprise. These are labeled with icons representing their corresponding operating systems—a sun for Sun Solaris, a penguin for Linux, and so on. They are at the proxy layer and make up the ESB, and Java™ application servers are also deployed on UNIX systems. Now, you can start to see how UNIX fits in and is a vital part of SOA in most enterprise environments. Although for most server hosting needs you can choose among UNIX, Linux, and Windows, most enterprises use UNIX servers.     IBM SOA solution architecture scenarios Although there are dozens of patterns and scenarios to use as examples, to keep things simple, I visually demonstrate patters that you may have seen previously discussed in other places. The patterns I use are the Direct, Indirect, External Provider, and External Consumer patterns. The diagrams below assume two organizations within a large enterprise, with one as a primary provider and the other a primary consumer. You also see how SOA scenarios would look with external users, systems, or applications needing to reference the provider services. Direct exposure The direct exposure pattern exposes an existing asset as a service with the use of open standards protocols such as SOAP and Web Services Description Language (WSDL). This solution will not likely be aligned with the business processes. As you see in Figure 3, assets are open and directly accessible to the consumer through a Web service. This situation isn't necessarily good, as it takes away from a large part of what SOA is all about—namely, decoupling. In this case, you'll be tied directly to that legacy system or asset. Nonetheless, it is an option that may be available to your organization. Figure 3. The direct SOA pattern   Indirect exposure The indirect exposure pattern connects several existing software functions to realize a service while using a well-planned interoperable service interface solution. This pattern essentially aligns your services with business activities. Based on which application you need to access as defined by your service definition, you can route this request through the local ESB, providing for a true decoupled SOA solution. In this case, systems and applications are sharing data and services within their own organization, as shown in Figure 4. Figure 4. The indirect SOA pattern   External Provider The External Provider pattern demonstrates how to outsource a noncritical business function to a consumer accessing one or more third-party services. The enterprise can share services among different organizations within the enterprise. In this scenario, shown in Figure 5, the consumer has the power, because the solution is based on their service definition and what they need at the time. They may or may not choose to connect to this particular organization's service. This allows great flexibility. Figure 5. The External Provider pattern   External Consumer The External Consumer patterns allows third parties outside the provider governance domain access to services that the provider serves. In this scenario, shown in Figure 6, the provider has the power, because the provider sets the definition of which services are allowed or opened to the outside world. A benefit to this scenario may be that your organization can host services and assets that they can make available to a business partner. Figure 6. The External Consumer SOA pattern   For some reason, sales people and most high-level business decision makers sell the "idea" of SOA very well as a sort of magic concept for integrating business goals with technical solutions by using existing platforms, allowing for future growth by using reusable services. The implementation of such magic is where things get a bit trickier. In all but one of the scenarios you see above, you will be ESB dependent. So, let's take a look at this vital part of the SOA infrastructure and see how UNIX operating systems may be the operating systems of choice for your ESB solution.     Implementation components for SOA in UNIX From my experience and observation, the least-understood facts regarding implementing SOA in the enterprise are: The software or tools needed at each SOA entry point to make the magic happen. The complexity involved in actual integration of all of the services, systems, reusable assets, and applications residing on different platforms using existing or outdated means. Integration in SOA is achieved at the service components layer, with the primary concept or tool being an ESB, as shown in Figure 7. The ESB is a vital piece of your SOA infrastructure, as it provides security and virtualization. Figure 7. The ESB   This particular ESB has a demilitarized zone (DMZ) File Transfer Protocol (FTP) server with a security and virus-checking process to correctly validate data, while a file server helps connect multiple systems by sharing data across a shared storage solution and hosts your file-move software for transferring data off and on IBM® WebSphere® MQ queues. IBM WebSphere Business Integration Message Broker allows for secure routing of messages through Publish and Subscribe definitions. WebSphere MQ is the core product at the heart of the ESB in this scenario. Obstacles One major obstacle you've faced is allowing Windows and UNIX servers to share and manipulate the same data. Data passing from UNIX-based ESB servers to Windows servers is formatted to the UNIX operating system and vice versa, requiring data conversion. Also, I have yet to see a great Network Attached Storage (NAS), Storage Area Network (SAN), or Samba shared-storage solution that easily and reliably shares data between UNIX and Windows servers. In addition, Windows Messaging platforms do not integrate with UNIX-based messaging software solutions such as WebSphere MQ. These are all challenges important to understand. Although SOA by definition means integration of various systems, services, and assets regardless of architecture or platform, it still requires actual software solutions like ESB likely deployed on UNIX-based servers. In addition, UNIX and Linux-based servers have an edge in shared storage solutions and sharing data with existing UNIX-based Web server environments, which still dominate the Web landscape. Although UNIX and Linux are not the only alternatives, it is important to understand their advantages in integrating such typically non-conforming systems. In this, you will see why UNIX or UNIX-like operating systems are still highly needed for the future of the Web-based computing.     Summary My goal in this article was to give you a high-level explanation of where we have come from regarding UNIX-based server environments in our enterprises as well as where we're going in regard to SOA while building a foundation of knowledge about SOA solution patterns and architecture. I even drilled down to specific implementations of such solutions, explaining why UNIX-based systems are beneficial given some of the challenges that we face when given the task of connecting all these services and systems. I hope you now have a decent understanding of where your organization is and where you may be going in relation to SOA and why UNIX-based servers are still critical pieces of the overall puzzle.