|
This article identifies and describes the roles of major participants within the evolving complex ecosystem of Web services. A brief introduction to Web services is offered. Next, the limitations and/or issues with Web services in general as seen by these participants are described. Then, a methodology for adopting Web services will be proposed. Finally, a discussion of what it takes for an entity to participate in the Web service space is presented.
What Are Web Services?
Web services are software components that are developed by a service provider and made available in a public registry for prospective clients to discover and use over the Internet. Examples of Web services are stock quotes, sports scores, credit card verification, and so on.
At the core of Web services is the Internet infrastructure, XML technologies, HTTP, Simple Object Access Protocol (SOAP), and other protocols. Service providers, service brokers, and clients communicate by exchanging SOAP messages with appropriate XML payload. The various elements of Web services and the corresponding applicable standards are shown in Table 1.
The Web Services Flow Language (WSFL) is an XML language for describing how individual Web services can be composed as part of a business workflow. UDDI is used for defining a structure for publishing and discovering information about business and the services they provide. The WSDL description makes it possible for a client to invoke a service after it's been discovered. Security, Management and Quality of Service aspects span the entire service stack.
In addition to the service providers, consumers, and service brokers, standards organizations, technology partners, and IT infrastructure vendors form the backbone of the Web services space.
The standards organizations W3C, OASIS, OMG and other industry leaders, such as IBM, Microsoft, and SUN, work on defining and publishing open standards for the emerging technologies. This long list of available and working drafts of specifications is a testimony to the monumental effort made possible only through the visionary and concerted efforts of various standards bodies, committees with active participation from technology vendors, industry experts, consumer groups, etc. The standards fall all over the spectrum of the Web services stack and industry-specific areas.
The technology partners typically provide the necessary tools and architectures for distributed service management and monitoring, distributed security models, XML engines, service frameworks and architectures, integration with business processes, modeling tools, development tools, and services enablers.
The IT infrastructure vendor provides the hardware and software infrastructure such as networks, communications, servers, systems integration, and everything that makes the Web services run (see Table 2). Enterprise issues such as scalability, availability, throughput, latency, bandwidth, clustering, hardware management, and network topology are factors in deploying Web services.
It's not difficult to see that an entity can participate in multiple roles to take advantage of the multitude of opportunities provided by this technology.
Why Web Services?
Web services is based on technologies and open standards coming together to provide a common good for doing business using the Internet. There's a lot of excitement and momentum in the industry because of the value perceived in making applications and services available in a quicker and better way. In the world of the Internet, it appears to be a natural progression for taking computing using the World Wide Web to the next level. The arguments for using Web services include:
- Availability: Uses existing Internet technologies to use and deploy services
- Transparency: Services can be located anywhere and used from any where.
- Encapsulation: Implementation details of the services are well hidden.
- Platform-independent: Open technologies that aren't tied to a particular vendor.
- Standards based: A variety of standards address almost every aspect of services
- Interoperability: Open and platform-independent standard-based implementations pave the way for interoperable services.
- Support: Well supported by industry leaders, vendors, and standards committees
Current Limitations/Issues
Participants in this space are faced with a number of limitations and issues due to the evolving nature of the technologies and standards that are continually being addressed and resolved. Here's a look at some general issues:
Standards
Evolving specifications are in various stages of finalization and approvals. At the time of this writing the current standards are:
UDDI 2.0 specifications from UDDI.org: Supported by IBM, Microsoft, HP, Sun
SOAP 1.2 working drafts just published; SOAP 1.1 W3C approved
WSDL 1.1 submitted as W3C note
WSFL 1.0 from IBM competing with XLANG from Microsoft
EbXML 1.04 Technical Architecture Specification approved by OASIS
Openstandard specifications are needed across the board in the Web services stack. Providing tools that support these everevolving and, at times, competing standards can be difficult.
Limited communication protocols: SOAP 1.0 was limited to HTTP protocols only. SOAP 1.1 included HTTP (S), JMS, and SMTP. Including more protocols enhances the ability to expose more legacy applications as Web services because of increased connectivity. After all, one of the main themes of Web
services is to make as many applications available as possible without having to do a major rewrite. In addition, some vendor implementations of SOAP 1.1 may not be interoperable, resulting in services that won't work properly.
SOAP object activation and life cycle management raise issues: When should a service clean up its resources? How long should the objects be kept around in anticipation of the next service call? Object life cycle management can have serious performance implications.
Quality of Service
Interoperability and interchangeability: While the consumer may choose between a number of service providers, the practical issue is whether service A1 from provider A can be used interchangeably with service B2 from provider B with the same results and the same quality. How does a service aggregator work with two different service providers? How do you convey the semantics of a service? Dynamic discovery is not yet available.
Transactions: The transactional nature of a service, such as database updates, hasn't been addressed. Can you roll back a service after the results are returned to the client? Is there support for distributed transactions?
Performance: Response time can be a key factor in determining the usefulness of a service.
Security
Sharing of information between the service provider, broker, and consumer in an open environment in a loosely coupled manner over a period of time can lead to additional security risks. Single-signon, establishing secure data services by brokers, and runtime protection security issues must be addressed. How do you define and communicate methodlevel security?
Management
Service management This becomes complex as services are composed of other
services that are geographically distributed. How do we test such a complex system?
Payments and escrow services: How much and for how long do you charge for a service? How do you maintain and track use? How do you specify escrow provisions?
Business Integration: The impact on current business processes needs to be analyzed.
Methodology For Adoption
Web services offer another channel for delivering quality products and services over the Internet. Perhaps the biggest question from a service provider's perspective is how to take an existing application or write a new one and turn into a Web service. One general approach for a Web services technology strategy contains three steps:
Understand the technology for what it is worth: Conduct research using industry expert reports such as Gartner, Tech Metrix, and so on. Know what the technology is about, what it can do, and where it will be in both the short and long term.
Evaluate the technology for use in your space: Develop a prototype and architect a solution around it. Look at how it impacts
your business processes. Evaluate and estimate project costs. Identify the value-add or issues in using it:
- Time to market
- Product development costs
- Risks
- XML protocols specific to the domain (e.g., banking, health care, etc.)
Look into existing Web services.
Adopt the technology: Once the technology is understood and you've ensured that it's viable, the next step is to incorporate it into a product or service offering. Deploy it internally before making it public.
Now let's look at adapting Web services from a service provider's perspective. We'll focus on building robust applications suitable for services by incorporating feedback from the deployed Web services as well as information gathered from researching Web services external to the organization.
Step 1: Build Robust Applications
Whether they are Web services or not, it's imperative that you build robust applications for your core business competency. High-quality applications are good candidates for Web services. The choice of technology (J2EE, .NET, etc.) for developing the applications is really a business decision. One of the biggest advantages in Web services is that the service implementation logic and the language of implementation are all transparent to the user of the service. Wrappers are needed to expose these applications.
Step 2: Identify Applications That Are Suitable for Web Services
A quick look at public registries reveals that a number of the available services are trivial, such as a calculator or temperature converter. The general guideline should be that the service offer some tangible value to the business. The following considerations can help you decide whether a particular application should be enabled under the Web services framework:
Service granularity: Is the package too much, too little, or too soon?
Cost of enabling the service: Web applications generally need less integration work compared to legacy applications.
Manageability: Deployment, code maintenance complexity, and support structure
Security: To whom and for how long can the service be made available? What are the security policies and how do you define and enforce them for isolation, authorization, authentication, auditing, and monitoring? Are there any method level/component level security restrictions?
Transaction: Read-only service versus real-time database updates? Do you need to roll back?
Availability: What's the impact on existing systems? How will it affect the current system load?
Dependencies: What are the third-party or other critical-system dependencies for this application?
Publishing criteria: Choose between a public free registry, public fee-based registry, or internal registry.
Fees and licensing: How will you charge and receive payments?
Current Internet infrastructure
Incorporate feedback from already published services and research from external services into your plans.
Step 3: Enable Applications as Web Services
This step involves developing wrappers and adapters for existing applications, followed by deployment, publishing, managing, and monitoring the services (see Figure 1).
Development and deployment
Applications that need to be enabled fall into three general categories: legacy systems, Web applications, and new applications written for Web services. The most important aspect of enabling is architecting a solution that contains a Web services layer to handle the incoming and outgoing SOAP/XML messages. This layer may also handle XML parsing, translation, XML message writing, and so on. Processing the results returned from the remote procedure call (RPC) or packaging an RPC call can be handled here as well. Business functions, such as interpreting results or packaging the service call, can be deferred to a lower-level module that provides the integration.
A variety of packaged solutions and product offerings, such as add-ons to application servers, standalone Web service containers, toolkits, and so on are available from vendors. Choose one that fits your current technology platform.
Just like any other development project, developing for Web services requires specialized skills. A number of vendors provide tools and toolkits to hide some of the complexities of these protocols to facilitate development and deployment. The following are some of what you'll need for consuming or developing Web services.
Development Environments: IDEs, toolkits, frameworks
Web skills: J2EE JSP, .NET .ASP
Web services skills: SOAP, XML, WSDL, UDDI, ebXML, domain-specific XML schemas
Web-enabling skills: Messaging systems, EAI, distributed computing, systems management, integration with business processes and workflows
After you build and test the service layer and adapters, the services are deployed.
Publishing
A deployed service is now available for publishing to a registry. Use a vendor provided tool to publish to a known registry.
Managing and Monitoring
Plan to monitor usage of your Web services. Update the registry with any changes to the service or withdrawal of service. If your service uses other services, then the deployment and rollout plan should include a riskmanagement plan such as use of alternate registries. The plan might include removing the service from the registry either temporarily or permanently.
Step 4. Seek Out Relevant and Useful Web Services
One nice way to learn about Web services is to look into an existing Web service. Be your own critic and try out your own published service or one that you might want to package. Check out the registries periodically. Architect solutions to consume XML data received from Web services and integrate with legacy or new applications. Provide feedback into product development.
Step 5. Use Those Web Services Internally or to Develop Others
Do a proof-of-concept use. Build aggregate services as a valueadd to core competency. Provide feedback into Step 2 for evaluating candidates for future Web services or feedback into Step 1 for developing robust applications.
This methodology can also be used, with minor modifications, during the evaluation phase. Service consumers and aggregators can benefit from this as well.
What It Takes To Participate
It's conceivable that a single organization might have several roles in the ecosystem of the Web services world. Following is a look at what is needed to take part in each role. As you'll see, some of the requirements overlap into several areas.
As a consumer of Web services:
Develop technical skills
Be aware of quality of service issues such as response time, lack of flexibility of the service, remote procedure versus local call, security, robustness, granularity of the service, etc.
Monitor service usage costs and quality of brokers
Participate in standards development
Continuously explore for quality relevant services
Monitor usage of services
Maintain service versions and withdrawal of services
Monitor security policies
Participate in standards development
Build wrappers to existing applications to enable Web services
As a service broker:
Set up and maintain free or fee-based UDDI servers and registries
Develop technical skills
Self-impose quality control checks on invalid entries in the repository
Implement security policies on data access as needed
Provide or enable electronic payments for registry use
Participate in standards development
Seek creative avenues to offset the costs of maintaining the registries
Make repositories easy to use
As a technology partner :
Research and develop technology foundations in the areas of distributed service management and monitoring, distributed security models, XML engines, service frameworks and architectures, integration with business processes, modeling tools, IDEs, and service enablers such as adapters, wrappers, connectors, client integration etc.
Work with IT infrastructure vendors to make the technology viable
Participate in standards development
As an IT infrastructure vendor:
Develop hardware and software infrastructure products and services for developing, deploying, and delivering Web services
Provide hardware and software infrastructure, such as networks, communications, servers, systems integration, and everything that makes the Web services run.
Provide tools and solutions to enterprise issues: Scalability, availability, throughput, latency, bandwidth, clustering, hardware management, and network topology
As a standards organization:
Evolve XML-based standards by working with other standards organizations
Promote participation and use of standards
Conclusion
Web services are based on proven Internet infrastructure, XML technology, HTTP, SOAP, UDDI, WSDL, and other industry-standard protocols. They provide service encapsulation and location transparency and are easy to publish and access. Web services makes a very promising and useful technology as it provides a new channel for making products and services available more quickly than ever before.
References
http://dcb.sun.com/practices/webservices/
www-4.ibm.com/software/solutions/webservices/
www.w3.org/
www.oasis-open.org
www.ebxml.org/
Author Bio
Murthy L. Mantha is an independent software consultant based in Austin, TX, focusing on Web services. He has more than 25 years of IT industry experience, ranging from start up companies to major corporations. His experience includes enterprise software architecture for e-commerce systems, Web portals, and other Internet solutions in the areas of automotive, banking and eLearning applications. Murthy holds 2 patents in Internet technologies. mlmantha@yahoo.com
All Rights Reserved
Copyright © 2004 SYS-CON Media, Inc.
E-mail: info@sys-con.com
Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.
|
