One of the big attractions of a SOA is the ability to connect to and consume running (web-)services, without having to worry about how to deploy, run, and manage these services. This wasn't always the way people thought of allowing reuse. In the not too distant history, these business services would have been built as reusable binary components, which would be shared between IT projects in the business. This type of component based reuse had several drawbacks. Here are a few of them:
- Updating a component required rebuilding and redeploying an application
- Components had design, build, and runtime dependencies, making them more and more fragile and complex to use
- Unforeseen differences in runtime environments caused unpredictable behaviour of these components that were difficult to debug and fix
- Components were development environment specific, e.g. VB components wouldn't be reusable in a Powerbuilder environment
- Components could, and often would, tie the consumer into vendor specific libraries
- Access to the binary components allowed the consumer to reverse engineer the code
- Access to the binary component put more requirements on security of the component internals
- No visibility on the use of the component
For these reasons, it made sense for businesses to move to an IT infrastructure that promotes the runtime sharing of services.
With this in mind, it is interesting to see the current approach to UI reuse. Several IDEs and frameworks are creating an environment in which UI component will be shared across the business at the binary level. This will create the exact same issues as we have seen with binary reuse of business components. The only way around it is to enable the runtime reuse of UI. The technology that allows this is called a UIService and is exactly the technology we have built at Corizon.
