 |
 |
||
 |
|||
|
 |
CBDI Web Services Roadmap - Guiding the Transition to Web Service and SOA Sponsored by
Sponsored PapersWeb Services Roadmap for the On Demand Business - IBM Vendor Web Services Roadmap Report - IBM. IBM's strategy today is centered around "Business On Deman... more  Service Oriented Architecture. An Introduction for Managers Many Organizations are now undertaking development of service oriented architectures, but the probab... more Modernizing Application Integration with SOA Whilst investment in Application Integration initiatives over the last decade has undoubtedly improv... more |
Web Services Roadmap Planning cont'd...Process Stream
Table 5 - The CBDI Roadmap Framework Ð Process Stream In the early learning stage, Services will be managed as adjuncts to conventional systems delivery processes (such as process design, application development, configuration and deployment etc). However, as Services become the primary mechanism for inter company communication, it will be essential for some considerable process reengineering to take advantage of the service orientation. A fundamental premise of the service is also that there is a provider and consumer, each of whom is executing different processes; the challenge is to align collaborator processes. However in the Roadmap process it is important to differentiate between use of Services as technical interoperability devices, and use as black box components where provider and consumer processes are quite separate. Basic Life Cycle definition A basic life cycle is required to cover use of services in project and integration use. The scope of the basic life cycle is likely to include the following deliverables:
Business Integration (Services as business products) SOA today is a largely technical concept surrounding the creation of loosely coupled services. Further SOA is often regarded merely as a superior way of deploying a component-based architecture - and in their early use of SOA, many organizations will not go far beyond CBD. However the real benefits of services will emerge when enterprises understand the concomitant business transformation that will be enabled. In the old economy, a standard enterprise transforms raw materials and components into finished product. In its simplest form, the business process can be represented as the kind of production line designed by Henry Ford. In the service-based economy, the core business model is no longer based on the conversion of raw materials into finished goods. The enterprise buys in services and sells services, and the core value proposition is the conversion of input services into output services. This calls for a very different kind of business process model, which allows us to see how services combine and interact to make other services. For example:
In considering the Web Services Roadmap, it will be necessary to consider how business services may alter the core and peripheral business of the enterprise(s) in question, and crucially in what timeframe. Today we model requirements using artifacts that are appropriate for understanding how to create applications and components. As our use of services matures, we will need to adapt our modeling techniques appropriately. For example hiding complexity (which is what a service does) yields a gain in manageability, as well as flexibility and reuse. Business analysts should consider carefully which type of complexity is most at issue in a given situation, and choose the appropriate modeling approach accordingly. See related CBDI Reports providing insight on this topic1. Collaborative (Supplier /Consumer) Life Cycle In the early learning and possibly the integration stages processes used to deliver, manage and consume Web and other types of services will be progressive extensions of existing processes and practices. However the real benefits from Web Services will only be realized when the providing and consuming processes are reengineered such that the interdependency between provider and consumer is reduced to the minimum necessary. Figure 3 illustrates that we have parallel universes that are focused on different aspects of the same service. Once an organization has implemented this perspective thoroughly, their ability to use, reuse, outsource, change supplier of services is radically improved.
Figure 3 - The Service Life Cycle Organizations should be responding to a number of drivers as follows:
The scope of the collaborative life cycle is likely to include the following deliverables:
Collaborative specification If businesses are to collaborate using Web Services to support a business process, this raises the question - how is this going to be managed. Obviously we don't want to hard-code Web Service calls into an application, because this will be highly inflexible. Instead, we want something like a scripting language, which will define the wiring between Web Services in a way that can be interpreted and executed at runtime. BPEL4WS, the Business Process Execution Language for Web Services is just that - a workflow definition language that allows businesses to describe complex business processes capable of both consuming and providing Web Services. BPEL4WS represents a merger between two initiatives: IBM's Web Services Flow Language and Microsoft's XLANG. The BPEL4WS scenario can be understood as a programming abstraction of a long-running business transaction or collaborative business process, and is sometimes known as a choreography. For distributed collaborations, a contract between provider and consumer needs to have three parts. The first part of the contract specifies the function of the Service, typically using a series of logical assertions such as preconditions and postconditions. The second part of the contract specifies the quality of service - which are often given the rather dismissive label of non-functional characteristics. The third part of the contract specifies the commercial arrangements, including charging for normal operation and compensation for abnormal operation. At the time of writing the BP scripting languages have very limited support for contractual specification. However in time this will be an area of critical focus, because it will be the mechanism by which we articulate precise obligations between collaborators. This collaboration will be an area for significant process development and improvement in the reengineering stage of the Roadmap. CBDI have undertaken research in this area, and organizations considering process patterns in this area may consult the related CBDI Report2. Certification Service Testing and certification practices require careful examination. Whilst many other issues relating to Web Services may be safely delayed until volume and widespread usage force action, testing and certification need early attention in order to ensure that Web Services are widely used and reused. The big issue is will the service work correctly every time when I need it? A further aspect is that Web Services are by definition designed in isolation from the end user. What we are asking for is the same level of reliability from "ordinary" business components as you would expect from safety-critical systems. We would all like 100% correct components, but what happens when the environment in which that component is being used changes? A component that is 100% correct for internal use can become vulnerable and a weakness when used on the open Internet, particularly when trust levels change. Even 100% correct can be wrong if the specification is wrong. This is a major problem with software in general - how do you test the specification? The Ariane 5 software was 100% correct to its spec for Ariane 4, but was reused in a different environment and caused a 500 million dollar uninsurable rocket launch to explode because of an integer overflow problem. Both computers worked perfectly, both shutdown correctly, and the self-destruct mechanism triggered. Web Services therefore place new demands on testing activity. There are fundamental differences between black box and white box reuse, and whilst we have all paid lip service to black box with components, once we go beyond the boundaries of project reuse, we are forced to operate with full transparency between provider and consumer in the Services world. Testing seems too narrow an expression because traditionally it is limited to activities that take place in the development process, and not during the execution phase, and certainly not prior to every business event. We need some form of active certification that the task has completed correctly with no unwanted effects. This goes beyond simply checking return codes and provides confirmation that the business transaction has completed correctly, which may of course involve multiple parties to validate this. The need for dynamic testing suggests we need to look at each part of the life cycle of a service and identify appropriate testing and certification at each stage. This requires a new framework for testing which might include:
The dynamic aspects of testing XML Web Services require the introduction of testing services in addition to the functional service. These are pre-condition and post-condition checks before and after each functional interface, and could include technical and business oriented testing services. A technical testing service may check that the WSDL complies with prior agreements. A business testing service would ensure transactional integrity. For example if a bank provides a web service function call "fundTransfer(fromAcct, toAcct)", then there may be two additional services required: "checkAccts(fromAcct)" which checks the fromAcct has enough funds, and "checkBalance(fromAcct, toAcct)" which verifies the sum of the two accounts is unchanged. These additional services are specifically checking pre and post conditional states, and designed to validate the correct operation of the core business service. A benefit of separate classification of these services would be to make it easy to manage (the entire life cycle of) these services quite separately from the core business transactions. Publishing Web Services that are intended to be consumer by others need publishing. The extent and quality of the information will reflect the level of separation between provider and consumer, and also the SLA underlying the service. In the early stages of Web Service use, many enterprises find they do not require discovery facilities provided by UDDI, because services are communicated to potential consumers that are already known. However as soon as the service is offered on a broader basis the publishing process needs to expose sufficient information to allow the user to understand the capability being offered and the implications of usage. Published information may also vary depending on the product SLA offered, for example more comprehensive information on the service behavior as a UML model, which may be appropriate to certain classes of consumers. Deployment and Versioning Web Services protocols have no explicit support for versioning. This is not a particular issue while Web Services are being used internal to projects, where provider and consumer are one and the same. But as soon as the provider and consumer are separate entities, and particularly when there is automated consumption, that is no communication other than provided by the WS protocols, then a versioning strategy is essential to ensure that there is good version coordination. It's important not to confuse the version of the implementation with the version of service (interface). New versions of the implementation should be transparent to the consumer. The service interface can of course be extended without impacting existing consumers, and it is common for projects to consider versioning a non issue because of that. But the issue is that you still have to ensure that consumers are made aware of extended functionality. Further there is a question of traceability and supportability. How do you know who's using what and why, and from what point in time? So whilst Web Services, courtesy of XML, are loosely coupled and won't break contracts so easily as tightly coupled services, nether less you still need a change management process to trace changes, notify service consumers where necessary and track usage. Acquisition The technology issues involved in acquiring Web Services are pretty easy. If you are consuming a Web Service on a sold as seen basis, such as an exchange rate calculator, or a weather forecast service, and you are quite happy if it may not be available in the future, or perform in exactly the same manner, then acquisition is easy. Widespread acquisition of services is unlikely to become widespread business practice in the near future however, not because of security, but because of external dependence and the risks associated with placing business reliance upon third parties. But not all services have the same dependence characteristics or profile, and in the table below we provide some thoughts on where you might want to go faster or slower in your thinking.
Table 6 - Service Acquisition Security and trust Security is a core topic in Web Services land. We have discussed security implications in planning & management, infrastructure and architecture. The purpose of a Web Services security architecture is to enable a variety of Web Service implementations to securely interoperate in a platform - and language-neutral manner, and to ensure the integrity, confidentiality and security of Web services. The real issue at the heart of these cases is that our systems automate standard or expected behavior. We omit to implement controls that "monitor" the behavior of systems. We hope that nuclear power stations have these controls, but we don't apply the same logic to business systems. We trap software errors not systems errors. Web services will potentially magnify this problem. With Web Services we will be able to increase the automation of business processes within and across companies. The lesson for Web Service providers is therefore clear - they may be introduced to improve operational efficiency, but must also be complemented with intelligent monitoring and systems controls. The purpose of process activity therefore is to ensure that the architecture is used appropriately. We might expect that the process includes steps such as:
References
Contents...
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
© Everware-CBDI Inc 1999-2008 |
  |