We are looking at some internal projects that definitely need EAI but may not need Web services. What factors do you feel might make a Web services-based solution more appropriate within the enterprise?
Click for part 1 of this answer.
We've been dealing with this paradigm for years as component-oriented programming, where many predefined application components combine to create a single application. However, within the notion of Web services, the application components reside on a remote computer, and the Web services are accessed as a piece of an application. For instance, the master application that monitors shipments invokes a series of Web services (running on remote computers) that provide application services for logistics processes, least cost routing, billing, etc. Going forward this will be the most popular architecture for Web services since it's closest to the concept.
Autonomous-distributed solutions refer to those architectures where the Web services are so tightly coupled that they appear as a single application. This is the final destination for Web services, binding many applications together, inter- intra-company, into a single unified whole. However, we are years away from the proliferation of this architecture.
Finally, the enabling technology is morphing to accommodate Web services. In addition to development tools that support the creation of Web service-enabled applications, we're seeing "traditional" application integration products moving to Web services through the addition of several new features. These include the creation of new adapters that provide service level (as well as information level) access to remote systems, method binding mechanisms innate to the server, and interface aggregation to support the combination of many Web services into a single Web service.
Most adapters were built to support simple information exchange, and don't support access to remote methods. These adapters will have to learn how to access application services, abstracting the interface within the integration server. We'll begin to see new Web services-enabled adapters sometime in the near future. However, it does not make much sense to create application service-enabled adapters without an integration server that can process Web services as well as information. This is bit more complex. However, we are seeing next generation integration servers that have the ability to process Web services as well as information, aggregating services within the integration server as required. For instance, combining several Web services into one, or passing Web services access between systems. What's more, Web services-enabled integration servers provide enabling mechanisms including WSDL and access to UDDI.
Dig Deeper on Topics Archive
Related Q&A from David Linthicum
David Linthicum explains what advanced business application programming (ABAP)/4 means. Continue Reading
David Linthicum defines Service Component Architecture (SCA) and Service Data Objects (SDO) and explains how to best build these components to enable... Continue Reading
David Linthicum explains how it is possible that Apache Tomcat is both a Web server and an application server. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.