Developer.com asked Michael Stevens to interview Jim Russell, Director of Emerging Technologies for IBM Websphere.
Jim, welcome to Developer.com. Thank you for letting me ask you a few questions on your group’s work and other current developments at IBM.
Thanks, I’m happy to have the opportunity.
Could you briefly explain service-oriented architecture? Is it all about Web services?
Services Oriented Architecture (SOA) and Web services go hand in hand. SOA describes the general concept of architecting applications and solutions around coarse-grained, loosely-coupled components (“services”). This is a powerful concept, since the componentization allows for both newly created business logic and existing applications to coexist and cooperate as part of the overall solution, preserving existing investments. Loose coupling means the components can be flexibly reused and recombined to respond to changing requirements.
Web Services are a concrete example of the services-oriented architecture concept. Web services describe a set of standards for the description, connection, communication, and integration of services. The Web services standards are a critical part of making services-oriented architectures successful, because they provide the industry agreement necessary for the integration of function from multiple sources, and the security of investment in a services-oriented design. IBM has been driving Web Services standards based on our technology experience in what is necessary to build powerful, open, SOAs. We have built SOA capabilities into the Enterprise configuration of WebSphere Application Server Version 5, and they will spread throughout the WebSphere family of software.
Do you think that Web services will be adopted more for internal systems integration or for eBusiness applications?
Both. Like the e-business revolution, I see the internal and external adoption building and driving each other. We initiated the standards work, and frankly much of the evangelism, by considering the problems external interoperability — where you have multiple independent entities creating services that they want to be able to share and interoperate. This drives the standards and vision to address the most important elements of interoperability.
However, I see the first deployments of serious Web services architectures being within the enterprise as internal systems integration. The standards and vision enable the tools, but then the tools are also extremely useful for solving internal integration problems. Internal integration is a problem customers face today, and using Web services to move to a services-oriented environment is a natural approach to address it.
This in turn forms the foundation for external e-business, since once a service is componentized and described with Web services, it is a relatively simple step to offer that same service to external partners, suppliers, customers, etc. That’s the benefit of the Web services standards.
Ultimately, I believe this will lead to a significant transformation in the way e-business applications are constructed or composed, with multiple entities able to cooperate and interoperate. I expect that in the next couple of years will see some novel and successful business models based on services. We’re getting there in stages, but this technology is moving very quickly.
How critical are concerns such as security, metering and billing of Web services to the adoption of Web services on the Internet?
As Web services evolve and grow in adoption, it is vital that we continue to “move up the stack” in ensuring that services can be secure, reliable, transactional, interoperable, and suitable for enterprise e-business. You can see this direction clearly in the evolution of the Web services standards, which have evolved from focusing on connection (WSDL, SOAP, XML), to embracing security (WS-Security, and the recently announced WS- Policy draft), transactions (WS-Transaction, WS-Coordination) and interoperability (WS-I.org). This is critical evolution to make sure that Web services will be “real” for e-business.
Metering and billing get at one of the business models for Web services, where the service is sold as a subscription or by usage. These will be an important part of an On Demand infrastructure for deploying Web services as a business. Ask me about Allegro later!
How is IBM addressing these concerns? In particular, how is IBM addressing security concerns for Web Services?
IBM is of course a leader in driving the Web services standards. We are committed to implementing the standards within our WebSphere family of products, and to ensuring the interoperability of our WebSphere middleware and tools. For security in particular, we were co-author of the WS-Security, WS-Policy, WS-Trust drafts, and author or co-author of several roadmap and whitepaper documents on how to make Web services secure.
The security needs of deployed services are evolving along these same lines. Today, with most Web services being point-to-point, the kind of security provided by an SSL connection is often sufficient. As we see services usage emerge that involves multiple cooperating services and Web services intermediaries, that will demand finer granularity of encryption, verification, and statements of expectations. That is the vision we have described in our roadmap, and are working within the industry to make part of the standard Web services infrastructure.
Do you think that UDDI has a bright future as a registry for Web Services or does another technology hold more promise?
I think UDDI is pretty well established as the registry for Web services. The UDDI registry plays an important role in a services architecture as the place to publish and discover services. This is true in internal deployments as well as external; in fact we are seeing quite a growth in so-called “private” UDDI registries. A private registry may be used for the services created by a particular company or department, or hold references to services that an entity is allowed to access, or a set of services that are “approved” for a particular purpose. The growth in the content within both private and public UDDI registries is of course proportional to the overall growth in Web services, so we will see more and more in the future. In addition, OASIS recently released the UDDI version 3 specification supporting affiliations of registries and digital signatures on the services, which will further support the essential needs
What products does IBM provide that support a Web Service platform?
Well, all of them. Seriously, Web services has permeated most of what we do in one way or another. Integration is one of the core problems that IBM platforms are designed to solve, and Web services are standards for enabling integration, so this is a natural effect. WebSphere is of course our industry-leading application server platform, supports the Web services standards, and provides the base platform for implementing and deploying Web services. The WebSphere Studio Tools provide many ways to create, compose, wrapper, and integrate Web services. WebSphere Business Integrator and WebSphere Portal both use Web services standards as the basis of their integration. And our Grid and on Demand efforts provide sophisticated infrastructure underlying Web services implementations, and are themselves also based on Web services standards.
What is Allegro, and how does it fit into IBM’s plans?
Allegro is the name of a technology that we are developing to support provisioning and metering of Web services. One of the business models we see for external Web services is to sell the services themselves as either a subscription or per-use basis. For example, this may be interesting for a software company that wants to open up a new revenue stream by selling their software on a usage basis; or, the service may be tied to an underlying process, like credit authorization or shipping, that is charged by usage.
In order to support this business model, the service provider needs several things: First, they must be able to create an offering for the service, and enroll customers and give them authorization to use the service. Then, at each service request, the provider needs to detect and authenticate the requestor as an enrolled customer. The provider also needs to be able log or meter the usage of the service for each customer. It is also possible that depending on the kind of enrollment a given customer might get “preferred” service (faster servers, greater volume, etc.) and that needs to be differentiated per request as well. Finally, at the appropriate time (say, the end of a billing cycle) the meter logs are used to bill the customer. Allegro is a provisioning system that provides these functions.
Note also that for the most part the provisioning functions are independent of the function of the service itself. The Allegro technology is structured as a “proxy” that can be used in front of existing services (potentially running on separate machines) to provision them as part of metered business offerings without perturbing the base service itself. The Web services standards for interfaces and protocols make this possible.
Right now an early version of Allegro is available on alphaWorks (www.alphaWorks.ibm.com) as the Web Services Hosting Technology, and we have recently completed beta evaluations with a small number of customers. We make this technology available so that Web services developers can begin to get experience with the technology and experiment with the model. We are working on incorporating this function it into our supported platform offerings in a future release.
Thanks for taking time to talk with us Jim.