Mike Ogrinz

Author
+ Follow
since Apr 09, 2009
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Mike Ogrinz

I wanted to thank everyone for their questions this week. I hope you found my responses helpful and that you'll keep an eye on this space. Even if you aren't actively planning on building mashups, I suspect you will find the concepts becoming more prevalent over the next several years of our professional careers.

Finally, I wanted to say "Thanks" to everyone over the years who have keep this an active community. I've actually been a "lurker" here many times. I can't count how often I Google for a quick answer to a Java question and the results point me here. I hope my posts this week even out my karma for all the good information I've gotten from JavaRanch in the past

I'm always available at mashuppatterns.com or mike@mashuppatterns.com if you want to continue the conversation.

Kind regards,
Mike
There aren't any full-blown open source mashup tools that I think really are practical in an enterprise environment right now. I attribute this to a few things:
1) Most mashup tools have a fairly sophisticated UI. In my general experience, many open source developers avoid this type of work
2) There aren't any real standards yet. Open source works great when the have a commercial product to model it after (heck, even Linux started this way).
3) There are already open tools and APIs for building simple mashups *outside* the enterprise... Most open source developers start with a desire to build something for themselves, not the corporate world.
4) A general lack of understanding of the potential of mashups is keeping them "low profile"

Those things said, I do expect this to change. Particularly if JackBe's EMML (Enterprise Mashup Markup Language) takes off. With a standard in place, I could see multiple projects kicking off to let you build/manipulate EMML in different ways. And maybe the vendors would all converge on it. JackBe is also trying to form an independent association among the vendors to drive this kind of consistency. In the end, I think it could be a great benefit for everyone.

As Chris points out, there are commercial products you can try for little or no cost. And there's also WS02, who say they have an open source mashup server. I don't know if they have any front-end tooling; I haven't used their product. I wanted to include them in my book, but their product was so new they didn't have any case studies as of a few months ago.
Ah.. we finally get down to the real issue: cost ;-) Let me start with your second question first:

The patterns in the book cover a wide variety of use cases. I doubt a single firm would leverage every single one of them, but if you press me for an answer I think they would probably need at least 2 different products from the pool currently available.

First, you'd need something that could harvest data from unstructured sources. This would mostly likely be a Kapow, OpenSpan, or Convertigo. Second, you'd need a tool to allow people to assemble the harvested information into widgets or portals. This would probably be a JackBe or IBM Mashup Center. Convertigo and -to a slightly less extent- Connotate are two products that could work in both camps.

What I think is most likely is that a firm would go after a subset of patterns, and pick the product best suited to them (and then products like Denodo, Serena, etc which shine in certain areas come into play)

Cost? Sigh - I go back and forth with the vendors over this. I think they need to make their products more affordable. Generally, we are talking in the $40k-75k range for an enterprise license. Of course, these are hard times, and you can definitely cut special deals by reducing the # of seats for example. I've gotten some good discounts for my firm. And, most companies will give you dev seats for free. For example, you can download JackBe's tooling and play around with it right from their site.
IBM also has a way for you to experiment with their tool in their "greenhouse". And Kapow has http://openkapow.com which will give you a partial glimpse into a portion of their tooling. Sites like Dapper are free, but you really need to bring the tooling behind the firewall to fully appreciate the benefits.



I am naturally very cynical ;-) I regularly get hit up by vendors with some new product or technology that seems like a re-hash of something I saw a decade ago. It's like, "Don't they realize this has been tried/done before? Are they either a) unaware or b) trying to pull the wool over my eyes?"

Mashups were the first new concept in some time to really get me excited. The idea of composite applications, etc isn't particularly new, but mashups seem to have burst onto the scene just as people were wondering what the payoff of SOA was going to be. And I love the "innovation without permission" angle. Not that I'm saying governance and control aren't important. It's just that after years of failed promises about empowering developers and power-users, we finally seem to be getting somewhere. I think partly it's because the tools have reached a certain level of maturity/capability, but also because users have become more technically savvy as well.

I hope you'll explore mashups and get charged up too!
Hey Cameron,

