Building The New E-Services Economy
Ever since batch computing and keypunch cards, IT has been obliged to become increasingly responsive to the enterprise
By: Rajiv Gupta
Mar. 15, 2001 04:00 PM
Ever since batch computing and keypunch cards, IT has been obliged to become increasingly responsive to the enterprise and faster at adapting technology to meet business needs. Right now businesses' upcoming need is for e-services, because IT's core competency is becoming the managing of IT policies and knowing how to leverage technology in support of the business, without necessarily having to physically own and manage that technology.
Any enterprise that wants to take full advantage of the business opportunity represented by "e-services" will focus on moving the Internet beyond merely accessing data to accessing a rich array of electronic services. E-service offerings will need to blend content, transactions, and information in compelling new ways, many of which have yet to be invented.
The advantage of an e-services approach to an enterprise is that, from an IT standpoint, it can select IT services on a per-use basis, outsource on demand, and avoid high capital investments. From a time-to-market standpoint, the enterprise can focus on core competencies and launch new products and services faster and at lower costs, without waiting for in-house IT resources or capabilities to catch up.
Enterprises will acquire the resources needed to launch an e-services strategy by connecting to potentially multiple e-service utilities and through them access competing independent e-service providers. This is similar to the way ISPs compete for the ability to connect you with independent Web sites.
New Opportunities for Financial Services
They can lower the cost of two aspects of their business:
As an example of lowering operations costs, you might see increased outsourcing for functions such as data center disaster recovery or analysis of customer information to determine each customer's value to the institution.
Launching New E-Services
Worldwide Effect on Financial Services Institutions
As for larger, more established financial institutions, one competitive advantage in that kind of environment would be the ability to drill down into existing databases through secure, reliable access to e-services. Today's larger institutions have acquired an enormous amount of information about customers. With reliable e-services they could quickly assemble a market analysis and campaign management value chain, thus enabling them to offer very personalized products in a timely, targeted manner, ultimately achieving one-to-one marketing.
Overall, then, an e-services environment doesn't change current trends so much as accelerate them. As with any other change, this can be viewed as a threat or an opportunity. The competitive arena for financial services isn't going away.
"21st-Century Computing" Defined
In a utility computing environment you have an infinite supply of computing resources instantly available and you pay only when you use them, without the expense of purchasing, installing, maintaining, and upgrading equipment at your own site.
With such an e-services technology for utility computing, HP seeks to accelerate the move toward e-services, which we see as the next coming phase in the evolution of information systems. Potentially as bold and influential as the advent of the Web itself or the shift from batch mainframes to distributed minicomputers, the transition from today's open client/server systems to tomorrow's utility-based open services and information appliances may herald a whole new e-services economy.
E-Services the HP Way
While E-Speak, the technology that HP has developed to enable e-services, is based on open technology available to anyone, HP, as its developer, expects to have the best understanding of it and the best offering for incorporating it into solutions. So we will be able to help provide a first-to-market advantage, and if you think about what being first did for companies such as AOL and Amazon.com, you will see the potential benefit here as well.
In addition, HP already has a well-established enabling-technology environment for supporting e-services with products such as the Praesidium security family and Web Quality of Service. This technology infrastructure will enable enterprises to launch end-to-end e-services solutions with confidence. And we also have a well-established, global HP Consulting organization to assist in developing, implementing, and supporting our enterprise partners. Many leading financial institutions, for example, already work with HP Consulting on their First Global strategies and e-services are a natural extension of that.
HP's strengths lie in its history as an open systems leader and in the breadth of its offerings. As a very diverse open systems company with enormous experience in supporting enterprises around the globe and with a reputation for quality, we are a customer-driven enterprise. HP has always responded to customer needs, and e-services represent just the next step in providing our customers and the consumers they serve with more options, more choice, and more opportunity.
Since Internet Chapter 2 is about changing the Internet experience from "do it yourself" to "do it for me," E-Speak defines a uniform services interface (APIs) and uniform services interaction (E-Speak engine) that allows e-services to dynamically interact to discover, negotiate, broker and compose themselves to solve a business to business or business to consumer service request.
Presently in beta, the Beta 2.2 release of E-Speak on www.e-speak.net includes an alpha quality Web access API that converts from the standard HTTP Web protocol (GET/POST) carrying XML or HTML/XHTML documents to E-Speak requests, or client service requests matching any arbitrary DTD. In this case E-Speak runs as a standard Java servlet behind Apache, but it could be running behind any servlet capable Web server.
What Is E-Speak? A Brief introduction
In the case of the Web, distributed application development has grown more out of the persistent infrastructure than it's been engineered from the start. If you've ever tried to write Web applications you'll have noticed that the stateless nature of the Web browser can be a real headache. Out of band updates are difficult, session management works when cookies are enabled but is a pain when they aren't, and anything other than a simple request-response interaction is completely out. And there are all of the nit-picking details that vary from one browser to another requiring you to check and recheck the HTML you're generating. But still, all in all it's basically an open-standards platform, and the server end is completely free.
The Web advertising element, the realm of Web portals, is completely owned by individual interests. Who controls what link comes up at the top of a Web search at your favorite portal?
In the case of a search engine like Altavista, you can get your site to come out on top by inventing your own keyword, and then using that keyword to search, but then who'll know to search for it that way? There are two problems with keywords: first, they lack parameterization; you can't look for the "shoe that is yellow or green," only for "shoe yellow green," which may return sites like "red shoe, green boat." Second, they have no hierarchy since they aren't defined to be searchable within a containing context. You can't search keywords for "shoe that is red returning only shoe stores," so you might get results that match the Wizard of Oz as readily as you can find Kenny's.
Portals like Yahoo! solve the latter problem by introducing categories, so that what they lack in number of links they make up in quality. So if you want to be the first or only site listed in a category, just create your own category. It's a good idea, but Yahoo! doesn't open up the creation of new categories to the general public. Your ability to differentiate the service you offer is restricted to the categories that a Yahoo! is willing to let you advertise in.
Java's approach is a world apart. By making all code in the world executable on all systems, applications can describe themselves by delivering executable device drivers that implement an interface. If the interface is unknown, then introspection allows the interface to be examined at runtime. Even assuming you buy Sun's arguments that transferring object code can be made safe through the use of sandboxes, the main weakness of this approach is that everything has to be Java for it to work, and Java is the exclusive property of Sun. You can own your juice table, but Sun owns the rug, and can pull it out from under you at any time; so really you are relying on the benevolence of a single company. More than that you are relying on the perpetual benevolence of that company.
Historically, CORBA grew from a tradition of remote procedure calls that were adapted to more modern OO (object oriented) design methods. As a result CORBA applications tend to be very fine grained in their method definitions: each method does only one function, and if the object being returned is at all complex, a typical CORBA application will return an object reference to an interface on the result-object rather than return the whole result. Distributed applications written in this way are very tightly coupled client to service and, although CORBA has some introspection and dynamic calling features, these are almost superfluous considering the complexity involved in trying to write an application that can make a series of useful calls to an object with only the function parameters to go by.
CORBA also suffers badly in an Internet environment. The typical latency of a CORBA request is less than 10ms, while Internet latency can be an order of magnitude higher making the tendency of a Web-based application to combine a whole series of operations into a single request much more responsive than CORBA over the Internet. And CORBA gets into big trouble trying to make its way through a firewall. By passing object references back and forth through its communications link, it becomes very complex to catch the references in transit and rewrite them so that they refer to a proxy location on the firewall, or to manage the lifecycle of a proxy object. Eventually network administrators give up and poke a hole through the firewall for the CORBA application and allow it to talk to its clients directly, effectively moving the firewall back a level to the CORBA server, and diminishing the control that the IT departments have over data entering and exiting their network.
"E-Speak" by comparison grew out of distributed operating system research. The question we asked ourselves was: How can clients interact with an abstract service the way that a UNIX program accesses a disk, while getting its semantics and implementation from arbitrary locations on the network? To explain: user programs under UNIX use what they call a file - they write to it and read from it. The operating system converts the file semantics that the user sees into a series of operations that read and write sectors on a disk; but the user program never has to deal with those. E-Speak allows a client to find a service that discusses actions with the client in terms of certain semantics; but that service can also be an intermediary that passes interpreted requests on to lower-level services until you get to the hardware.
This architecture leads to a system with latency in the tens of milliseconds (i.e., between Web latency and CORBA latency). Otherwise the architecture is quite similar to the Web, but with integrated support for searching and fine-grained access control. E-Speak servers acting like a kernel can be inserted between clients and services at multiple points in a chain, with remote services looking and acting just like local services but with slightly higher latency. Net result: administrators can see and control access to services inside their networks. The firewall remains the firewall.
Compared with the Web, resource advertising is much more open, meaning you can differentiate yourself on more than just price. Anyone can create their own vocabulary and advertise in that, essentially creating a category. Anyone can own a vocabulary and control access to that vocabulary so that, say, a rating service for services can exist. When advertising in a commonly used vocabulary you aren't restricted to just including or not including keywords; each attribute is parameterized so that you can search for the service that actually fits your needs, not just for any service in the same general market.
This ties in closely with what I believe is the core value of XML. In making loosely coupled client/service interactions broadly usable, the real value of XML isn't in the standards committees (though they certainly have their uses), but in XML itself. That a company can go out and create a service that responds to some XML document that no one has ever heard of before and that no one else will ever try to reproduce, but that's still usable by a client who can read and understand the DTD, is the most important aspect of XML. It places the ability to succeed in the hands of each individual company, and although the standards may become important, I think that the ability to talk to services that aren't yet (and may never be) important enough to be standardized is on a much higher growth curve.
So E-Speak incorporates XML messaging at its core (for loosely coupled interaction). And it provides a network object model environment for more tightly coupled applications or for developers who aren't comfortable working in the document domain. Getting from a client using documents to a service written for network objects is a simple matter of inserting a translation service in the middle of the request. Just advertise the ability to translate from some DTD to some NOM interface and clients will be able to locate you anywhere on the network; and translating the request is straightforward since all messages are directed through the core anyway; the client and the service continue to talk to the same physical entity, even when they require protocol translation.
For now, moving from the document world to the NOM world is a matter of scripting some Perl to do the translation, but HP is also actively researching the possibility of unifying these two domains more transparently. Even with the current system, though, E-Speak provides a perfect management system for managing all of the little Perl scripts, protocol converters, and stubs that no one really owns, manages, or knows where to find.
Finally in contrast with Java, E-Speak is free not only in the beer sense, but in the speech sense too. We aren't just giving away the source code to E-Speak because we think we can keep control over it in some other way; if so it would have been foolish to choose the GPL for our license. If you in the community don't like what we are doing with E-Speak you can fork the project. In fact at HP we're very interested in developing our relationship with the open source community as a consensus-driven standardization process. We're currently busy finding interested people to form a steering committee to control the future of E-Speak on which HP will hold only one seat. The processes to be used by this committee are open for all to see; and that committee, not HP, will eventually decide what modifications continue to be called the E-Speak Services Platform, and what are not.
Paraphrasing the words of Tim Berners-Lee, we're already asking people to put up their most valuable resources on our product; if we ask any more than that by holding something back, then there'll be no acceptance of this product. The market will continue to divide and fragment until every company has its own product that tries to achieve some hidden control over the whole market.
Reader Feedback: Page 1 of 1
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week