Advantages in Going Lighter
By not requiring departments to use a specific enterprise stack for everything they do, productivity can improve considerably. For example, if an employee in another division located in another country needs access to data on another department's system, he should be able to do an HTTP GET (as long as he has the right access control) to retrieve the data he needs in an XML document.

On the developer side, the requirement to federate more and more applications and data across traditional corporate boundaries - and at the same time deliver those new services quickly - already has enterprise IT departments looking for new options. For instance, a project team that is tasked with developing five new services that are to be tested and deployed in two months may find that the complexities of the organization's enterprise platform make it impossible to meet their deadline. If they had a framework that includes data services and identity management, they would be able to cut time to market substantially and make that deadline.

Because faster time-to-market is becoming the overriding criteria for successful application infrastructure projects, SOA frameworks of the future will need to deliver more application infrastructure capabilities in less time - and without unnecessary complexity.

Looking to the Internet
Metadata discovery would also need to be a key part of such a lightweight framework. Many SOA platforms have evolved to include heavyweight repositories for service definitions, which require the service definitions to be separated from the implementations and placed in large registries. One lesson we can learn from the Internet is the benefit of lightweight indices; for example, Google and Yahoo! allow for searching across all of the sources of information without consolidating that information into a single location. We search for information and we are then directed to the source of that information for the latest version. This same structure can be applied to service registries; we can employ a lightweight index of service locations that points us to the actual implementations of those services.

Metadata is still important; we just need to handle it in a more lightweight manner. The metadata about what a service offers (what data it presents and what data it expects) will have to be located with the implementation of the service so the data doesn't get out of sync. Lightweight conventions like WSDL or WADL could be employed to package the metadata along with the resource implementation. And putting all of these locations into a single searchable lightweight index would provide just the right level of centralization without slowing down the innovation. However, there is still some work that needs to be done in this area to promote lightweight standards to address metadata packaging in REST resources.

Leveraging Clouds
Looking ahead, more and more Web Services will be built for and leveraged from a cloud. Enterprise developers will need a framework that enables them to create secure Web Services that can be accessed via the Internet or the cloud. A lightweight service that is deployed in a way that external parties can access it has to provide access control that depends on external identity. This is where identity architectures need to scale out to a global perspective. Some WS-* protocols are targeted at providing a solution for this. However, there's additional work that needs to be done to allow a simplified external identity model to be applied to the REST-style programming model. New identity architectures will need to be defined to secure REST resources for programmatic consumption, just as initiatives like OpenID have done to simplify human-based externalized identity.

Enterprises may also choose to develop and house some applications that provide a competitive advantage internally and house other less mission-critical applications on an external cloud. And, both categories will need to interoperate. For example, a company may use Salesforce.com but need it to interact with customer information located in an internal Oracle or SAP application. A unified security programming model for RESTful resource exposure can provide the developer a consistent way to access resources - regardless of where the resource comes from (inside the corporation or outside). A lightweight security model that can be used both inside and outside the corporation would help in this process.

Currently every SaaS interface has a different non-standard way of controlling access to resources; this makes what could be a simple mashup problem difficult. Combining the data together from multiple sources is the easy part, but getting all of the right credentials together for accessing all of the disparate resources is tricky.