SOA: WSDL Ought Not to be Treated Lightly

Web service reusability is a key benefit of SOA, but context must dictate how services can and should be reused. As this worst practice illustrates, in the case of SOA, WSDL should not be treated lightly: security, privacy, and compliance issues can surface when the use of a Web services description language (WSDL) is not governed.

The Idea: "We Even Let Grandma Use Our WSDL"

Venton Automotive, an OEM of sunroofs, had provided its human resources (HR) team with a great new tool. The company had designed its internal HR portal so that employees could enter and manage their own information, including skill sets, phone numbers and locations, managers' names, etc. Likewise, HR validated this information and manually removed records for any individuals who were no longer with the company.

The portal functioned largely as a trust-based system, performing only minor data validation, such as validating reporting structure, titles, etc.

Soon the portal was the only place where up-to-date and complete employee profile information could be found. In fact, it was the only place where HR could locate a current organizational chart. Over time, other departments discovered the portal—and began to use it. The audit team, for example, used the information to ensure that everyone in a group had been trained on compliance and privacy issues. And the company telephone operator was able to ensure calls were routed to the appropriate individuals.

When other developers requested access to the HR portal information, the IT team shared the WSDL used to define the service's formats and protocols. The IT team was comfortable sharing the WSDL, for it reasoned that the point of a SOA was to have a reusable service. The main developer shared the WSDL with three or four people, who then shared it with other developers. After a few months, no one was certain about the number or identity of people consuming the service.

Actional identifies all users and providers of services on the in the SOA; WSDL distribution is no longer an issue

Why It Wasn't So Smart

The IT team soon learned that someone had put the WSDL into a library and then shared the library with all the development teams. They soon learned that the Web service had more than 30 consumers.

The IT team had no idea that so many users and lines of business were being supported. They also didn't know:

• Were the right departments being supported?
• Was the Web service data encrypted?
• What was the capacity of the service?
• If it failed, what would be the ramifications?
• What if the IT team needed to engage in Web service versioning?

To make matters worse, people were using the library in production, so the IT team had a development server supporting production applications. This arrangement posed serious security risks and jeopardized adherence to compliance and privacy laws.

In sum, IT management was exposing its systems to substantial risk, while missing the opportunity to show measurable value of a SOA, as demonstrated by reuse.

A Better Approach

To achieve secure reuse of services via a SOA, you want to have a detailed process in place. Such a process must:

• Identify the consumers and providers that depend on the service
• Ensure that the right security measures are in place, IT policy is enforced, and business rules are applied
• Set up management and runtime governance technology
• Validate that the service is running as designed and meeting the business objectives for which it was designed
• Include a warning mechanism and discovery capability, so you can know immediately when production operations go awry or something slips by the process—such as the inappropriate sharing of a service or WSDL

Bottom line? Sharing a WSDL may seem like an innocent act, but, if not controlled, countless individuals can gain access to a valuable service, putting your data at serious risk.

For More Information

Understand SOA and WSDL in detail – and the implications of "WSDL run amok" on the network: download the free webinar, Runtime Governance