Typically, mashups involve SOAP or REST APIs, so they aren't Java-specific. In fact, they can combine resources build in Java, .NET, PHP, etc. Frequently, the "glue" that pulls all of these together for a web-based mashup is actually JavaScript.

However, sometimes we start off with closed applications that don't have an API. We need to use a tool to impose our own interface to get to the data. Recently, I've been using Kapow a lot for this. It creates an API against a closed web site, excel spreadsheet, pdf doc, and other stuff. In Kapow, you can spit out a web service interface, an RSS feed, or -cool part- a native .NET object or a POJO (plain old Java object).

For example, recently I wanted to create an API against our corporate directory. I used Kapow to spit out a POJO that gives me a clean and simple way to add phone # lookups to any of my Java apps (web, swing, or otherwise).

As a Java developer, imagine being able to get to almost any resource (especially, but not limited to, the web-based ones!) inside your company without needing access to the source code! I was able to complete my simple phone lookup work without getting access to their database and even though they had no published interface. Underneath my super-simple Java object Kapow's mashup server was interacting with their web app and providing the functionality I needed. It gets really cool when you start joining multiple web resources together, and still exposing them as that same, simple API.

For my next trick, I decided that when I couldn't find a name in the corporate directory, I would look it up on whitepages.com. I changed my mashup in Kapow to add this additional step and redeployed it to their mashup server. Since the interface on my Java object didn't change, I didn't even need to recompile. Poof! My application was automatically showing the phone numbers of non-employees (contractors and consultants) automatically.

Once you realize what you can do with these things, your mind will explode in a hundred different directions.
John,

