Home > Articles > Web Services > XML

Enabling Enterprise-Class Web Services

This chapter focuses on the considerations for enabling enterprise-class web services. These are web services that meet the level of technical and operational maturity consistent with the increasingly stringent requirements of today's enterprise.
This chapter is from the book

This chapter is from the book

In the last chapter, we talked about the business requirements and the business reasons for choosing a web services architecture for the solution. Before you start designing the web services to meet these business requirements, you have to take a close look at the factors to be considered for enabling enterprise-class web services. Enterprise-class web services represent a level of technical and operational maturity that is consistent with the increasingly stringent requirements of today's enterprise. As we progress toward building such web services, in this chapter, we take a close look at designing interoperability, publishing an enduring web services contract, exposing the business-tier components, and planning for a robust production environment.

The WebLogic Workshop web services framework abstracts the developer from the plumbing code required to build enterprise-class web services. WebLogic Workshop combines the visual development environment with the runtime framework to help developers and nondevelopers effectively and efficiently build these services.

Designing Interoperability

The two dominant web services development platforms are on J2EE and .NET. Most often, the client accessing the web services cannot be predetermined. Therefore, it is important to make certain design choices—choice of standards, WSDL design, and SOAP messaging style—that enhance the interoperability of the web services implementation across different platforms.

Conforming to Standards

Using the web services standards—XML, WSDL, SOAP, and UDDI, as well as WS-Security (security), Web Services Distributed Management (manageability), and the Business Process Execution Language (orchestration)—strictly as defined by the standard bodies is a necessary requirement for interoperability. Following the recommendation from bodies such as the WS-I not only improve interoperability, but it also facilitates fast implementation with business partners.

Standards are important at all levels of web services communication. By using a standard way of exchanging data using XML, choosing a common SOAP message protocol, and describing services through WSDL, you enable the users of your service to communicate with your application regardless of the platform they are using. This approach helps you to integrate your web services with those of your business partners without relying on proprietary vendor technology.

In WebLogic Workshop, exposing an operation through these standards is extremely easy. Workshop introduces a simple javadoc-based annotation @jws:operation for marking up standard Java code. If you simply put this annotation before a method in a standard Java class file, Workshop exposes that method as a web service that fully supports the web services standards.

Designing WSDL First

In general, designing the WSDL first is the right way to start your web services. The WSDL represents the contract between you and the user of your service. Not unlike the real world, the contract needs to be well crafted. It needs to spell out in the clearest possible terms what the service offers—and, ideally, what it does not do.

Most often, developers seldom design the WSDL because many SOAP implementations provide tools to automatically generate a WSDL file from a COM object or Java class files. Surprisingly, this can cause issues of interoperability between different Java application servers and between .NET and Java implementations. This is because the automatically generated WSDLs might not be interpretable across different platforms. For example, some application servers cannot use WSDLs that have imported or included XML Schemas. Designing the WSDL first and then creating the web service avoids the issue.

The recommendation is that you generate WSDL using techniques based on the Unified Modeling Language (UML) or using WSDL editors (see Figure 5.1). We cover in detail how to design WSDL using XMLSPY, a WSDL editor, in the next chapter.

WSDL modeling in UML can be another way of creating WSDL rather than using WSDL editors. The Object Management Group (OMG) has established a Model Driven Architecture (MDA) and Unified Modeling Language (UML) for modeling software applications. UML is a graphical language for specifying, visualizing, constructing, and documenting software systems. Because of its wide acceptance and capabilities, UML is the natural choice for any modeling activities. UML profiles provide a generic extension mechanism for building UML models in particular domains such as Web Modeling Profile, XSD Schema Profile, and Business Profile Modeling. A profile consists of stereotypes, constraints, and tagged values that allow modeling of all WSDL definitions.

Figure 5.1Figure 5.1 XMLSPY, a sample WSDL editor

Deriving from the MDA, the modelling of the WSDL can be divided into a platform-independent model (PIM) and a platform-specific model (PSM). A WSDL file has two sections, the abstract section and the bindings section. The PIM represents the abstract section of the WSDL. This includes Definitions, Service, PortType(s), Messages, Parts, and PartType(s). The PSM completes the bindings section of the WSDL. The elements modelled here include Service, Ports, and Binding(s).

Selecting SOAP Messaging

