In a couple of my previous posts, I discussed the integration of a Flex application into an existing web site. One post (link to post) discussed dynamically controlling the HTML real estate used by an embedded Flex application. The other post (link to post) gave a (hopefully) simplified view of code snippets that can be used to communicate between Flex and JavaScript under various scenarios. These were low-level, “how-to” posts. In this post, I’d like to explore some of the ways that this type of integration might benefit the enterprise.
In this particular situation, I was representing a company that had a new product/service offering. This offering is something that many existing E-Commerce web sites would like to add to their existing web site. Conceptually, this is a pretty common situation. However, integration is often more difficult to implement than it is to conceive.
That was not the case in this situation. Implementing this business offering by embedding a Flex application into an existing web site was embarrassingly easy. The integration instructions given to the E-Commerce site’s developers consisted of about 30 lines of text. This text consisted of the HTML Object/Embed tags and the JavaScript functions that the E-Commerce site’s developers needed to copy and paste into their web page. Beyond copying and pasting this text, all the E-Commerce site’s developers needed to do was to modify the JavaScript return values with the values from their web page.
They did not have to change any code on their server. They did not have to change the flow of their web pages. The Flex application that we provided them handled the external-domain server communication. We did not have to work-out the details of how the customer’s servers would access our servers and our services. We did not have to match technologies or protocols. The E-Commerce web site’s developers did not have to modify their server code to know, understand, and call our services.
This integration did not take months or years. This integration took something on the order of minutes or hours. I suppose you could say it took days, if you include time to arrange phone calls between the developers, etc.
Think about that. A new business offering was implemented in a matter of days.
Obviously, the company (or enterprise project team) providing the services, will have to build the backend for the services. But, they would have to do this anyway. The huge payoff is at integration time. And, if these services are used by many “clients” (either by selling the same offering over and over to many customers … or, within an enterprise, by allowing many project teams and existing applications to leverage your services), the cost-benefit analysis becomes compelling. Moreover, the more you can shrink the integration time, the easier it becomes to close a deal. In corporations, various levels of the hierarchy often have different levels of budgetary decision-making power. The lower the integration cost, the fewer levels of approval you will need to close a deal.
Admittedly, this was a specific type of business offering. It clearly does not replace all other forms of integration. As with any architectural tool (or software design pattern), you still must choose the best solution for a given challenge. There are many places where SOA, RESTful Web Services, XML, etc. will be the better solution. But, when this type of solution fits, it can really payoff!
Tags: business, Enterprise, existing web site, Flex, integrate, integration, speed, value