Mashups: New and Agile way to Integrate

I came across this interesting post: How Mashups Could Eliminate Integration Projects by Loraine Lawson. In a related post, she refers to John Crupi’s article Enterprise Mashups Part I: Bringing SOA to the People which I would recommend to readers who want to understand JackBe’s take on defining mashups. Anyway, Loraine’s post led me to Ron Schmelzer’s ZapFlash.

Here are some excerpts of Ron’s article that caught my eye, with my take on it:

A year or two ago, assuming that a mashup was a web browser-based, static, user interface composition of web-based functionality would be a reasonable presumption. But in the enterprise context, none of those assumptions necessarily hold – we might want non-Web access to mashed applications, we might want to change them regularly, and we might want to mash up information that exists below the user interface abstraction. For sure, Web mashups might embody the ideals of the original mashup concept, but we now have the desire to mash up a wide variety of IT resources from application to infrastructure to data that might be exposed with a wide range of interfaces – or without. And, it’s the desire to mash up information freed from the application that diversifies the mashup term to include the concept of the data mashup.

Introducing the Mashup Tier
Introducing the Mashup Tier

My take: This hits the point right on what we at JackBe have been saying all along about mashups. While some mashups are done purely in the UI/Browser, in the enterprise, such mashups need to be supported by a new tier, the mashup tier, which sits between the presentation and business tier. So enterprise mashups will have some mashing done in the client, but most of the mashing happens in server side where security, governance, policies can be applied before any mashing can happen in the client.

Another excerpt:

There are many scenarios for composing data, but some are better suited for static, tightly-coupled, IT-driven, non-Service Oriented form. In fact, 80% of the value that businesses derive from data come from the 20% of fixed, highly optimized data integration approaches implemented over decades. In this realm, traditional data integration approaches retain high value. However, it’s the other 80% of data integration requirements, most of which come from the need to meet short-term, often ad hoc, integration requests that cause 80% of the problems. Anyone who has lived long enough in the enterprise IT space knows that business-driven requests for reporting, forecasting, analysis, or other interpretations of data can present significant complications and cost to the IT organization. The reason for this is that the IT organization is set up to meet the recurring needs of the business and not “situational” needs for information.

Long Tail of Enterprise Software Demand
Long Tail of Enterprise Software Demand

My take: This highlights another issue which we have been talking about at JackBe about the long tail & enterprise applications need which was so nicely discussed here by Dion Hinchcliffe.

Bottom line: Something new and interesting is happening in the enterprise architecture space. A new flexible and agile tier is being introduced in the architecture to meet the increasing demand on IT and  add value to existing architecture, applications, services and data. Question is, are you embracing this inevitable change? If not, it’s still not too late. 🙂

SOA Patterns?

Dave Linthicum writes about why patterns can be key to SOA solutions. Being a patterns enthusiast and practitioner, I agree with what’s been said in spirit. But, having been through the process of identifying and documenting the enterprise Java patterns, I am cringing at one thought he expressed there of creating a database of SOA patterns. I am afraid that I don’t buy this approach entirely. Such a database is going to cause more problems than solve anything.

Patterns don’t live in isolation, they really create a network amongst them (of inter-relationships) that increases the value of the set of patterns as a whole. A single pattern itself, while useful, has limited applicability. Whereas with a set of patterns and relationships, you can start understanding the key pattern heuristics and eventually lead to a pattern language, which is the ultimate goal of any patterns practitioner. This was the hardest part of pattern discovery in our (me, Dan & John) enterprise patterns work, where you can see one such example of pattern relationships (and here) to help you better understand the community of patterns, rather than just a single pattern.

For an example of a patterns database, take a look at the Server Side patterns database, while commendable and has incredible participation, the patterns submitted there lack such a language of relationships and thereby exist at multiple levels of abstraction which do not inter-relate very well.

Remembering John Vlissides

