There are a couple major problems with this approach:
- Anytime you added a gadget you would possibly have to write a whole slew of interpreter gadgets for the gadgets you wanted to give input to or take input from. At a minimum, every gadget would require at least one interpreter gadget.
- The whole gadget as a web service concept breaks down when you start talking about interpreter gadgets. They do not need to reside on the web, they need to reside on the platform. Should you have a platform based gadget? Is that really worthwhile or does it break the nice clean system we've conceptualized?
In PopFly, you capture two (or more) web service endpoints and then you map the fields in the endpoints together. This allows you to create dynamic mash-ups on the fly, among other things. So, let's say that I have a web service that gives me a weather report for a list of locations and I have a mapping web service (like Google Earth). I can map the location info from the weather report list onto the mapping service and create a series of push-pins on the map that will show you the weather report when you mouse over them. It's pretty nifty and very simple to use.
Why not use the mapping between web services concept for our platform?
It's a much more elegant solution. It has several advantages over the other approach I mentioned:
- A mapping is much easier to generate than a complete gadget. What's more, if done right, it could be done in a UI! PopFly has demonstrated this very well.
- The platform would only have to remember a mapping (which could be done in XML quite easily) for any communication between gadgets. That eliminates the problem of having platform-bound gadgets.
- The mappings could be based off of the WSDLs that the web services publish. This would allow a direct mapping from the output of one gadget to the input of another. No intermediary step is needed.
I shall post my progress here!
No comments:
Post a Comment