Darren Wesemann Blog

In a recent customer presentation, I had a slide up on the wall showing the CSA in the middle (sort of a hub-looking thing) with spokes coming out of it representing various SunGard application components. I generally use the slide (as I was doing at that time) to show that application parts, when following the same standards, can communicate with each other in a composite solution without necessarily knowing which components would be integrated together at the time each component is constructed (if you’ve seen my CSA presentation, you’ll likely remember the diagram I’m referring to).

An IT guy in the room asked if the graphic could be interpreted from a production perspective as a ‘Hub-and-Spoke’ runtime environment. I answered that SunGard Composite Solutions powered by the CSA are distributed runtime environments (more in line with agile system, SOA, asynchronous messaging, etc…) as opposed to the models associated with older attempts, which run counter to today’s agility goal. In other words, the runtime environment is not Hub-and-Spoke. This particular customer had been investing in getting away from a Hub-and-Spoke “attempt” at a universal IT infrastructure for a over a year, however we reminisced about the original virtues of the promise of what Hub-and-Spoke runtime environments claimed (the hype), although there is a place for this paradigm, it certainly doesn’t belong as a core strategy. There is “control” with Hub-and-Spoke, simplicity and lower overhead in managing the centralized paradigm. There is also the ability to standardize data elements and other items among applications and data sources, with a centralized model. Perhaps there is middle-ground somewhere … is it possible to enjoy the low-overhead and centralized control of a Hub-and-Spoke paradigm while fully leveraging distributed, loose-coupling, agile composite solutions? I think so; I’ll explain how I proposed the SunGard CSA Composite Solutions can offer the best of both worlds to this customer in the context of his inquiry regarding my Hub-and-Spoke diagram.

I recounted the historical perspective from CORBA to EAI to SOA, (I spent five years as a member of the OMG, collaborating on things like CORBA, UML and MDA), in order to shed some light on attempts at supporting dynamic service relationships between various parts of IT infrastructure, and SunGard’s work in all of the above over the years. The forerunners to SOA (CORBA, DCOM, etc.) force rigidity, proprietary languages, object models, tight coupling, and so forth. However, the SOA paradigm owes a lot to the work done in those early distributed computing years. Many of the popular SOA standards parallel things the CORBA introduced. Further, some SOA parts lag in areas CORBA was very advanced in (for example, Web Services aren’t as robust with performance and transaction processing as CORBA was/is, which some ESB vendors are trying to correct). Although, the general IT populous is heading for a different level of distributed computing than CORBA envisioned. SOA describes a network of independent, reusable services that may be discovered and accessed according to open Web standards. We didn’t know what the web was when CORBA began, at least in today’s terms. We were concerned primarily with getting rid of the redundant effort of remotely calling a function on a heterogeneous system by building the communication protocol and defining bit formats for accommodating the call. CORBA brought us IIOP, an efficient universal protocol for remotely communicating, but with it came inflexibilities not realized at the time, (because of all that IIOP was saving us, it was hard to complain about areas that would eventually be perfected by the proliferation of the Web).

Further, in the pre-Web days, EAI appeared as an alternative to the point-to-point and custom-programmed communication to access information with routines of code that had plagued organizations. The EAI approach was even more explicitly Hub-and-Spoke than the CORBA ORB in that there was centralized data transformation, adapters, security and routines/functions. The hub communicated with object-based adaptors, which wrapped legacy applications so they could communicate by sending/receiving data routed through the hub from other applications. EAI provided a much-hyped vision of application integration moved out of ad hoc plumbing to a more abstract level, where developers could focus on implementing component and object models. With this paradigm, EAI technologies assisted with the move to Model Driven Architecture (MDA, another OMG thing, I left the OMG shortly after MDA was ratified), in which developers were allowed to focus on implementing components through modeling, leveraging the UML (yet another OMG thing), allowing applications to work together without having to share network protocols or other specifics at the lower levels. EAI vendors implemented the CORBA specification originally to enable standard interoperability among distributed computing nodes in a Hub-and-Spoke fashion. CORBA and DCOM systems supported exclusively object-oriented RPC communications, (which is similar to how SOAP uses XML over HTTP and other IP protocols), with an interface definition language (similar to WSDL), where the interface wad defined to enable interaction within the ORB middleware. The primary form of early middleware communication was synchronous RPC, which was highly coupled, so requesting and responding entities must be in lock-step to avoid interface mismatches and breakdowns. Then came the asynchronous message and event-based computing technologies, which allowed for more flexibility. Still the Hub-and-Spoke paradigm existed, because the early approach was to use “adaptors” that would send and receive messages (called “events”) to and from a central broker that managed queuing, filtering, delivery and security. Systems scaled by adding more brokers. Around that time, the OMG defined an asynchronous messaging service for CORBA, however the proprietary nature of most CORBA implementations made heterogeneous computing tough. The Hub-and-Spoke relationships among servers had to be tightly coupled point-to-point connections between interfaces. That’s where Web Services came in, in order to solve the scaling problem of gazillions of unknown clients (the Web model) trying to communicate with servers over the Internet.

