I've been working with Kapow's RoboMaker for the past few days, investigating it for ease of use with the business masher in mind. RoboMaker is a desktop tool that enables mashers to bring content together from many sources to create RSS feeds, RESTful web services and even portal content.
From a pure 'number of features' measure, it is hands-down the most capable product I've looked at so far. Once I figured out how to use it, I was able to create an RSS feed from a news article list on Serena's website in very short order. In fact, I used the same basic steps to build both a feed and a RESTful web service.
Kapow's approach is similar to that taken by Intel's Mash Maker. (Or rather, since Kapow's offering has been out for quite a while, Intel Mash Maker's approach is similar to Kapow's.) That is, a masher identifies the content to be mashed by pulling a web page into RoboMaker. the masher uses html tag paths to tell RoboMaker where to extract the content, and depending on the output destination, how to format the output.
RoboMaker has a number of additional features, such as the ability to branch, call out to services, simulate mouse clicks, execute javascript, etc. This is both a blessing and a curse. A blessing because the richness of features allows mashers more flexibility when developing content. A curse because without solid and user-friendly documentation, the extra features can be difficult to find and use.
I didn't see any evidence of a WADL, which isn't surprising considering the industry hasn't yet decided whether RESTful web services actually need a WSDL-like contract. Since it will be mighty difficult or a non-technical user to pull a service into a process-based orchestration engine without a contract, I hope we do embrace either WADL, or some other contract standard. Until then, I think Kapow should be proactive and publish both the service and the WADL contract. I know, that's easy for me to say since it isn't my R&D budget.
The resulting feed, service or portal content, as specified by the robot (in Kapow-speak) is stored 'in the cloud' on Kapow's server. Kapow also supports OpenKapow, a user community where mashers can publish, share, search for and discuss robots and mashups. (Note: Kapow also has an on-premise edition that I didn't test drive. I can certainly see how the on-premise edition would be very useful for organizations trying to leverage the valuable data that lies trapped behind the firewall.)
So in most ways, except for the sheer number of features, RoboMaker is a lot like Mash Maker. Since they both use HTML scraping, that isn't a surprise. Unlike Intel, however, RoboMaker robots produce mashable content that is based on standards, so you can create the mashup content using RoboMaker and use any mashup tool to build the mashup itself.
That is mighty cool.
But is it ready for a business user?
Back in my Unix days we used to say that the Unix shell was 'expert friendly.' That is, once you knew the ropes, you could use the shell to do an amazing number of things. That's the way I feel about RoboMaker. I found the documentation circular and confusing, and even more infuriating, error messages that were unhelpful and in many cases actually cryptic. However, once I found the rough edges and understood what was going on, I was able to do a lot of mashing very quickly.
Back to the question. Depsite the need for better documentation and a usability development cycle, RoboMaker is the first mashup tool, besides Serena Mashup Composer, of course, that I believe I could put in front of a business masher.
Subscribe to:
Post Comments (Atom)
1 comment:
"Business Masher" thats interesting term, i like it, would love to see companies have a 'business masher' just like they have 'webmasters'
Web 2.0 is just a phenomenon not an actual thing. I think people are overmilking this cow.
What really we should be looking at are wiki, RSS and responsive web UIs that are the underlying.
Mashup = assembly & simplicity
This any day beats complicated WS*-stacks + SOA + ESB that have been posturing for years. In business, it's either 'fast and up' or 'never at all'
And to mash up at the 'semantic level' not at some display level.
Lets not split hairs to get it absolutely wrong, but roughly correct. A mashup that is in heavy used is better than a pristine cobwebbed service.
speed- speed- then simplify- then more speed
Post a Comment