OASIS has taken on another massive project that could further define the role — and the architecture — of web services, this time in the B2B arena.
A new committee, called the OASIS Management Protocol Technical Committee, has set itself the task of defining a new inter-enterprise protocol that would enable developers and sysadmins to build, monitor and manage web services interactions between companies.
The scope of the project makes this protocol one of the most complicated ever, as committee members intend to empower the protocol to provide views and management controls to the entire life-cycle of a web services transaction or event. Topologically, this means the new protocol will need to provide views into network, application logic and even business logic elements of traffic. Committee members also intend to ensure the protocol supports more than one application model because the protocol is intended to support inter-enterprise (B2B) communications.
The committee membership, to date, comprises many of the leaders in network management, including IBM, Hewlett-Packard, Novell, Computer Associates, Microsoft, Intel and Cisco, among others. The committee has targeted early 2003 for their first draft specification of the new B2B web services management protocol.
As the work begins, Open Enterprise Trends caught up with chair of the committee, Winston Bumpus, (who is also the President of the Distributed Management Task Force and an employee of Novell). OET asked him about the scope of the project, its goals and when the front-lines IT community might see some impact.
Mapping of a New Protocol
“My intent was that we would build management protocols using web services technologies, and that we would support and leverage, where appropriate, much of the prior management protocol work that has been done by pre-SOAP committees,” Bumpus said, most notably this includes the DMTF’s work on the Common Information Model (CIM). CIM is so important to the effort, Bumpus said, because of OASIS’ intent to support multiple models.
When it comes to what work to leverage, the OASIS committee has already begun making a laundry list of what to keep, and what needs to be improved upon, Bumpus told OET.
“One of the first exercises we did last week was to take all the known management protocols and identify their strengths and weaknesses.” CIM, for instance, he said, has strong modeling and schema features. CIM also has support in shipping products from Microsoft, Cisco and Sun Microsystems, among others. Other core technologies the committee will look to leverage early will be HP’s Open Management Interface and Java Community Process’ JMX, he said.
“Our goal is to make an exhaustive list so we can come up with a protocol that will support a common set of management operations that in turn will be able to be implemented across all environments,” Bumpus added.
What’s on the List?
“Security, in fact, is the first thing on the list,” Bumpus said. He noted that SNMP, for example, was good at getting information, but that the protocol’s security support was so poor because SNMP has never done much in the area of setting information. “The new protocol will have to address this,” he said, noting that the committee is looking at work being done by the SAML (Security Assertion Markup Language) and WS-Security committees, also (not coincidently) under the OASIS umbrella.
Also a top priority for the new protocol (which has yet to be officially named), Bumpus said, are the following: event notification, exception handling, asynchronous communications, service level agreement enforcement and state management for traffic between legacy and Internet resources. “Whatever we do management needs to encode policy and SLAs,” Bumpus said.
Another key item for agreement is what Bumpus calls “model independence.” He puts it this way: “If we went down the road and said, ‘Let’s pick a model’, and some vendors came back and said they couldn’t support that model, then our interoperability is at risk. SOAP is an RPC mechanism but it also creates a common model for data encoding, so you can have a level of interoperability you couldn’t have before. Also, the new protocol will have to deal with domains that are virtual and dynamic — not physical.”
The protocol will store and exchange management data using XML.
We asked Bumpus that given the fact that most of management protocol is based on information capture and transfer, why could XML just be used on top of existing management protocols? “XML didn’t solve the problem of information exchange all by itself”, Bumpus said, “But we will be using XML schema in addition to techniques that enable us to define and validate the information being captured and sent.” The protocol also must support representations of management information (devices and properties) between multiple models, and that required something broader than simply XML, Bumpus said, such as technology based on the DMTF’s Common Information Model.
Only Re-invent the Wheels You Need
This approach to leveraging work already completed (or in progress) is the hallmark of the committee’s approach, Bumpus said. “From the start, the committee members all said, ‘Let’s focus on the things we agree on,'” Bumpus said. As the President of the DMTF, Bumpus knows the mix of politics and marketplace issues that can bog down the progress of a committee’s search for a standard.
“In a technical committee such as this, there are technical and political pressures and issues where you’re not going to have agreement. But, our goal is to set up as much interoperability as possible, so we decided that we would focus on those areas where we can agree, because if we do we can make good progress,” Bumpus said. “We are management experts, and so we don’t want to invent new wheels where we don’t have to,” he added, and leveraging prior work also helps the committee start from a common set of agreements, he added.
“Layering” Protocols
But despite the need to leverage, Bumpus concedes there is work that will take the committee to new areas. “Part of our work will be a ‘layering activity’ that would make all that available to the new protocol.” This layering work will be key to just how flexible and data-rich the new protocol will be, compared to traditional management protocols.
“With SMNP, we look at one device, rather than looking at a correlation engine, to figure out where the relationships are,” Bumpus explained. “The advent of a layering engine will help the protocol map these complex relationships in real-time.”
The OASIS management protocol work joins several Web services standards currently being developed within OASIS. Other specifications include UDDI for discovery, ebXML for electronic business commerce, WS-Security for secure Web services, WSIA for interactive Web applications, WSRP for remote portals, and others. Participation in the OASIS Management Protocol Technical Committee remains open to all organizations and individuals. OASIS will host an open mail list for public comment, and completed work will be freely available to the public without licensing or other fees. Information on joining OASIS can be found onhttp://www.oasis-open.org/join.
“This work may start to redefine what we think of as ‘traffic’,” Bumpus concluded. “When we get to talking about SLAs and effective management of business transactions, we’ve got to start looking at the process from the business systems point-of-view. Ideally all the info we need from devices, applications, inventory and even incompatible business rules should all be aggregated in a management view that helps the manager see what went wrong, Trying to track that down by looking for a device that failed isn’t the way to go. We may not get there with this first draft, but it will be a big step in that direction.”