The style, or binding style, decision controls how the elements just under the SOAP body are constructed. The two choices are RPC and document. The use, or encoding, concerns how types are represented in XML. The two choices are literal and SOAP encoded. Literal follows an XML Schema definition. SOAP encoded follows special encoding rules detailed in the SOAP 1.1 specification to produce XML that can contain references pointing within the message. The WS-I Basic Profile Version 1.0a specification recommends the use of literal encoding; it actually discourages the use of SOAP encoding.

Theoretically, you should be able to mix and match any of the styles and uses for SOAP messaging. However, practically, the RPC-encoded and document-literal choices are the ones used. In addition, many web service platforms don't directly support RPC-literal. WebLogic Workshop uses document-literal as its default message format, but it also supports the RPC-encoded message format. To specify the message format that a web service uses to communicate with the web service control, you can set the soap-style attribute of the @jc:protocol annotation to document for the document-literal message format or rpc for the SOAP-RPC format.

RPC-encoded seemed reasonable in a world without XML Schema. Now that XML Schema is here to stay, document-literal is quickly becoming the de facto standard among developers and toolkits, thanks to its simplicity and interoperability results.

Styles: Document and RPC

Document style indicates that the SOAP body contains an XML document. In this approach, you the send XML document as is. The sender and receiver must agree on the format of the document ahead of time. Here is an example of a document-style message:

<SOAP-ENV: Envelope xmlns:SOAP- 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SOAP-ENV:Body> <m:inValidateConfig xmlns:m="http://production.psg.hp.com/types"> <m:Config> <m:Model/> <m:Cstic/> </m:Config> <m:User AccountID=0000000000> <m:Password>String</m:Password> <m:IpcVersion>OLD</m:IpcVersion> <m:ConfigID>String</m:ConfigID> </m:inValidateConfig> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Observe that all elements are defined within the same namespace. With a document-style web service, you are free to define the XML however you want because all the XML is explicitly specified.

RPC style indicates that the SOAP body contains an XML representation of a method call. RPC style uses the names of the method and its parameters to generate structures that represent a method's call stack. Here's an example of a RPC-style message:

    <m:validate xmlns:m="local
host:7001/services/validate" SOAP-ENV:encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"> <in0 xsi:type="xsd:string">String</in0> </m:validate> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

RPC relies on some rules. Observe that the root element is qualified with a namespace, but the child element uses an unqualified name. The root element is named after the operation: validate for a SOAP request and opNameResponse for a SOAP response. Each child is a parameter, or a return value named opNameReturn.

The binding style is specified in the WSDL. There actually is a style attribute that can be RPC or Document in the <soapbind:binding> element, which is the <wsdl:binding> element's first child. Table 5.1 illustrates the differences between RPC and Document.

Table 5.1 Binding Style in a WSDL




<soapbind:binding> element



<wsdl:part> element(s)

<part> element can be many; each contains a "type" attribute.

Only one <part> element containing an "element" attribute.

<wsdl:part> element(s) explained

Specify the type so that the SOAP engine can use RPC rules to make it either a parameter or a return value.

The SOAP body has an XML element that is fully specified in <wsdl:types>.

Use: Literal and Encoding

The use, or encoding, concerns how types are represented in XML. The two choices are literal and SOAP encoded. Literal follows an XML Schema definition. SOAP encoded follows special encoding rules detailed in the SOAP 1.1 specification (section 5) to produce XML that can contain references pointing within the message. Now to compare the literal and encoded use, let's compare the example from the document style that also uses the literal with another example showing the encoding use.

Here's the literal use:

<m:User AccountID=0000000000>
    <m:Password>xyz </m:Password>

Here's the encoding use:

< AccountID xsi:type ="xsd:string">0000000000</ AccountID r>
<Password xsi:type="xsd:string">xyz</Password>

SOAP encoding automatically maps all eligible fields to elements, not attributes. With the literal use of an XML Schema, on the other hand, you can specify what items are attributes and what items are elements. In the previous example, the simple AccountID field can be written more compactly as an attribute.

Now we can examine how use is specified in the WSDL. Table 5.2 shows the difference in literal versus encoded in the WSDL document.

Table 5.2 Use/Encoding Specified in a WSDL




<soapbind:body> use attribute



Other <soapbind:body> attributes

encodingStyle="http:// schemas.xmlsoap.org/soap/ encoding/"

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020