##CONTINUE##
But inside an enterprise, sharing data and applications is far more complex. Enterprise SOA vendors have added advanced tools and enabled capabilities that leverage complex specs, making it more difficult for smaller projects to use these features. Although the software may be based on open standards, it often requires a thorough understanding of a range of standards to integrate the data. For example, a department manager who wants access to customer information from another business unit may find that the data is housed in a proprietary middleware bus. In this case, the only way she can access it is by installing the same middleware on her servers, training staff to manage the software, and paying the vendor fees to maintain it.
These kinds of obstacles don't exist on the Internet, where you can go to sites like Google Maps, create a mashup, and send it to your contacts through Facebook. If you want data, you can go directly to the source via open APIs and use it as you see fit. That same capability is needed in the enterprise. For example, Web Services developers must choose between using a RESTful architecture, which has some limitations regarding security, or traditional Web Services (WS) standards, which provide heavy security but are more complex to deploy. And if a developer adds single sign-on functionality to a RESTful interface, the complexity grows.
What we need for the enterprise - and where we believe SOA is heading - is an interface that allows someone to interact directly with data through standard protocols and simple access management instead of through a heavyweight platform, as well as the ability to select the right tool for the job - Web Services where appropriate and a RESTful approach when required.
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.
Identity Management Critical
As developers create Web Services that provide access to data to an ever-expanding federated audience, identity management is critical. When users present credentials to access a Web Service, there must be validation that they're part of a larger system that allows them to access what they're requesting - just like when you present a debit card to make a purchase or get a cash advance at the grocery store. If you could only use that card at ATM machines run by the credit card issuer, that would be a heavyweight model; a non-distributed security model. Instead, the card issuer enables you to use the card virtually anywhere, assuring the store of your security credentials to do the transaction.
Similarly, such a distributed model for Web Services enables developers to create greater value by emphasizing the service and not verification of security credentials. While an identity management function doesn't have to be embedded in the offering, the Web Service needs to be able to connect with identity management software through lightweight standards; this enables developers to focus on the service offering.
Greater Mobility
Finally, with the increasing need for Web Services to run on a variety of screens - desktop, laptop, mobile devices, and set-top boxes - Web Services developers need an application infrastructure that is simple enough to accommodate all of those possibilities. The emphasis is on quick access to data and multiple fast reads from a database table with greater intelligence on the edge. Where enterprise-class applications that offer all the "-ilities" were the focus in the past, lightweight, Web-scale applications that can be used on a range of screens - particularly on mobile devices - will continue to grown in dominance.
For example, the iPhone or Blackberry could become a next-generation publishing platform, or perhaps provide contextual intelligence that offers highly targeted location-based advertising or other information relevant to appropriate potential customers. But to create such services, developers must be able to easily leverage data services and identity management capabilities; a lightweight framework that provides both would be ideal.
Demand for Simpler Framework Will Be Addressed
To enable enterprises to meet the ever-growing demand to deliver new secure Web Services and quickly and easily leverage data across the business, a simpler SOA framework specifically designed for smaller projects is needed.
Web scale is the new enterprise class that organizations will all aspire to. As work continues in developing and promoting lightweight standards, we believe that enterprise developers will soon have a simpler platform that helps them significantly speed and simplify Web Service design and deployment.
-----------------------------BY Ashesh Badani and Jerry Waldorf
Source：Ulitzer
Copyright © 2009 Ulitzer, Inc. - All Rights Reserved.
Posts
0 comments:
Post a Comment