For those of us new to enterprise application mashups, portals may be a good place to start learning. Some mashups
experts, including our friend Mike Ogrinz, would consider a portal to be a type of enterprise mashup despite the fact that portals came first. Application mashup techniques can quickly build enterprise portals, but enterprise application mashups are also able to accomplish a lot of other important goals within the IT organization. According to Ogrinz, REST APIs can be an important part of making application mashups work.
Data integration is one of the major use cases of enterprise mashups, according to Ogrinz. "The primary purpose of portals is to get various data from point A to point B," he said. One of the most important questions that developers answer using enterprise applications mashups is, "How am I going to get this important data out of (or into) this application?"
In some ways, this view likens enterprise data mashups to data extraction, transformation, and load (ETL) tools with which you may be familiar. The difference between portals or ETL tools and enterprise mashups may be similar to the difference between a varied assortment of enterprise applications and a mature SOA. In both cases, the difference is not so much in what they are, but in how they're built.
By building enterprise applications and other IT assets based on SOA and Web services, architects are able to build SOA architecture that allows for increased integration and reusability of services. Similarly, using standard services and application programming interfaces (APIs) allows application mashup developers to quickly mix and match data and functionality among various different IT assets.
One of the major tenets behind the discipline of enterprise application mashups is to view enterprise assets (applications and data sources) as being composed of the most basic building blocks possible. Said building blocks can be seen as the atomic components of functionality for potential enterprise application mashups. According to Ogrinz, REST represents the easiest way to mould these building blocks into standard, reusable shapes.
In a recent conversation, Ogrinz told us that REST is a common denominator in developers' skillsets today. SOAP might be a little easier for .NET folks while Java folks might find it more difficult, but both groups can agree on REST as a middle ground. This agreement probably relates to the popularity of REST as the architecture for Web applications.
REST has changed many developers' approaches to problems. In the past, you might build a database query that would search a database of users to return appropriate information about a given user. You would have to carefully plan around explicitly stated user requirements in order to ensure that users will be able enter the right information into the system and that the system will be able to return information that is useful to the user. Today, Ogrinz tells us, generating generic REST APIs can be the best first way to enable the construction and customization of search-related applications. It can reduce the necessity of rigid software requirement management.
With a list of generic APIs in place, it is possible to rearrange search criteria on the fly. It does, however, require that a separate API is developed for each relationship within the database. So a database that includes user ID, location, email, and company information would require a separate API for the user ID/location relationship, the user ID/email relationship, the user ID/company relationship, and so on.
Once these APIs are in place, customizing a search mashup to perform any query possible in the database becomes a simple process. So if the requirements change suddenly, the mashup application can be updated suddenly - or even replaced with a new application mashup.