CBDI Forum CBDI Web Services Roadmap. Guiding the transition to Web Services and SOA
 
eLearning

Applying Web Services cont'd...

Where to Apply Web Services

Whilst we expect to see a gradual adoption of Web Services across all connectivity scenarios, we fully expect organizations to adopt a "if it ain't broke, don't fix it" attitude, and extension not replacement will be the de facto strategy.

In the short to medium term organizations will be looking for the sweet spots in which to use Web Services, where there are clear advantages or where Web Services provide a solution not really viable with the existing technologies.

In this section we provide a framework for identifying these sweet spots.

Business Characteristics

Table 2 examines some of the characteristics of business processes that might be best supported by the applying Web Services.

Business Characteristic Reasons to Apply Web Services
High number of participants
  • One to Many
  • Many to many
  • Multiple intermediaries (business and infrastructure)
  • Federated
    		•  Increasing likelihood of diverse technology across participants, and/or unknown technology at other end of wire

    Support for Federation
    Cross Functional
  • Process or information need spans many business units, organizations
    		•  Diverse technology
    External integration
  • Need to integrate customer or partners
    		•  Increasing likelihood of incompatible technology between provider and consumer and likelihood that technology at other end of wire is unknown
    Real time information need
  • Provide real time access to remote information
  • Improve the accuracy and timeliness of information
  • Retrieve information on demand from source rather than replicate
    		•  Enable direct access to core operational systems, rather than cached or replicated data which is out of synch
    Automation
  • Application to Application
  • Repetitive, well defined processes, rules and information
    		•  Provide automatable interface, rather than self-service browser interface

    Human intervention for exceptions, not for every execution
    Dynamic Provider/Consumer marketplace
  • Dynamic selection of new service providers
  • Self subscription of service consumers
    		•  Richer specification of Service

    Programmable specification enables automation of service consumption in applications
    Dynamic Process
  • Reconfigure business process on demand
    		•  Enable runtime selection of service and/or provider

    Table 2 - Business Processes Characteristics suitable for Web Services

    Looking for Boundaries

    Another useful selection process is to identify where processes have to cross what we term "boundaries". Where change might occur independently on either side of a boundary, then a loosely coupled approach (as offered by Web Services) to any connections across those boundaries can better facilitate those changes. Whereas within the boundary existing proprietary or platform specific technologies and approaches can continue to be used, and may be desirable for performance or SLA reasons.

    An organizational boundary is an obvious candidate as the participants on either side of the boundary need not be forced to adopt the same technology to interoperate. But this can true for divisions and business units within the organization too. As well as organizational, other obvious boundaries are technology and application architecture as illustrated in Table 3.

    In time this concept may become redundant as all communications simply become based on Web Services. In the meantime, identifying boundary points across which Web Services are most suitable is a useful starting point for Web Services adoption.

    Boundary Use of Web Services
    Organization External interfaces to customer, partner, etc use SOAP for loose coupling to remove technology independence
    Division/Business Unit Internal interfaces to other business units use SOAP. Loose coupling supports potential for outsourcing, spin off, etc as Organizational boundary
    Sub Assembly (grouping of related objects and components) (e.g. Customer) Internally uses native platform protocols to communicate between low level interfaces, but interfaces external to the sub assembly are SOAP to facilitate integration into multiple systems.

    Enable sub assembly level replacement or upgrade

    Enable outsourcing of business functionality at sub assembly level (e.g. logistics)
    Application As sub assembly.

    Enable Application level replacement or upgrade
    Application Layer Communications across layers such as presentation, business rules and data, or client/server use SOAP, but use platform native protocols within the same layer
    Platform Communication between components on same platform use native protocols, whereas communications to different platforms use SOAP

    Table 3 - Candidate Boundaries for Web Service Adoption

    Exploitation Scenarios - Capitalizing on Web Services

    Beyond the conversion scenarios outlined above, there are three exploitation scenarios based on re-engineering business processes:

    1. Reengineer Selected Information Flows

      2. Using the more conventional approaches outlined above, but reengineering the way information flows through the business process.

    2. Use Breakthrough Technology

      3. Taking advantage of new capabilities offered by Web Services, particularly their support for more dynamic usage scenarios via

    3. Convergent Technology Strategy

      4. Implementing Web Services in conjunction with other emerging technologies (which are themselves becoming increasingly Web Service based) such as

         a. Pervasive Computing
         b. Grid Computing
         c. "On Demand", or "Utility" Computing
         d. Autonomic Computing
    Or of course some combination of each.

    Re-engineering Selected Information Flows

    Web Services can be used to optimize and change what we term the Information Supply Chain - i.e. we don't change the physical participants in the supply chain, but we do change how information flows between them. The following shows a couple of examples of how we might consider re-engineering firstly data sharing, and secondly process execution to improve information flows.

    Data Sharing

    With the capability of semi real-time, wide area interoperability, Web Services have the potential to enable breakthrough solutions. Some of the most interesting early case studies of Web Service adoption have been about radical improvement in data availability.

    Today, data is commonly replicated by a plethora of diverse mechanisms amongst the participants in business processes. A conversion scenario might use Web Services to enhance the replication process.

    Whilst this would simplify and standardize the way in which data is transferred, the use of Web Services per se doesn't fully remove synchronization problems, nor does it necessarily improve the accuracy of information presented to a particular participant unless other participants replicate changes the moment they occur.

    Figure 1 illustrates how participants might share the same single source of information using a Web Service so that all information is up to date. This is not to suggest that all participants now consolidate all their data in a single shared database. Rather it is the principle of each participant sharing the data they truly own and who's responsibility it is to ensure that data is timely and accurate.

    Figure 1 - Data Replication or Data Sharing?

    Advantages

    • Timely and accurate information
    • Reduction on in-house data storage requirements

    Suitability

    • Fast changing data where changes should be made available ASAP to other participants
    • Large volumes of reference data that would otherwise need to be stored in-house

    Shared Collaborative Processes

    The next logical step is to ask if participants are going to share the same data via Web Services, should they also consider sharing processes too? Today, not only will the participants be replicating data, but will often use that information in similar systems. In an exploitation scenario, rather than duplicate functionality in-house, organizations could share their processes as well as data. This is not the same pattern as Application Solution Provider (ASP), as the process is shared between all participants, rather than each of them just outsourcing their own. However, it may well be that a 3rd party such as an ASP would be ideal for hosting common shared processes as Web Services.

    The BPEL protocol is suitable for this scenario.

    Advantages

    • Process and business rule consistency
    • Reduction of in-house processing requirements
    • Reduction of in-house configuration management

    Suitability

    • Common processes that are not the source of competitive advantage

    Of course in both the above cases, whilst Web Services might provide a solution to current problems they introduce new challenges of their own. Common objections to the above scenarios would be security, SLA, scalability, and the risk of basing core systems on external dependencies. Whilst these must be weighed against the business benefits, we would also observe that apart from the additional communications factor that would be introduced, the same objections are also unfortunately often true of in-house systems, and the current replication process. For small organizations in particular, an external entity may be able to offer a more secure, scalable, robust solution than they could afford to operate in-house, enabling them to focus resources on the core processes and data which are unique to them, and they in turn will be offering to others as services.

    Additionally it clearly requires some level of process and semantic standardization amongst participants, though replication requires this to some degree already. Moreover, where the participants are involved in many-to-many relationships with each other it requires industry wide agreement. See "managing participation" later in this document.

    Re-engineering like this is likely to occur slowly, and probably take place between a limited number of very close partners before spreading out across all participants. In some industries, dominant participants might be able to force the change if they think it desirable. That said, there are already some examples of organizations providing Web Services as an alternative way to access information they own and which they normally deliver via replication.

    Use Breakthrough Technology - Dynamic Web Service Consumption

    One of the main advantages that Web Services offer over most existing application connectivity mechanisms is that consumption of Web Services can be resolved more easily at run time, and not just at design time. Two key elements of this are

    • Rich specification, or "Self Describing" interfaces, which can be accessed programmatically to understand what a Web Service does and how it should be used
    • Publication and Discovering mechanisms to announce and locate required Web Services

    These elements can be built into applications themselves so that they can effectively discover and use new Web Services at runtime. However, most organizations are currently skeptical of any notion that Service consumers might appear to randomly and anonymously discover and use the provider's Services. They point out that in most cases, the necessary business relationship has to be in place long before any use of Web Services is appropriate, and as such any need to discover and consume the provider's Services at runtime is a moot point.

    This is a valid point. However, in certain industries some common standard business transactions may well be suitable for this scenario. For example in the auto insurance industry where most insurance companies already provide a near universally similar "service" for insurance quotes via their web sites or call centers (i.e. some minor variation on give me the vehicle ID, your ID, and your location, and I will give you a quote) could easily be adapted to a Web Service scenario whereby my personal finance application running on my PC could each year automatically include new insurance companies in the list from which to get quotations. Though whether insurance companies really want to enable such an easy form of price comparison is of course a different question.

    Advantages

    • Remove developer effort to consume new Web Services
    • Flexibility of choice in Service provider, resolved at run time

    Suitability

    • Common, standardized business services

    Convergent Technology Strategy - Autonomic, Grid and On Demand Computing

    An alternative use of the dynamic Web Service scenario outlined above is to support Autonomic, Grid and On Demand Computing. Rather than use the dynamic capabilities to discover new service providers, instead they can also be used to discover and consumer new services from a known provider - and of course internally. These might be used for

    • Failover and backup. Publishing, discovering and using alternative routes to, or instances of a Web Service in the event of failure. i.e. Self healing systems
    • Scalability. Publishing, discovering and using additional instances of a Web Service to scale up at periods of high demand
    • Versioning. Publishing, discovering and using new versions of a Web Service
    • Location Transparency. Moving the implementation of a Web Service without impacting the service consumer

    Given the current business reticence to use the dynamic Web Service consumption scenarios mentioned previously, it is probably that in the medium term much wider use of the dynamic nature of Web Services will be seen in the Autonomic, Grid and On Demand arena.

    A more detailed look at the use of Web Services in the context of this is provided in "Web Services Roadmap for the On Demand Business". 2

    Advantages

    • Reduce developer effort, and time to solution via self healing, self discovering systems
    • Reduce Web Service configuration management

    Suitability

    • Failover. Scalability, etc are required for all mission critical Web Services
    2. Web Services Roadmap for the On Demand Business

    Contents...


    Previous Page Next Page
    eLearning

      © Everware-CBDI Inc 1999-2008