 |
 |
||
 |
|||
|
 |
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...Architecture Stream
Table 4 - The CBDI Roadmap Framework - Architecture Stream In the early learning stage, Web Services will typically be adopted in a tactical manner. Architecture is not a significant issue. As an organization moves forward it is looking to integrate Web Services into core business processes, to progressively establish the service as the unit of reuse across an organization. The Architecture stream provides a clustering of topics and deliverables to support this activity. Service Oriented Architecture SOA is the broad set of concepts that enable units of functionality to be provided and consumed as Services. This essentially simple concept can and should be used, not just for Web Services, but also at each tier of the architecture, in order to compartmentalize and provide flexibility. Establishing a service oriented architecture is a foundational activity that forms the basis for a more adaptable application portfolio, exposing core functionality as Web Services. CBDI advise that creating an SOA is a medium term project, which implements services to a common bus structure (policy, semantics, middleware). This is typically an integration stage Roadmap activity, and should be viewed as an essential pre-requisite for the reengineering Roadmap stage. More details in the CBDI Roadmap report - Moving to SOA. Trust & Security Architecture Application publishing and using Web Services require a new layer of security that is separate from the network firewalls, which in the main can do no more than block unwanted protocols and rogue IP addresses. There is an interesting conflict that in order to empower an application, the credentials and encryption capabilities have to be moved nearer to the code and away from the infrastructure. But, to maintain a clean separation of concerns the service implementation must be clearly separated from the security management layer. The new SOAP protocols for WS-security allow an application to deal with data that is private, right from the point of entry, all the way through to the point of delivery, and even then it can remain encrypted in storage. Similarly, authentication is end-to-end, from the individual that signs the request right through to the business process that checks the ID. This is how you do conventional business - you sign the check, not the postman. In the Plan & Manage Roadmap Stream we identify the business and technical policies that drive the application specific security. Here in the Architecture Stream there is a requirement for clear architectural guidance in various forms, to ensure conformance with the policies and clean separation of concerns. Business Service Bus In the days when middleware was top of the technical architect's toy box, the notion of the transaction bus was very popular. But whilst this is a necessary layer, it's equally if not more important to develop the concept of the Business Service Bus. The Business Service Bus is the set of business services for a specific domain that are available for widespread use across an enterprise. The services are published in a UDDI compliant registry which allows them to be reused without manual intervention by the provider. The creation and particularly the population of the BSB is an important step towards service maturity, which facilitates widespread reuse of common services. Redefining the Application Application scoping has always been an imprecise science for end user enterprises and ISV's. In the end result many projects are scoped around a compromise of functionality and commercial/budgetary considerations that makes most sense at the time. In the initial stages of service usage, the service is simply an appendage to existing applications. However the service concept is closely related to the business process; some say the service is a business process. Over time therefore sets of service will become the natural focus of application investment and scoping. Why over time? Because there are relatively few applications being built from scratch today, and it will take time for services to be incorporated into existing portfolios, to a point where there are service based artifacts available as a basis for planning. Governance framework An important aspect of SOA is the question of how to ensure architectural decisions get implemented - otherwise known as the governance issue. Each architectural deliverable can be attributed with governance roles, for example - standard or guideline, mandatory or optional. These roles then have applicability to specific domains which might include platform, product, layer, application, relationship etc. Governance may then be managed by a variety of mechanisms which include patterns, templates, common components, common services, protocols, semantics, products and practices. Shared usage Creating services for use by multiple consumers has all the complexities of creating common components, and then some more. This is a major area of architectural consideration, which will need to be planned for each application and service set. The first thing to think about is generalization of functionality. This is one of the primary issues in the integration Roadmap stage, because the level of generalization is determined to a large extent by the existing applications. Some level of generalization and transformation can be built into the facade and business process scripting layers. However this may not be possible without expensive, invasive modifications. So in the early stages there may be considerable compromise required. CBDI defined the concept of the differentiated service1 as an important pattern for service architects. The differentiated service is a device for managing reuse of common services in a context sensitive manner. This pattern may be used to simply reduce the number of interfaces, and to increase the applicability of an individual service offering. More importantly the pattern will be applicable to design guidelines for security and productized business services. Semantics Web Services enable wider involvement in existing processes and or wider use of standard services. These developments require that the users have a common language system. In simple domains, it may at least be theoretically possible (even if often impractical or technically inappropriate) to establish a single shared (global) data model, so that all local models are mapped to the shared model. In complex domains, which means most large enterprises, this isn't even theoretically possible. There is no top-down approach, because there is no single agreed place that is the "top" - merely lots of different stakeholders each of whom thinks the world revolves around his agenda. Many organizations have commenced some rationalization at a document level as they implement XML based transfers between systems. However many of these implementations have been achieved using transformations rather than rationalization. A key architectural task for organizations preparing for widespread usage of Web Services is to establish the policies and practices that lead to rationalization where it makes business sense, and for coordination of different stakeholders views. In the CBDI Report on Data Collaboration2, we examined how a distributed business process can be understood as a series of collaborations or conversations between different stakeholders. Each stakeholder has a context, which can be expressed as a local data model. This leads to defining firstly the documents that represent the exchange of information and services between stakeholders, and secondly the process wiring that bridges between the multiple contexts. We look at the techniques for doing this, and the implications for decomposing requirements into discrete services? Protocol coordination Whilst it is probable that there will be universal consensus around the transport protocols, SOAP and WSDL, it is by no means certain that this acceptance will apply throughout the entire Web Service stack. Although ebXML has adopted the transport protocols, it is entirely feasible that it will continue to occupy a niche, particularly in business contract descriptions. Likewise there is no evidence yet of agreement around BPEL, WSCI etc. Each organization needs to select the combination of protocols that are likely to be most applicable in terms of functionality and acceptance within the ecosystem relevant for that enterprise. Information Ownership Replicated data is the industry convention. We replicate because there has been no sensible alternative. Yet replication is an inherently weak and error prone model that causes inconsistency, complexity and huge costs. Web Services based interoperability offers interesting solutions to this problem as the new SOAP based Internet standards enable pervasive accessibility. We don't suggest that all data replication will or should be eliminated, but we do anticipate opportunities to simplify and improve business processes that architects should be looking for right now. Over time data distribution will migrate towards the point of ownership, or a proxy of same. Rather than every organization replicating and maintaining copies of the data, real owners of the data will maintain it themselves and make it accessible to everyone who needs it. Your bank does not 'own' your name and address, nor does the retailer, but you do as an individual. They do own the transactions you make of course, but this is an intersection between their products and you. What if instead, you maintain your personal information in one location and everyone retrieves it from there at the time they need it? All any interested parties have to do is store the URL that you give them and then retrieve up to date information whenever they need it. Not every piece of information needs to accessible in real time. Where it is appropriate the migration to a Web Service will still be gradual. But this is a progressive process which will be driven by business opportunity and need. An important part of Roadmap planning is therefore to prepare for the progressive change, a) by providing the infrastructure to allow data migration and b) working with business units, partners, customers and suppliers etc to improve the currency and accuracy of data using Web Service based architectures. There is comprehensive treatment of this topic in the CBDI Report Will Web Services Revolutionize Data Distribution?3 WS Based BI Strategy Web services are being widely discussed for integration of operational business processes. Many enterprises are starting to deploy Web Service technology for connecting applications internally. Whilst there is significant interest in deploying the same technologies externally, this is currently inhibited by concerns such as security and reliability. Meanwhile, the use of the Internet as a platform for business intelligence (BI) is becoming more mature and sophisticated. There is an important role for Web Services in the business intelligence space based on the capability of creating real time, rules driven information access services, which can potentially deliver real business benefit even with relatively unsophisticated WS technologies. At the core of most BI systems are software products providing query, reporting and analysis functionality, sometimes referred to as OLAP. Traditionally, these functions have been based either directly on operational systems, or more commonly on a data warehouse or data mart, which assembles and restructures data from one or more operational data stores. The result of the data combination can be stored in another data store, or may remain virtual. However business intelligence should be viewed as a closed control loop system where managers use tools to process and interpret information; they then act upon this information and monitor the effects of their actions. If the actions have the expected effect on business performance, this helps to confirm the original interpretation; if management intervention doesn't work in the expected way, then this should trigger further analysis. This management feedback and learning loop is a key element of true business intelligence. It is also important to provide a context for making sense of events and trends. Regular readers of CBDI reports will recall our analysis of the Kodak case4, in which the online retailer found itself obliged to supply a large number of digital cameras at an incorrect price. Real-time business intelligence can help identify a sudden increase in demand for a given product, and may place some constraints on automatic supply until the increase can be explained. But we need some context for this. It is only when we can link a sudden increase EITHER to a marketing campaign by Kodak OR to some hostile activity on an internet newsgroup that we know what to make of it - and therefore how to respond. For more information on this topic see there is fuller treatment in a related CBDI report5. Though several core WS protocols are in place and/or in progress through standard committees, a broader set will continue to emerge and evolve to support the needs of Enterprise level Web Service and other scenarios. Many organizations are implementing their own protocol compliance guidelines in order to facilitate early learning activity. It will make sense to adopt the WS-I profiles as they come available, although it will still be necessary to have some level of coordination on what profiles are being used at any point in time, and also any local overlays that are applicable. Interoperability will continue to be a minor problem in the Early Learning stage. References
Contents...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
© Everware-CBDI Inc 1999-2008 |
  |