WS-I Sets Basic Profile for Interoperable Web Services
The WS-I has released a working draft of its first Basic Profile document. It provides developers an exhaustive list of implementation guidelines for how to use SOAP, WSDL and XML Schema to help ensure projects will interoperate with other systems. IDN looks in-depth at these specs for messaging, service description, discovery and security in our Q&A with a key WS-I exec.
The Web Services Interoperability Organization (WS-I) last week released a working draft of its first Basic Profile (v 1.0) document.
The 48-page Basic Profile draft document, edited by WS-I members from Microsoft, IBM, BEA Systems and webMethods, is designed to present an exhaustive list of implementation areas In specific, the WS-I Basic Profile aims to spell out a set of open (non-proprietary) web services specifications for how developers and vendors should implement SOAP, WSDL and other key first-generation web services technologies to insure interoperability between different technologies (such as Java and .Net, Java and Windows).
The Basic Profile's implementation guidelines recommend how SOAP 1.1, WSDL 1.1, UDDI 2.0, XML 1.0 and XML Schema should be used together to develop interoperable Web services, drilling down into the following implementation areas:
WS-I: Provider of an Implementation RoadMap,
for Web Services with Tools, Code and Models
In addition to the Basic Profile, the WS-I will also produce some tools and templates to assist ISVs and end user developers build web services that will interoperate across platforms. Key deliverables to ship by summer will include.
(1) Testing Tools: To monitor and analyze interactions with a Web service to determine conformance with the Basic Profile.
(2) Use Cases and Usage Scenarios: To define distinct classes of real-world business and technical requirements for Web services.
(3) Sample Applications: To demonstrate Best Practices for the implementation of applications based on the Basic Profile.
"WS-I is looking to provide a single point of aggregation or contact for all interoperability activity," said Rob Cheng, chairman of WS-I's marketing communications committee. "Without this organization, you would actually have to have a large amount of your staff and resources focused on all the different [standards] activities, and then try to figure out how they all work together.
To get more insight on the role WS-I hopes to play for developers and implementers of web services, Integration Developer News spoke in-depth with Cheng. That interview appears below.
The WS-I Interview
IDN: What is the WS-I hoping to achieve with the release of its first Basic Profile?
Cheng: The WS-I has three (3) major goals. The main goal is to achieve interoperability across different platforms, and the ways that we do this is to provide a common definition [for web services interoperability] and the Basic Profile. From that, we also give the different vendors and end users some guidelines on how to implement web services in an interoperable manner.
IDN: So, does the WS-I work represent a new level of standard apart from work being done W3C and OASIS, or an enhancement of existing standards?
Cheng: The goal is really to integrate these specifications from various standards bodies. [WS-I's role] is not a standards effort, to deliver one-off specification by specification. It's really more of a holistic approach, looking at the integrated implementation side of things.
IDN: How does that translate to what WS-I has done in the basic Profile for SOAP, WSDL, etc.?
Cheng: Each of these specifications leave a lot of room for interpretation, which is good from the perspective of being broadly applicable. But, it causes challenges when you're trying to do interoperability across various business segments.
IDN: In web services, what technologies were considered the most important to WS-I, as far as specifying implementations to help avoid problems with interoperability?
Cheng: SOAP and WSDL and XML schema were key. UDDI is included in the [Basic Profile] but was not a major focus of the work.
IDN: And was SOAP considered a new protocol, rather than XML over RPC, as key?
Cheng: It's wasn't so much because it [SOAP] was a new protocol, as much as it was a consensus of the membership. We have 168 members, and so the way WS-I works is to see where consensus [on standards] is in the industry and in the membership. And then, taking that piece [of technology], determining what the interoperability issues are issues around this space. So, even when you talk about SOAP and WSDL, there is still specific things you need to figure out. How are you handling SOAP action headers? What are the error handling types? How many parts you can send? Things like that at an interoperability level need to be handled from an implementation perspective.
IDN: So, is it the intent of WS-I to guide standards groups like W3C and OASIS on possible interoperability problems or issues as they affect standards they are considering?
Cheng: Oh yeah. There is definitely active efforts at WS-I at liaison relationships between the different bodies, especially at the grassroots level. The large majority of the engineers in the working groups at the WS-I, are the same names that are dealing with these issues at the W3C and OASIS. The WS-I is really trying to be sort of an integrator or middleman between the end users, developers and businesses and these upstream standards bodies. It really tries to be a standards integrator for them.
IDN: What do you see as the benefits of WS-I taking this role?
Cheng: It serves two purposes. From the end users perspective, it gives you a single point or interface into that activity where you can work and collaborate with others in to come up with a consensus on how to do things. From a standards bodies perspective, we actually do actively try to bring requirements from the end users back into the standards organizations.
IDN: So, would you say that WS-I wants to be a sort of 'referee' in helping standards bodies avoid interoperability conflicts?
Cheng: Referee might not be the right word to use, but we are trying to be a forum for end users, developers and businesses to communicate the requirements upstream to the standards organizations. And we're really trying to be an advocate to raise specific issuers and business requirements in the industry.
IDN: Your first Basic Profile document seems to be a very extensive drill down on certain technology issues. Is your goal here to specify as much implementation detail, what can go right and or wrong, as possible for the developer and ISV communities?
Cheng: WS-I is extremely implementation-focused
The deliverables WS-I produces are not limited to the profile, it also includes more implementation-heavy deliverables, such as sample applications and testing tools. Sample applications are complex sample code running applications that demonstrate Best Practices. Testing tools are actual utilities that developers can download and use to test their actual server endpoints against what's expected by a WS-I-conformant product.
IDN: So, eventually, there will be more to WS-I output than just more specs?
Cheng: That's a huge huge difference in how WS-I is organized and how it works. A lot of times, the engineers [at WS-I] have deliverables, deadlines and milestones and actually even need to write code. The activities are run essentially as projects.
IDN: How does WS-I go about organizing their work and deliverables?
Cheng: The way it works is this. For example, the set of user scenarios that we just recently published really drive the requirement for the Basic Profile. Our sample application [also recently drafted] is a simple Supply Chain model, and there is a number of use cases that came out around how those different entities will interact -- the suppliers, the manufacturers, the retailers and the end users.
From that, the [WS-I members] distilled down certain messaging models required by one or more entity in the profile. Those were: one-way, fire and forget, callback. Those are what really drove the requirements in the profile.
IDN: So, if I am a Java or .Net developer, how would I best leverage your work? In the beginning, developers may not have all the end-to-end knowledge needed to build an interoperable web service?
Cheng: Probably, other than looking at the profile, you would start with the sample applications. When they are published [in summer 2003], there will be a number of different implementations on different platforms. So, developers will be able to see how Oracle implemented the retailer and manufacturing component. And how Bowstreet, or IBM or Microsoft or others implemented those different things to confirm with the WS-I Best Practices. The goal is to show developers how the real world implementations are getting worked out.
IDN: What about the WS-I tools you mentioned? Will there be different tools depending on what kind of developer you are?
Cheng: There probably [will be] more than one platform on which they run. The tools themselves are not intended to be used as sample code.
IDN: So, are the tools designed to be plug-ins for IDEs, or scripts or something different?
Cheng: They are stand-alone tools, which doesn't mean that a member of WS-I or adopter couldn't (with the correct licensing) actually build them into their application. I know that there are a number of vendors that are WS-I members that are planning to do something of that nature.
IDN: So, in the meantime, how would an end user/developer use your tools as stand-alones?
Cheng: For the end user and developer, typically we would see this happening by having them download the tools and utilities. The tools have three components to them: There is a monitoring tool which is basically a packet sniffer that checks the message on the wire; a logging tool which records them; and an analysis tools which examines traces to see if the output of those web services conform with the WS-I Basic Profile web service. They would run those against the web services [they've built].
IDN: What's next up for WS-I? Any further add-ons to the current Basic Profile in the works?
Cheng: We will have a relatively short tern around step that will handle SOAP with attachments. This is something that has been driven by the membership, and something that has been discussed by the end user companies and the smaller vendors to have attachment support. The SOAP with attachments be handled in an updated Basic Profile (v1.1), and implementation issues for SOAP 1.2 will come later this year. .