OASIS Framework for Web Services Implementation (FWSI) TC
How is the work of OASIS FWSI TC different from that of WS-I Consortium?
OASIS FWSI TC aims to facilitate implementation of robust web services by defining a practical and extensible methodology consisting of implementation processes and common functional elements that practitioners can adopt to create high quality web services systems without re-inventing them for each implementation.
WS-I primary focus is on message interoperability; for example for messaging use SOAP 1.1 as your standard and try not to use custom fault codes, even if SOAP 1.1 allows for that, unless you provide a definition of the fault codes from your industry. WS-I uses specifications from W3C and OASIS and determines where and how each standard will be used in conformant Web Services.
A member of this TC draws this golf analogy:
If W3C and OASIS will be defining all the different golf clubs, ranging from wood to irons (eg 2 wood, 5 Iron, 9 Iron, etc.) WS-I will be telling us what a complete golf set must contain, which is a subset of all the available types of clubs out there given the fact that you have a limit on the number of clubs you can carry in your golf bag; whereas the common functional elements of OASIS FWSI TC deal with how you use the different clubs in different situations.
What criteria will the TC use to select specifications to add to its framework?
The criteria that the TC will use, though not necessary in order of importance, are 1) industry acceptance of the specifications, 2) mature, stable and proven specifications.
Will the TC do any interoperability testing of the specs they choose to comprise each framework?
WS-I has produced a Web service interoperability testing tool to test web services interoperability, and there are also others. Though the TC will refers to some of these standards and specifications; it is not in the interest of this TC to carry out any interoperability tests or for that matter, other tests.
What was the motivation for forming the OASIS FWSI Technical Committee?
As part of its effort to accelerate the adoption of web services, the Java Smart Services Lab (JSSL) of Singapore has developed a Web Service Reference Architecture (WSRA) (please refer to http://www.jssl.org.). WSRA has two main parts, namely 1) sets of relevant Guidelines and 2) Reference Implementation of Core Services as shown in Figure 1.
Through the experience of developing WSRA (the arena of play for the WSRA is as illustrated in Figure 2) and working with the industry in actual implementations of Web service-enabled applications, it became apparent that web services implementation needs a lot of actual implementation guidelines and there are also a lot of commonalities that exist throughout these implementations. If harnessed properly, the movement towards getting web services to the mass market can be realised that much faster. As such, the thoughts for contributing this knowledge and harnessing the vast knowledge out there from all parts of the industry was mooted and hence the work towards the formation of this TC.
Figure 1: Core Services in the WSRA
Figure 2: The relationship of the WSRA with other works in the International Arena
What is the initial input for this work?
Essentially, the Guidelines are sets of best practices or experienced gained from implementing web services and harnessed from within JSSL and its technology partners; whilst the core services are sets of infrastructure software pieces that are identified and developed by JSSL. Figure 1 shows a conceptual representation of the Core Services that have been identified for Reference Implementations. JSSL will like to contribute the experience and knowledge gained through the derivation of WSRA as initial input to this TC. Table 3 shows that the knowledge and experience gained through actual hands-on development of core services will be used as initial input towards the deliverables of the TC.
Initial Input to TC Deliverables
Guidelines / Best Practices
Web Services Implementation Process Specification
Reference Implementation of Core Services (Release 1.0)
Web Services Functional Elements Specification
Table 1: Relevance of the WSRA as initial inputs towards the deliverables of the OASIS FWSI TC
What are some sample scenarios of the usage of functional elements
for the OASIS FWSI TC?
In this section an example is used to illustrate the usage of the Core Services in the WSRA. In essence these Core Services can be the Functional Elements to be specified in the work of the TC.
1. Example - Service Monitoring
In this example, 4 Core Services (or Functional Elements) are used to define a service monitoring solution:
Service Management This Core Service provides the basic service management facilities at the server end (or where web services are hosted) like performance metric measurement and audit trails.
Service Tester This Core Service enhances the solution by providing ability for Web service consumers (clients) who may want to ensure that the web services that are about to be invoked are available, or provide the performance quality that is needed. It also may provide some performance metrics at the client end.
XML-Rule Engine/Middleware As audit information and performance metrics are usually stored into some database, and depending on the target group of users, different types of information or statistics will probably be needed. This is where some intelligence will be useful, like an XML-Rule Engine in this case.
Notification Engine To add to the intelligence, different users might want to be notified differently, on different devices for example. This Notification Engine Core Service, together with the XML-Rule Engine will be able to customize and personalize such deliveries.
Different applications would probably have different permutations for a service monitoring solution. This example here is to illustrate how the various Core Services can be used to form a specific solution for an application. Likewise, a set of similar Functional Elements will help the industry to standardize some expected foundation blocks that could be made available by Web service infrastructure products provider and application developers will be able to know/understand/help define what they will like to develop.