The centralized hub approach and the slower nature of MDA development methods associated with CORBA and EAI are abrasive to the agility sought after by most organizations today. CORBA has not incorporated XML in a straight forward manner. SOAP, WSDL, etc… gained momentum due to XML’s capability as a data-distribution middleware alternative to CORBA, which is why XML thrives in the Agile Methodology for development and rejects the older waterfall techniques of yesterday. Enter the ESB, or the Enterprise Service Bus, which leverages a message-oriented middleware paradigm, leveraging queues as its means of organizing and prioritizing data and content communications and passing state between distributed components in a loosely coupled fashion. This is where true event-based systems come alive, which rely on the ESB to serve as the backbone from which the system listens for events or state changes in subscribing applications and uses process intelligence to determine what to do next.

At the end of the day, IT professionals (such as the customer I was in discussions with on this topic referred to above) are looking to preserve certain “centralized” benefits through the Hub-and-Spoke model and at the same time they need the agility offered by asynchronous messaging or event-based models. The CSA approach to this need provides centralization for administrative functions common to all areas of the IT infrastructure in a single location, (such as identity management, user administration, security and entitlement manipulation, etc.) and yet all of the application components run on distributed computing resources for both scaling purposes, and most importantly, legacy leverage and integration purposes. The CSA bus capability allows for the distribution of the computing resources, while the core CSA components provide for a central location for administration and other common functions. At the end of the day, the CSA doesn’t care if the bus is communicating with a database over JDBC, or a service over SOAP/HTTP or SOAP/JMS or XML/JMS… etc. all it cares about is that the SunGard application components are agnostic to the runtime distributed complexities, allowing for centralization where Hub-and-Spoke is needed and distribution where agility and legacy leverage is required. The runtime environment should dictate the particular configuration, not develop-time choices made far in advance of the installation. This is the CSA-way, the best of both worlds.

The principles of commonality and variation are well defined in a thesis paper by James Coplien “Multi-Paradigm Design”, (can be downloaded from: http://prog.vub.ac.be/Publications/2000/vub-prog-phd-00-01.pdf also described in his book: “Multi-Paradigm Design for C++”, published by Addison-Wesley in October of 1998 [Coplien1999], the thesis paper is essentially the book). These principles are fundamental to SunGard’s success with the CSA, and are relevant to software architecture as well as product management going forward.

As I’ve discussed in earlier blogs, the CSA uses abstraction heavily in order to make sense of the various elements and concepts found in our myriad of architectures at SunGard. Coplien’s paper addresses abstraction techniques in terms of commonality and variation since complexity and problem definition are key issues in software work today. For example, grouping is a useful technique in abstracting similar concepts. Procedures or methods form out of grouping steps of an algorithm by their relationships, and responsibilities of an encapsulated collection of related data are grouped to form classes.

Coplien’s design approach uses analyses of both the application and solution domains in parallel. It provides techniques in finding solution domain constructs that most naturally express the structure of the application domain. It seeks a match between commonalities and variabilities of the solution domain with those of the application domain to understand what solution techniques to apply to which parts of the problem, and then builds taxonomies of solution domain constructs which describe commonalities and variabilities in code using the most appropriate paradigms (classes, templates, services, modules, ordinary procedural programming, etc.), languages, objects, etc.

In summary, Coplien says that Commonality defines families (via grouping), and families are the primary basis for abstraction. Commonalities can then be expressed in a programming language (capable of multiple paradigms). Then, an analysis of how similar items differ, which yields huge abstracting power by parameterizing the variabilities of a domain.

Without spoiling too much of the fun, I’ll differ the punch lines to the paper itself. I’ll defer to the paper and recommend to the reader to download the thesis or buy the book referred to above and get familiar with these techniques. Although the constructs used in the paper are based in C++, the techniques are very applicable to Java and C# and other languages.