- Service-Oriented Architecture (SOA)
- Extensible Markup Language (XML)
- Universal Description, Discovery, and Integration (UDDI)
- Web Services and Other Technologies
- Phases of Adoption
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Web Services and Other Technologies
Now that we have explained the basics of Web Services, it is worth reviewing whether Web Services will coexist or whether they will replace many of the technologies we've discussed. Remember, a WSDL document advertises the methods that can be invoked, and SOAP provides the mechanism for invoking the methods. However, there is still a need to have back-end applications take the SOAP request and perform the processing. This functionality is still provided by some applications, which can be written in a client-server or n-tier architecture. The following scenarios elaborate how existing technologies can be affected by the adoption of Web Services.
Application servers, middleware, and object-oriented technologies. Recall that application servers are written predominantly in Java; it follows that applications using application servers must be written in Java as well. Without SOAP, Java applications must use either RMI (which allows communications only with other Java programs) or CORBA (fairly expensive and difficult to learn) for integration to legacy systems. Most popular application servers now provide SOAP support. Furthermore, through SOAP, applications built with an application server (i.e., Java applications) can now communicate with programs in other languages, regardless of the language in which they are written (provided that language has SOAP support). However, keep in mind that, in many cases, CORBA is still the only viable solution for connecting systems speaking different languages and/or on different operating systems because it defines many features (real-time extensions, etc.) that are not available with Web Services. The key is to determine what needs to be done and address the missing functionality. In many cases, a viable option is to use third party products, such as Web Services networks, to address some of the gaps in the existing standards. We'll talk more about Web Services networks in Chapter 6.
ERP, CRM, and EAI systems. ERP and CRM systems provide the core functionality for many firms and will continue to do so even with the emergence of Web Services. In some cases, Web Services may replace the simpler integration scenarios between CRM and ERP currently addressed by the lower-end EAI solutions. However, as of now, the base Web Services do not address l many of the advanced features found in the higher-end EAI solutions—transaction control, message integrity, queuing, to name a few. For an in-depth look at the types of cases in which it can be beneficial to use Web Services in place of traditional integration, see the case studies in Appendix B. For a more thorough discussion how EAI and Web Services will coexist, see the JCA section of Chapter 4.
EDI. There are conflicting points of view about whether Web Services will make EDI obsolete; quite a few believe that EDI will be around for a long time. First, a lot of money has been invested in EDI by major corporations such as Wal-Mart and General Motors. Furthermore, EDI provides a data exchange mechanism and a set of predefined business processes. As of this writing, without the adoption of ebXML or something similar, Web Services do not address the issue of business processes. For more information on ebXML, see Appendix A.