The best approach is to design and deploy an SOA with mashups in mind. In other words, make your enterprise’s systems exposable to services or applications outside of your firewall, or able to consume those same services or applications. This is harder than it sounds. Chances are your current systems can’t see outside their own operating systems, let alone the firewall.
To leverage Web-based services and content as resources for mashups, you need to catalog and test services you don’t own and attempt to mash up systems inside and outside of the firewall — and make sure your security planning considers this notion as well. An enterprise that can’t see the new Web will have a huge strategic disadvantage in the years to come.
Mashup preparation can be divided into six familiar stages: requirements, design, governance, security, deployment, and testing. These are core architectural bases you must touch if you are to arrive safely in the promised land of mashups on top of an SOA.
Some sort of requirements document for mashups is needed to surface the issues endemic to your enterprise. A common mistake is to “manage by magazine” and assume that all of the cool stuff that works for other enterprises will be right for you. Instead, consider both your unique business drivers and the state of the current architecture. Start thinking about which mashups will be valuable and how much change must occur to get you there.
The design for mashups involves figuring out how the systems should be configured and which enabling technology and standards should be applied to provide the best SOA-based mashup platform. Key questions here: What interfaces should I expose and how? How will I handle scalability? How will I approach both visual and nonvisual mashups? How will I leverage services and interfaces delivered over the Web? How will I manage the exposure of my interfaces and services to others on the Web, if needed?
Governance — the creation and enforcement of design time and runtime policies — is tricky business for mashups. Given that mashups are made up of services and may indeed become services themselves, you need to manage these services across the entire lifecycle, as with any service or process contained in an SOA. Among other things, this means selecting, building, and maintaining a mashup-aware registry/repository. However, although mashups need to be managed, you should avoid overloading them with policies and procedures, or you’ll discourage developers from creating them.
Mashup security is critical, considering that you’re looking to leverage interfaces, content, and services you neither created nor own. No one wants to discover that an innocent-looking AJAX mashup is actually sending customer data to some remote server and compromising the business. Care must be taken to implement security policies and technology layers that will protect the value of the mashup platform. This should mesh with your SOA security or become an extension to it.
To deploy mashups properly, you need to select the proper enabling technology and standards. Clearly, AJAX is popular for interfaces, but there’s also Adobe Flex — it all depends on what you think you’ll need to build and what your developers are up to speed on. Moreover, consider how the technologies you choose will link to governance and security. What are the key products you’ll leverage to support mashups within your SOA, and how will they be linked to the enabling technology solutions already implemented?