Each pattern has a Fragility section associated with it. At this point, I strongly argue against mashups of "time-critical, real-time servers & systems" (there's your Aha moment ;-)) Any system can break. The code can be perfect, but the network can drop out, disk fill up, bad RAM, etc. But mashups can be more vulnerable, because they rely on the SLAs (service level agreements) of multiple systems.

However, there is a "Fragility Reducer" pattern that discusses using mashups to add redundancy where little or none currently exists. This can shore up an existing system or mashup to make it more reliable. Still; if I had to make a general recommendation, it would be to avoid mashups for critical functionality. That's where you may want to go with more traditional development techniques.

BTW, the patterns are intended to be independent of web services. Some tools (notably OpenSpan) even let you create mashups against windows desktop applications by natively hooking into the Windows API. Cool stuff.
Heh. I know Raymond Yee; we both contribute to ProgrammableWeb on occasion.

Raymond's book focuses on mashups *outside* the enterprise, and typically just the very limited are of taking existing public APIs from sites like Google and flickr and combining them together. If you want to learn about basic API wiring stuff, this is a good resource.

My book attempts to codify all of the things mashups are actually capable of. Many people don't even realize these capabilities are available today, let alone that mashups are the enabler.

For example, what if I told you you could:
-Modify the user interface of an application, without needing the original developers? (Usability Enhancer pattern)
-Fix a vendor's bug without access to the source code (Field Medic pattern)
-Add tagging to a system that doesnt natively support it (Folksonomy Enabler pattern)
-Add an API to a "closed" application (API Enabler pattern)
-Port an app to the iPhone without changing the source code (Accessibility pattern)

Imagine being able to take all of the legacy apps your firm has, and giving them all RSS capability (Feed Factory pattern) without needing to find the original developers or source code? Maybe it's a vendor product and you don't even have access! Mashups (and the empowering tools) make this possible. This is not the focus of Raymond's book. In fact, there is no other material out there that even begins to address the solution patterns specific to mashup technology.

The goal of my book isn't to give you the javascript to put nearby ATM machines on a Google map.. it's to open the minds of enterprise developers to the incredible possibilities that now exist for creating, enhancing, and fixing software. And best of all - in some cases we can even give this power to end-users.

If you read just one of the patterns and think, "I never knew you could do that!" then I'll feel I accomplished my mission.

I wish someone would build for mashups what's out there for wikis at http://www.wikimatrix.org/. In fact, I thought about it but someone is already squatting on mashupmatrix.org

Dion Hinchcliffe's article you mention is a good start, but a little dated. There are so many tools know it seems I learn about a different one each day. Just off the top of my head there's

JackBe, Denodo, Kapow, IBM Mashup Center, OpenSpan, Convertigo, Connotate, Serena, Lansa, Chickenfoot, WSO2, MindTouch, Dapper...

Dion includes some stuff in the RSS space which I'm skipping - but I include some stuff in the browser (chickenfoot) and wiki spaces (MindTouch).

The only way to really compare them is to put some thought into what you want to do (<plug>which my book hopefully helps you to do</plug>).

To illustrate some of the differences...
Need to mashup data coming from mainframes? Lansa or Convertigo are where to look..
Want to API-enable a clsoed web source? Most likely Kapow, OpenSpan, or Convertigo
Want to mashup various workflow-centric problems? Serena shines in this area
Want to give end-users the ability to build their own mashups? JackBe and IBM are probably the best tools to look at
Data mashups your bag? Denodo
Need to give end-users the ability to mark up web pages, hand them off to IT, and get solutions back? This is something interesting that Connotate does

As you can see, no particular tool does it all. I like the idea of starting with the Patterns you want to implement, and then backing into the right tools afterwards. Someone once came up to me and announced they were doing a pilot with vendor product X. Then I asked.. "What problem are you hoping to solve?" From their answer, it was clear they chose incorrectly. That's the danger when you start with tools first, and problems second.

How many of us just decided to learn Java for the heck of it, and how many did so b/c they had a problem to solve first?
Hi John,

We have to be a little careful here, because there are EII (Enterprise Information Integration) and EAI (Enterprise Application Integration) tools that overlap with mashups in this space. That's why Anthony Bradley denies the existence of the data mashup here (see my rebuttals after his post).

Many of the mashup products out there today (from vendors like JackBe, Kapow, Twinsoft, etc) are capable of doing pure data mashups without any sort of graphical artifacts. For example, combing SQL/JDBC datasources, RSS feeds, and raw XML data. So are these "Mashup *plus* EII" tools? I still file them in the pure mashup category. Part of enabling mashups at a firm means getting at the data. If IT provides the raw materials and someone else builds the interface, I still think it's part of the overall mashup process. Anthony however differentiates between Mashup Enablers and Mashup Builders. I don't completely disagree, but I think we're still in the early stages of explaining the technology and it might be a little early to start splitting hairs.

I do focus on pure data mashups, mostly in the Harvest chapter. But patterns like "Quick Proof of Concept" are applicable to this discussion as well. It might make sense to build a mashup-based integrated feed as a test to justify the time and expense to build it "the right way" later on. This addresses your concern about optimizations as well. Data mashups might be situational and short-lived. They might not be optimal - but could still serve as a useful blueprint to hand over for more formal development.

Your big question: What kind of tools are out there? In the book, I define a set of "core activities" : Data Extraction, Data transformation, Data entry, Scheduling, Action, Support for Open Standards, Visualization, etc (see my post here). For pattern, I explain which of these activities comes into play. Not every mashup tool supports every Core Activity. But if you find the patterns you want to build all require Data Extraction and Data Transformation, you'll know what questions to ask the vendors when you start your investigation. Otherwise, I fear vendors will just tell you what you want to hear and you'll have no practical basis for finding out if they do what you really need.

For pure data activities, you may find mashup products like Denodo, Kapow, and Convertigo are a good place to start.
If this is Mashup related, there is a "Folksonomy Enabler" pattern in the book that describes how Mashups can be used to add tagging capabilities to a system that doesn't already support them. And like most of the patterns, this can be done without access to the original source code.

However, for green-field development I agree with David; you'll normally just building in tagging functionality yourself (e.g., collecting the metadata, storing it in a database, making it searchable, etc)
Hi Vijitha,

The mashups are broken down into 5 major categories: Harvest, Manage, Enhance, Assemble, and Test. A complete description of the patterns is available at the book's companion website.

It is definitely example-oriented, as each of the 34 patterns covered has an average of 3 examples included. However, these examples are not code-based (see some of my other posts this week) owing to the current maturity level of the technology. The goal here is to get readers to break out of a traditional development mindset that makes them dismiss certain solutions as technologically impossible. All of the examples in the book can be created with current mashup tooling. The book gives ascribes a set of Core Activities to each of the patterns which will help you choose the right product to help implement the examples.
Hi Roger,

No worries. Please see my post here.

And as one of my endorsers wrote, "Michael Ogrinz does for mashups what the illustrious Gang of Four (Gamma, Helm, Johnson, and Vlissides) did for object-oriented software design. He starts with a buzzword-free explanation of what mashups are and how they matter to the enterprise. He then presents a taxonomy of ready-to-implement design patterns, chock-full of concrete examples. Finally, he includes an appendix of realworld case studies, ranging from a Web 2.0 startup to the Defense Intelligence Agency. This clear, readable, no-nonsense book is a must-have for enterprise IT workers who are ready to embrace the brave new world of Enterprise 2.0.” –Daniel Tunkelang, Ph.D., Chief Scientist, Endeca
Alas, it does not. There are simply no prevailing open standards for mashup building right now that would have made such a task possible.

JackBe is doing leading work with something called EMML (Enterprise Mashup Markup Language) that they created. If that gets good traction, and if they release it to a standards body (as I suspect they will), then we could see vendors and open-source developers rally around it. And that would make it more likely to have code in a future edition or different work.

Right now, the tools for creating mashups (and the resources that go into them) vary too widely. You will see Mashup books that provide Java (or more often JavaScript) code, but these are usually using a few common web resources like Google Maps or Flickr. In Mashup Patterns, I am more focused on the Enterprise mashup developer whose resources may be largely internal.
Hi Alex,

Head First Design Patterns is a great book, but it is basically a new explanation of the patterns introduced in the classic Design Patterns text (Addision Wesley 1994). Many other "Patterns" books focusing on different problem spaces have come (and gone) since then, including: Core J2EE Patterns, SOA Patterns, Wiki Patterns, etc.

If you're interested in learning about what promise Mashups hold as a new development paradigm, then my book is for you
Two good points are raised here:
What is a Mashup?
What the heck are Mashup Patterns?

What's a mashup? Well, that gets right to the crux of why I wrote the book. When I first was exposed to the idea of mashups about 2 years ago, it was the typical "Good restaurants near you on a Google map" example. In my day job, vendors soon started barraging me with different "mashup tools" and each one had a different definition of what a mashup was. Guess what? Each vendor's tool somehow exactly matched their definition!

I spoke at a few conferences about how the vendors weren't going to get anywhere unless they could agree on some common terminology. I even recall saying they should put together a web site called "Mashup Patterns" where they talked about all the problems they could help solve. After one of these talks, a publisher (Addison Wesley) approached me and the rest is history...

Even today people *still* cannot agree on what a mashup is. One vendor (JackBe) is even running a contest on the subject. And Gartner analyst Anthony Bradley and I have had some discussion over whether or not data mashups are a legimate entity. I blog my own definition here.

"Enterprise mashups unleash the information locked in a company’s systems and the creativity trapped within its employees to allow anyone to quickly meet specific business challenges."

That is intentionally not a very technical definition, because the technical aspects of mashups are not of interest to many of the people who may create them (power users). "Mashups" does imply multiple systems are involved, but this isn't necessarily the case, either. It's like "AJAX" - an unfortunately inaccurate but popular term that we are all now stuck with. Without rambling further, I would propose that the wikipedia definition is one of the most horrible ones. There are a lot better proposals over at JackBe's at the link above.

As to the "Patterns": There is a tradition in software engineering going back to the classic Design Patterns text to identify a reusable class of solution and publicize them to prevent others from constantly re-creating the wheel. And to also find bad practices (aka, Anti patterns) so they can be avoided. In Mashup Patterns, I present 34 patterns that show how mashups can solve specific business or technical challenges in a manner unique to this technology. There are also 8 anti-patterns.

As further evidence that the Patterns can provide actual business value, the book is also supplemented with Case Studies from firms like the Associated Press, Thomson Financial, etc that show the patterns in action. This was almost a necessity. Traditional patterns books generally give you the code to implement a pattern. But with mashups, there are no standard tools or protocols, and the raw ingredients vary widely. I felt that until standards emerge, the Case Studies provide the best empirical evidence of the value of this technology.