I am deeply saddened to hear that John Vlissides passed away during thanksgiving after a long battle with an illness (see here and here). I had the pleasure and good fortune of meeting him once and only once at OOPSLA a couple of years ago. I now recall how I was struck by his modesty and friendliness. He was a great author, contributor and an overall very nice guy. He will greatly missed by the community.
Read anecdotes and memories and even share yours on WikiWikiWeb here (See http://c2.com/cgi/wiki?JohnVlissides).

YouRIt

Patterns & Platforms: Deprecated Patterns?


Let's say you have used a pattern many times in your implementations. And then
one day something new comes along and you no longer need to implement that old
pattern anymore. So what happens to that pattern? Does it get deprecated? I
have come across this question many times while talking to other developers.

For instance, this question of pattern deprecation is associated with some
patterns we documented in Core J2EE
Patterns
. We first released these patterns in the 1st edition. And when
newer version of J2EE/EJB/Servlet specifications became available, these patterns
gained direct support in the underlying platform. The questions related to a
few of the J2EE patterns are:

  • Did Intercepting Filter pattern get deprecated since Servlet version 2.3 specification introduced an new Filter component ?
  • Is Composite Entity pattern no longer applicable since EJB 2.0 introduced local EJBs?
  • Is Service Activator pattern deprecated since EJB version 2.0 introduced Message Driven Beans (MDB)?

IMO, patterns do not get deprecated. In these cases above, the patterns were absorbed and supported into the relevant specifications. This makes the platform better because it is providing built-in support for well known patterns. So as platforms mature, some platform patterns can get assimilated into the platform as a process of improvement.

This process however does not diminish the value of those patterns. Instead the forces around the patterns can change a bit leading to new solutions and strategies for implementing the pattern in the new platform. This is what happened to some patterns in Core J2EE Patterns. As J2EE evolved, the strategies we describe for these patterns also evolved. I look at this as a process of symbiosis and maturation between patterns and platforms.

YouRIt:

To Control or To Filter ? Why not both?

Question: Should I use Intercepting Filter or Front Controller?

Short answer is: use both. Intercepting Filter and Front Controller are typically used in combination. IMO, the real question is how to separate the concerns of each in my web application.

This is a common question I encounter.
Sometimes, when I need to implement a request/response handling functionality in the presentation tier,
choosing between processing in Intercepting Filter and Front Controller becomes a matter of preference. Both patterns offer a way to centralize control of request/response processing. However, there are some key differences in how you assign responsibilities to each.

  • I use Intercepting Filter when I want loosely-coupled pre and post processors for request/response handling.
    Intercepting Filters offer pluggability and configurability so that I can add/remove filters non-intrusively (declaratively). Filters are ideal if the operations they perform are well-encapsulated and discrete so that I can plug and play as I want.
  • For all other common request processing, a Front Controller is the way to go for me. Front Controller avoids duplication of code in multiple views. Typically, once I implement a Front Controller, I pretty much want to leave it alone as much as possible. Over time, if I start seeing lots of conditional switching (if-then-else or case/switch) in my Front Controller, then I might refactor conditional logic using Intercepting Filters or delegate the conditional processing to helpers using the Command and Controller Strategy [see Front Controller pattern] implementing a Command [GoF] based services layer.

Bottomline: I want my Front Controllers to be straightforward, simple and easy to maintain, and my Intercepting Filters to be loosely-coupled, pluggable and stateless.

What do you think?

How I Use Patterns…

If you are new to software patterns, you might be wondering how to use them. In any case, I would love to hear back from you on how you find patterns useful (or not) depending on your experience. Anyway, based on my experience, I see 3 broad categories of pattern usage.

  1. Building a new system

    If you are developing a new system, patterns help you to layout the design blueprint for the system. You can design the system using well-known patterns and help your team understand your design rapidly by documenting and explaining your design with patterns. Assuming that the patterns you use are well understood by your team members, you spend very little or no time in explaining the nitty-gritty details that can be encapsulated by each pattern. If someone is not familiar with a pattern that you are using, you simply point them to the pattern documentation and they would quickly get up to speed on it. Patterns streamline the design communication within your team and help your team to focus on the design and implementation instead of arguing about the fine-grained implementation choices underneath. Once you agree upon the overall design and the choice of patterns, you then get on with choosing the right strategies for implementing the design. Remember, there is not one way to implement a pattern. Multiple implementations (or solutions) for a pattern are described as discrete implementation strategies you get to choose and implement after choosing the pattern.
  2. Understanding an existing system

    If you begin working with an alien system, the first (and hardest) thing to do is to comprehend the system design and architecture. Patterns help you in understanding such systems. You can use your patterns experience to drill down, identify and decompose the system design into comprehensible pieces that can be mapped to well-known patterns. In my job as a consultant, this is what I do. I end up mapping the system back into patterns by investigating the code, design documentations (if I am lucky to find one) and talking to other developers who might have worked with or have some knowledge of system. This helps me to capture and share the design information of the system and to focus on those areas I don't understand well (i.e. those areas that do not easily map to well-known patterns). Understanding a system is essential to managing, maintaining, refactoring and enhancing it confidently and patterns can help you to get there.
  3. Refactoring a system

    This depends on the above point on understanding a system. Once you understand a system and map the system back to well-known patterns, refactoring becomes easier. You can identify the impact of refactoring by looking at the patterns and their inter-connections. Refactoring may involve such activities as changing a pattern strategy (i.e. same pattern, different implementation), swapping patterns (replace one pattern with another), or introducing a new pattern. Patterns become the targets to which we refactor a system. So there too, patterns provide me a better way to improve my refactoring. In my experience as a consultant to many customers, this benefit of patterns alone has proven to be of great value to perform my job efficiently and with the highest quality.

Useful References

Patterns: Aha! …or… Duh!

I hear from other developers all the time about how they feel that design patterns are over-hyped and not really useful. For example, recently I was talking to an aquaintance Bob (not his real name), who works for a hugely well-known company.
We were talking about some programming stuff, and as it happens, soon wandered into the world of patterns.
Bob said to me that when he first read the GoF book, he felt that there was nothing new in it. He had already implemented those patterns and had reused them over and over in his designs. So, he said, “What is the big deal with patterns? I did not learn anything new!”

In my experience, this sentiment is pretty common among us developers. I, and my co-authors, received similar feedback during the early days of our work on Core J2EE Patterns. I said to him “Bob, it is great that you had implemented those patterns in the GoF book before it was published. But the very fact that you, me and others like us have repeatedly implemented them proves that those patterns are indeed patterns! And that's the whole point about patterns.”

Documenting recurring designs helps us to communicate with other developers. Patterns provide a great mechanism to document and share reusable problem/solution pairs. Patterns also provide a powerful design vocabulary so everyone on the team can talk the same talk and understand each other. This increases productivity and decreases noise and ambiguity in our design discussions. The benefit of such a vocabulary in design is often an overlooked benefit of using patterns in our day to day work.

In the GoF book, they talk about an Aha! experience – when one understands the patterns and gains new insights. I think the experience I have encountered from other developers is a bit different, one that I call the Duh! effect, as in “Duh! I knew that already.” As a pattern practitioner, when I hear the Duh! effect, I no longer have to prove that patterns are useful and that a pattern is a pattern.

Duh! = Game over!