Okay -- this definitely does not qualify as a good SOA practice. It sounds like traditional EAI. I guess that's what you should expect from the See Beyond guys. Any ESB should enable the department manager to access the customer information "service" without installing a specific vendor's middleware.
> 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. I'm a huge proponent of exposing service via URLs and HTTP, but this article starts off with a bogus thesis. Anne On Sun, May 24, 2009 at 5:11 PM, Gervas Douglas <[email protected]> wrote: > <<As consumers we are accustomed to the end-user experience of the Internet. > With HTTP and XML, you don't need to have a specific application on your > computer to make use of external data - you can just open a browser window > and do a search or visit a particular Web site to find the information you > need. > > 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.>> > > You can read this at: http://in.sys-con.com/node/973243 > > Gervas >
