UEU-co logo

Executive Summary

Previous Section  < Free Open Study >  Next Section

Executive Summary

To build Web services, you need to select some products. I wouldn’t be surprised if you found the blizzard of Web services products intimidating. Fortunately, you don’t need a lot of products for your pilot project. At a minimum you need Web services platforms for the client and server environments. Depending on your integration needs, you may need an adapter framework to help you build application adapters. You might also find it helpful to use some XML tools and testing and diagnostic tools.[5]

[5] See Chapter 8 for a definition of these product categories.

When you begin to deploy multiple systems, you’ll start to need a few more pieces. I strongly recommend that you get an operations-oriented Web services management extension. Your operations staff will certainly appreciate it. I also recommend that you set up a private UDDI registry to help manage your service assets, although not necessarily immediately. UDDI becomes more important as your portfolio of services increases and when you want to start offering these services to a wider constituency.

Base Your Selection on Project Requirements

I can’t stress enough how important it is that you select your products based on your project requirements. Before you start your product evaluation process, make sure that you understand your requirements, including factors such as operating platform, performance, scalability, reliability, availability, security, asynchrony, and transactions. Don’t forget to characterize your nontechnical requirements, too. These requirements will influence your core platform selection. They will also help you determine whether you need any additional middleware-oriented management extensions or infrastructure-level services.

Some of the most basic characteristics that I look for in a Web services platform are as follows:

  • Standards support. Standards compliance ensures easier interoperability. At a minimum a platform should support SOAP 1.1, WSDL 1.1, UDDI 2.0, and XML Schema 1.0. Also look for WS-I Basic Profile compliance. If you’re investigating solutions for Java, look for JAX-RPC compliance.

  • Performance and scalability. You need to make sure that the platform will support your requirements. Run benchmarks that represent realistic applications and loads.

  • Security. Figure out what your immediate security requirements are. Also consider what your future requirements might be. Investigate which security features are built into the platform, and which options are available to extend those features. For maximum flexibility, you’ll want support for multiple authentication mechanisms and application-level authorization services. Determine what it would take to integrate the supplied security features with your security infrastructure. Look for support for WS-Security and SAML.

  • Extensibility. Extensibility allows you to add functionality to the platform. I always assume that at some point I’m going to want to make the system do more than originally expected. Figure out which mechanisms the platform has that will help you extend or enhance the platform. How easy is it to write and configure interceptors and header processors? What’s in volved in adding support for emerging standards, such as SOAP 1.2, WSDL 1.2, WS-Security, WS-RM, WSDM, and others? What transports does the platform support beyond HTTP?

  • Development. Make sure that your developers feel comfortable with the environment. What kinds of tools does the platform supply? How well do they fit with your developers’ usual toolbox? How much of the development effort is automated? How often does a developer have to tweak the generated code to make the applications work in real world scenarios?

  • Management and administration. Make sure that your operations staff feels comfortable with the administrative tools supplied. What facilities are available to manage the Web services runtime using your traditional system management framework?

Don’t just blithely believe the vendor claims. Run your own tests and benchmarks. Experiment with multiple products. Most vendors will give you a free evaluation period. Get feedback from both your development staff and your operations staff. Make your vendors give you references. It’s especially nice if these organizations are doing projects somewhat similar in scope to yours. Take advantage of these contacts to learn whatever you can. Join user groups. Participate in discussions. Make the effort to get educated.

Charting Your Course

I hope this book has been helpful to you and that you are now prepared to start your voyage. My advice is that you take it easy and start slowly. Identify a noncritical but reasonably visible project. For your first pilot, I suggest that you choose a simple point-to-point integration project. It will give you a chance to learn the basics about the technology. Make sure that you constrain the scope of the project. Break it into attainable tasks, and chart your course.

Don’t build Web services just because they’re cool. Make sure that you have a viable business model to go with the service. As a rule, your Web services should support or augment your existing business model. Web services should do things such as enhance sales, improve customer relationships, simplify customer or partner interaction, and streamline business processes.

Don’t get distracted by the software-as-a-service business model. If you don’t have a viable ASP-style business model today, Web services won’t help you create one. If you do have a viable ASP-style business model, you should definitely use Web services technology to provide programmable Web APIs to the business service. Just keep in mind that you are selling a business service, not the Web service. The Web service is simply one of many mechanisms you provide to your customers to use the business service. The technology and the business model are separate things.

For the time being, I recommend that you focus on integration. First and foremost, Web services help you integrate applications. And they do so at a fraction of the cost of traditional middleware technology.

After you get comfortable with the concepts, you can start tackling some really high-payoff initiatives.[6] Here are examples:

[6] See Chapter 7 for case studies of high-payoff initiatives.

  • Use Web services to support collaboration, allowing your people to more effectively share information so that they can be better and more efficient at their jobs.

  • Use Web services to give your staff a 360-degree view of your customers, resulting in higher productivity, stronger customer relationships, and lowered attrition rates.

  • Use Web services to integrate your business process across departmental and organizational boundaries, eliminating friction, reducing costs, and improving quality.

  • Use Web services to provide programmable access to your business process for your customers and business partners, making it easier for them to do business with you and producing higher sales.

  • Use Web services to consolidate redundant application systems, resulting in substantial savings from streamlining systems operations and increasing process efficiencies.

  • Use Web services to make it easier to manage your legacy application assets, significantly lowering the total cost of ownership of these systems.

  • Use Web services to coordinate your portal initiatives, making it easier for your staff, your partners, and your customers to interact with you. Web services also make it easier for your portal to support multiple user access channels such as IVR and the wireless Web.

I’m sure you can think of other ways to exploit Web services. They have enormous potential. Web services simplify integration. Integration helps your business operate better. Think of Web services as lubrication for your business.

    Previous Section  < Free Open Study >  Next Section
    Tags:  , , ,

    Leave a Reply

    Time limit is exhausted. Please reload the CAPTCHA.


    apply_now Pepperstone Group Limited