Position Paper for W3C Workshop On Web Services |
||||||||||||
Reuters Position |
||||||||||||
Reuters core business is information and transactional services (view and do paradigm). As a global information, news and technology group, Reuters supplies news, information and value-added services in more than 20 languages to over 1400 websites worldwide. In addition, Reuters plays a significant role in the functioning of the financial markets. Reuters mission is to make the financial markets work on the Internet on a global scale. Reuters leverages the Internet by applying proven architectural models (eg, application or end-to-end service provider) to their own unique requirements. This strategy encompasses providing financial online trading and information services (eg, risk management or securities trading) by migrating traditional desktop applications into to a more flexible service-based architecture, ie. an architecture decomposed in to end-user services, business process services and data services From Reuters perspective, the concept of web services appears to be an ambitious, innovative and more importantly achievable approach to clarify, simplify and resolve the ongoing discussion within Reuters. A marked up description of web services can help to communicate web services among the business and technology side. Thus, a common and standard web service description would act as a catalyst especially during the early phases of a software project. From a technical point of view, web services can be seen as an application API that can be invoked by an Uniform Resource Locator (URL). The service may be delivered via the Internet or indirectly via other means. In contrast to traditional services, web services can be dynamically integrated into a business process at runtime. Ie. removing the need to bind to rigid programatic interfaces. |
||||||||||||
Reuters Web Service Challenges |
||||||||||||
Web services are of strategic importance for Reuters and its clients. However, there are a couple of challengers Reuters has to face during the development and implementation of web services, such as: Standardisation: It is quite likely that almost every software will provide some kind of web services in the near future, eg. monolithic solutions can be web-enabled by implementing a web service relevant Application Programming Interfaces (API). The current available set for implementing web services so far includes Simple Object Access Protocol (SOAP) [M+00] for remote synchronous and asynchronous service invocation, Web Services Description Language (WSDL) [AIM00] for service description and Universal Description and Discovery Initiation (UDDI) [UDD00] to catalog available business and web services. These proposals are mainly driven by leading software vendors, such as IBM, Microsoft and Ariba. However, none of these efforts have been officially accepted by a standards body, such as the World Wide Web Consortium (W3C) or the Internet Engineering Task Force (IETF). At this stage, it is very important to keep the redundancy among the proposed standards to a minimum. Similar initiatives, such as ebXML [ebX99] registries, RosettaNet [Ros98] and UDDI do not converge yet in a unified standard. Scalability & Availability: The total number of installed web servers world wide will soon exceed 30 million. In addition, it is quite likely that each web server will host several web services. These web services will be registered, deployed, requested and provisioned by other web services or client applications. Thus, a web service registry, expressed in eXtensible Markup Language (XML) requires sophisticated search capabilities. In contrast to a domain name service (DNS), a web service registry can offer multiple search keys, such as company name or geographic location. Finding web services can be quite crucial, if the web service registry contains thousands of entries and if the registry has to cope with thousands of concurrent clients at the same time. Interoperability: Web services can almost interact with any other web service. That means, secure protocols provide the infrastructure for accessing and invoking distributed web services. Furthermore, web services can be composed of other web services, eg. a product purchase web service could orchestrate the usage of base web services, such as credit card validation or billing. These web services need to exchange semantic details about the web service or other quality of service details. Transactions: Traditional transaction systems use a two-phase commit approach, ie. participating resources are gathered and then locked until the entire transaction can take place. Finally, once the transaction completed, all participating resources will be released. This approach works ideally in a closed environment where transactions are of a short duration. However, in an open environment the duration of a transaction can hardly be assured or predicted. Proposed standards like XAML [XAM00], an upcoming XML markup language for supporting traditional transactions is already addressing transactional related issues within web services. Security: Some web services will be publicly available and unsecured, but most business-related services will use encrypted communications with different authentication models. It is likely that Hypertext Transfer Protocol (HTTP) over Secure Sockets Layer (SSL) will provide basic security, but individual services will need a higher level of granularity. In that context, there are a couple of questions to clarify. Eg, how does a web service authenticate users? Do services need to be able to provide security at the method level? If you sign up with a vendor that provides services around the world, how do these services learn about your security privileges or trust levels? |
||||||||||||
Reuters Expectations from the W3C Workshop |
||||||||||||
Since autumn 2000, Reuters has been aware of the latest developments on web
services and is constantly evaluating proposals for web service related standards,
such as UDDI or SOAP.
Reuters has already adopted and extended web service concepts
(eg, SOAP). This highlights the need
for additional standards to implement a richer and more complete set of web services.
Reuters expectations are as follows:
|
||||||||||||
How can Reuters contribute? | ||||||||||||
Reuters has views on web services and can contribute to the web
services debate in many ways:
|
||||||||||||
Conclusion |
||||||||||||
Web services represent a fresh approach for online service provisioning. Reuters intends to migrate to a flexible, open, web service-based architecture. Such an effort is related to costs and risks too. So far, web service related initiatives are not complete and have not matured yet. In order to implement and make web services a success, a solid, thorough definition and backing throughout the industry is essential. In the meanwhile, due to lack of de jure standards, Reuters will utilise existing de facto standards. Simultaneously, if applicable Reuters will make proposals for web service protocols. | ||||||||||||
References |
||||||||||||
|