New business processes typically must be web service-ready, as they're expected to communicate in a bidirectional manner with service-orientated technologies such as BPEL and ESBs. Today, BPEL process managers using web service interfaces have become a core component for business process execution and integration in service-orientated infrastructures. Traditional ESBs have been messaging-based proprietary platforms, but are focused more on providing integration through web service interfaces. In both the BPEL and ESB cases, web services are being positioned by IT vendors and industry experts as the 'holy grail' of Enterprise Information Integration (EII). The IT vendor's answer is to make your applications, data, and processes web service-enabled, and your EII and EAI woes will all be addressed. However, there are some potential issues with using web services for all integration needs:
Performance: The XML-based messages that are exchanged when using web services can lead to performance problems on several fronts. The first area is that the XML message must be built using expensive CPU cycles and memory on the source machine. On the receiving end, due to web services using XML to exchange information, these documents require marshaling of the request or the message being sent, and de-marshaling (essentially reading the message that was sent). Processing the XML message requires more CPU resources, and potentially larger data storage than a typical integration approach would consume.
Network: XML is an ASCII-based (human-readable text in a document) and contains the data definition tags inside the XML document along with the data payload. This can cause the internal network to become saturated with web service XML-based integration traffic. For external web service network interaction, the situation is worse because you may have a slow network where bulky XML-based communication can perform very poorly. Even if the network is fast and can support a lot of bandwidth, the XML documents travel over HTTP, which is not optimized to work with the underlying network protocol which is TCP/IP. In addition to the current integration solutions, you may just use TCP/IP, by introducing web services into the current architecture where you have two communication protocol layers (HTTP and TCP/IP) as opposed to one (TCP/IP).
Not everything can be made a web service: DOS Windows-based application or C applications are two examples of applications that don't have web service capabilities built into them. You can use products from companies like Seagull Software to make these applications web service-enabled; however this entails purchasing, learning, and maintaining a new product. Technologies and languages that are not easily web service-enabled may be better served by keeping the current custom-built application point-to-point integration solution, using message-based products, simple flat file transfer using FTP, or some other product like an ETL/ELT solution.
Current integration solutions: It is safe to say that your company currently uses a number of custom and vendor-based integration solutions. These solutions are not going to disappear from the corporate landscape any time soon. Some of these solutions may not even support web services. These current solutions still need to be leveraged for years to come as you migrate to a web services approach to integration.
These potential issues may not be a concern, based upon the hardware are you using, the types of languages your applications are written, in the network bandwidth at your company, and the number of legacy integration solutions.
It is always important to learn from past lessons. Remember Enterprise Java Beans (EJBs), built for remote invocation of Java objects across the network? The EJB standard was intended to solve the issues related to application integration by making it easy for Java modules to integrate. 'Easy' is a relative term as learning and implementing EJB technology was not necessarily easy. EJB interfaces and communication implementation assumed that EJBs would be calling other EJBs in other locations; remote application integration. The issue was, that when most companies deployed EJBs they discovered that in a majority of cases EJBs were communicating with EJBs on the same machine or at least within the same company. EJBs incurred a lot of internal processing and communication overhead was required for remote invocation when in most cases this overhead was not necessary. So, Plain Old Java Objects (POJOs) came along which did not have the overhead of remote communication and building remote interfaces. POJOs are built to use Inter-Process Communication (IPC) and assume that both Java objects will reside locally in the same hardware infrastructure.
The authors are not implying that web services are going the way of EJBs. Web services are here to stay and continue to gain momentum as the leading EII and EAI technology. However, you should be aware of the four potential issues, listed previously, with web services and watch what leading IT infrastructure vendors do to address these issues.