Web Services: (Some) Order From Chaos
Thanks to software's Holy Trinity (Microsoft, IBM, and Sun), the mythical healing powers of Web Services may now rival those of the True Grail; Web Services reality is almost as elusive, but far less mesmerizing. First (and foremost), standard, consistent interfaces are good; they promote harmony, a sense of well-being, and general mental health amongst the programmer ranks. Second, contract-based programming is and always will be the best way to make systems that were never intended to work together do so. Third, a lot of smart people have invested a lot of time and effort in making things like TCP/IP, HTTP, and XML work very well (okay ... scalable, reliable, extensible).
Figure 1:
Taken in this context, Web Services is a no-brainer as a standard mechanism for providing access to enterprise applications and data; this will allow businesses to create words out of alphabet soup (ERP, SFA, CRM, EAI, EJB, COM, BFD). Sure, there are holes in the specifications, and not a little bit of brinksmanship at work when it comes to implementation languages and run-time environments, but it'll all get sorted out; remember, a rising tide floats all boats. However, this is only one factor in a complex equation; nothing about Web Services addresses the front-end complexity of dealing with multiple channels, such as supporting disconnected devices and asynchronous interaction models that are required by wireless and mobile connectivity.
This is Part 2 of a 2-part article on how Software Technology is evolving toward Multi-Channel Interaction Servers.
Part 1 discussed the changes in Software Technology that are leading to this.
Introducing the Interaction Server
Abstraction is the time-honored approach to dealing with software complexity. When things get too squirrelly for the mortal mind to comprehend (5 to 7 things + or - 2, remember?), you can always count on someone to break the problem apart and wrap up the hard stuff in a (seemingly) elegant package. This is the historical evolution of enterprise architecture, from monolithic mainframe to distributed client/server to multi-tier web apps. We've now reached the juncture where the interactions with our systems have become too complex to manage as part of the applications themselves; like salmon swimming upstream to spawn, we as system architects must abstract.
But what is this new layer of abstraction? Since it manages system interactions, it seems logical to refer to it as an Interaction Server, similar to its predecessors, the Database and Application server. This parallels widely accepted, logical separations in software architecture between data, business logic, and presentation.
The Interaction Server hosts a run-time container to manage interactions between multiple connected and disconnected devices and channels (e.g. HTML browsers, mobile phones, PDA's, Voice, Web Services) and the systems that support the enterprise. Such interactions can be simple requests for information, or complex, multi-step business processes that touch many back office systems and have transactional implications.
Interaction Server: The Front End
The Interaction Container provides critical services in support of the user-facing aspects of multi-channel interactions:
- Security & Single Sign-on: A consistent mechanism for authentication & access control across interactions
- Device & Channel Detection: Information about device capabilities and connection quality
- Data Transformation & Validation: Externalized rules for translating and validating interaction data
- Presentation Management: Creation of user interface content and interaction navigation, including:
- Identity (Who am I?)
- Context (What is my role? What am I trying to do?)
- Personalization (What are my preferences?)
- Localization (Where am I, and what implications does this have to what I'm trying to do?)
- Extended Session Management: Transfer interactions seamlessly across time and devices, for operating efficiency and to
mitigate connectivity issues
- Data Synchronization: Support disconnected devices via "store-and-forward"
- Notification: Alert users (or systems) via one or more channels when critical events occur using configurable
profiles
Interaction Server: The Back End
Composite Interactions will implement new business processes, generally including one or more system interactions. In support of this, the Interaction Server will provide the following capabilities:
- Web Services: Consume and produce (host) Web Services as the standard means of system integration
- Business Context Management: Manage the execution of the interaction, including:
- Business Process Flow
- Business Rules Expression
- Business Events Sensitivity
- Asynchronous Processing: Efficiently manage long-running interactions, complex operations, and disconnected devices
- Transaction Management: Interact with XA-compliant sources to ensure operational and data integrity
Finally, the Interaction Server must incorporate a visual development environment with powerful tools for rapid enterprise interaction assembly, deployment and management, and must interoperate with standards-based, third party products that provide system monitoring capabilities.
Figure 2:
Conclusion
Change to our fundamental system assumptions has reached critical mass, and we are in the midst of an inflection point for software technology. Every enterprise has or will become a web of multi-channel interactions, and traditional Internet architectures are inadequate for this next generation of systems.
Most extension strategies exacerbate the "accidental complexity" that ultimately paralyzes most businesses, the disastrous tendency to build stovepipes and point-solutions to address new requirements. Only through composite interactions can you unleash the value of existing systems and applications.
The Interaction Server is inevitable; it's the natural evolution of enterprise integration architectures. As with any thorny problem, it's best to deal with interaction and integration issues now; it will only get more difficult and costly with time. While many will look to current industry leaders for solutions, the incumbents are too distracted to innovate; history illustrates that a new leader will emerge.
This concludes Part 2 of a 2-part article on how Software Technology is evolving toward Multi-Channel Interaction Servers.
Part 1 discussed the changes in Software Technology that are leading to this.
About the Author
Greg Rollins, Director of Product Management for Cysive, Inc. has been involved in enterprise architecture, design and development for over 20 years and has worked on some of the largest enterprise Java systems developed by Cysive for clients such as Cisco, First Union, and AT&T. Greg sets the technical direction for Cymbio, Cysive's Interaction Server for developing, deploying and managing the complexity associated with supporting today's multi-channel (web, wireless, voice, and web services) enterprise applications.
For more information visit www.cysive.com.