definindo um arquivo wsdl

8/3/2019 Definindo Um Arquivo WSDL

1/29

9/11/11 Writing WSDL Contracts

1/1usesource.com/docs/esb/4.4/cf_sdl/front.html

WRITING WSDL CONTRACTS

Version 4.4June 2011

Copyright 2011 FuseSource Corporation, a Progress Software company. All rights reserved.

Legal Notices

Updaed: 10 Jn 2011


2/29

9/11/11 Chapter 1. Introducing WSDL Contracts

1/1usesource.com/docs/esb/4.4/cf_sdl/WSDLIntro.html

Chapter 1. Introducing WSDL Contracts

Structure of a WSDL document

WSDL elements

Designing a contract

The recommended approach to design services is to define our services in WSDL and XML Schema before

writing an code. When hand-editing WSDL documents ou must make sure that the document is valid, as well

as correct. To do this ou must have some familiarit with WSDL. You can find the standard on the W3C web

site, www.w3.org.

WSDL docmen define eice ing Web Seice Decipion Langage and a nmbe of poible

eenion. The docmen hae a logical pa and a concee pa. The abac pa of he conac

define he eice in em of implemenaion neal daa pe and meage. The concee pa of he

docmen define ho an endpoin implemening a eice ill ineac ih he oide old.


3/29

9/11/11 Structure of a WSDL document

1/1usesource.com/docs/esb/4.4/cf_sdl/WSDLStructure.html

The logical par

The concree par

Structure of a WSDL document

A WSDL document is, at its simplest, a collection of elements contained within a root definition element.

These elements describe a service and how an endpoint implementing that service is accessed.

A WSDL document has two distinct parts:

A logical part that defines the service in implementation neutral terms

A concrete part that defines how an endpoint implementing the service is exposed on a network

The logical part of a WSDL document contains the tpes, the message, and the portTpe

elements. It describes the services interface and the messages exchanged by the

service. Within the tpes element, XML Schema is used to define the structure of the data that makes up the

messages. A number ofmessage elements are used to define the structure of the messages used by the

service. The portTpe element contains one or more operation elements that define the messages sent by

the operations exposed by the service.

The concrete part of a WSDL document contains the binding and the serviceelements. It describes how an endpoint that implements the service connects to the

outside world. The binding elements describe how the data units described by the message elements are

mapped into a concrete, on-the-wire data format, such as SOAP. The service elements contain one or more

port elements which define the endpoints implementing the service.


4/29

9/11/11 WSDL elements

1/1usesource.com/docs/esb/4.4/cf_sdl/WSDLElements.html

WSDL elements

A WSDL document is made up of the following elements:

definitions The root element of a WSDL document. The attributes of this element specify the name

of the WSDL document, the documents target namespace, and the shorthand definitions for the

namespaces referenced in the WSDL document.

tpes The XML Schema definitions for the data units that form the building blocks of the messages

used by a service. For information about defining data types see Defining Logical Data Units.

message The description of the messages exchanged during invocation of a services operations.

These elements define the arguments of the operations making up your service. For information on

defining messages see Defining Logical Messages Used by a Service.

portTpe A collection ofoperation elements describing the logical interface of a service. For

information about defining port types see Defining Your Logical Interfaces.

operation The description of an action performed by a service. Operations are defined by themessages passed between two endpoints when the operation is invoked. For information on defining

operations see Operations.

binding The concrete data format specification for an endpoint. A binding element defines how the

abstract messages are mapped into the concrete data format used by an endpoint. This element is

where specifics such as parameter order and return values are specified.

service A collection of related port elements. These elements are repositories for organizing

endpoint definitions.

port The endpoint defined by a binding and a physical address. These elements bring all of the

abstract definitions together, combined with the definition of transport details, and they define the

physical endpoint on which a service is exposed.


5/29

9/11/11 Designing a contract

1/1usesource.com/docs/esb/4.4/cf_sdl/WSDLDesignContract.html

Designing a contract

To design a WSDL contract for our services ou must perform the following steps:

1. Define the data tpes used b our services.

2. Define the messages used b our services.

3. Define the interfaces for our services.

4. Define the bindings between the messages used b each interface and the concrete representation of

the data on the wire.

5. Define the transport details for each of the services.


6/29

9/11/11 Chapter 2. Defining Logical Data Units

1/1usesource.com/docs/esb/4.4/cf_sdl/WSDLTpes.html

Chape 2. Defining Logical Daa Uni

Mapping daa ino logical daa ni

Adding daa ni o a conac

XML Schema imple peDefining comple daa pe

Defining daa ce

Defining aa

Defining pe b eenion

Defining pe b eicion

Defining enmeaed pe

Defining elemen

When defining a eice, he fi hing o m conide i ho he daa ed a paamee fo he epoed

opeaion i going o be epeened. Unlike applicaion ha ae ien in a pogamming langage ha

e fied daa ce, eice m define hei daa in logical ni ha can be conmed b an nmbe

of applicaion. Thi inole o ep:

1. Beaking he daa ino logical ni ha can be mapped ino he daa pe ed b he phical

implemenaion of he eice

2. Combining he logical ni ino meage ha ae paed beeen endpoin o ca o he opeaion

Thi chape dice he fi ep. Defining Logical Meage Ued b a Seice dice he econd ep.

When describing a service in a WSDL contract comple data tpes are defined as logical units using XML

Schema.


7/29

9/11/11 Mapping data into logical data units

1/1usesource.com/docs/esb/4.4/cf_sdl/WSDLMappingData.html

Available tpe sstems for defining service data units

XML Schema as a tpe sstem

Considerations for creating our data units

Mapping data into logical data units

The interfaces used to implement a service define the data representing operation parameters as XML

documents. If you are defining an interface for a service that is already implemented, you must translate the

data types of the implemented operations into discreet XML elements that can be assembled into messages. If

you are starting from scratch, you must determine the building blocks from which your messages are built, so

that they make sense from an implementation standpoint.

According to the WSDL specification, you can use

any type system you choose to define data types in

a WSDL contract. However, the W3C specification states that XML Schema is the preferred canonical type

system for a WSDL document. Therefore, XML Schema is the intrinsic type system in Fuse Services Framework.

XML Schema is used to define how an XML document is structured. This is

done by defining the elements that make up the document. These elements

can use native XML Schema types, like sd:int, or they can use types that are defined by the user. User

defined types are either built up using combinations of XML elements or they are defined by restricting existing

types. By combining type definitions and element definitions you can create intricate XML documents that can

contain complex data.

When used in WSDL XML Schema defines the structure of the XML document that holds the data used to

interact with a service. When defining the data units used by your service, you can define them as types that

specify the structure of the message parts. You can also define your data units as elements that make up the

message parts.

You might consider s imply creating logical data units that

map directly to the types you envision using when

implementing the service. While this approach works, and closely follows the model of building RPC-style

applications, it is not necessarily ideal for building a piece of a service-oriented architecture.

The Web Services Interoperability Organizations WS-I basic profile provides a number of guidelines for

defining data units and can be accessed at http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-

24.html#WSDLTYPES. In addition, the W3C also provides the following guidelines for using XML Schema to

represent data types in WSDL documents:

Use elements, not attributes.

Do not use protocol-specific types as base types.


8/29

9/11/11 Adding data units to a contract

1/1usesource.com/docs/esb/4.4/cf_sdl/WSDLAddingDataUnits.html

Procedre

Addig daa i a cac

Deedig h che ceae WSDL cac, ceaig e daa defiii eie aig

a f edge. The Fe Seice Fae GUI ide a be f aid f decibig daa

e ig XML Schea. Ohe XML edi ffe diffee ee f aiace. Regade f he edi

che, i i a gd idea hae e edge ab ha he eig cac hd ie.

Defiig he daa ed i a WSDL cac ie he fig e:

1. Deeie a he daa i ed i he ieface decibed b he cac.

2. Ceae a tpes eee i cac.

3. Ceae a schema eee, h i Eae 2.1, a a chid f he tpe eee.

The targetNamespace aibe ecifie he aeace de hich e daa e ae defied. The

eaiig eie hd be chaged.

Eample 2.1. Schema entr for a WSDL contract

4. F each ce e ha i a ceci f eee, defie he daa e ig a compleTpe

eee. See Defiig daa ce.

5. F each aa, defie he daa e ig a compleTpe eee. See Defiig aa.

6. F each ce e ha i deied f a ie e, defie he daa e ig a simpleTpe

eee. See Defiig e b eici.

7. F each eeaed e, defie he daa e ig a simpleTpe eee. See Defiig eeaed

e.

8. F each eee, defie i ig a element eee. See Defiig eee.


9/29

9/11/11 XML Schema simple tpes

1/2usesource.com/docs/esb/4.4/cf_sdl/WSDLXMLSimpleTpes.html

Entering simple tpes

Supported XSD simple tpes

XML Schema imple pe

If a meage pa i going o be of a imple pe i i no necea o ceae a pe definiion fo i. Hoee,

he comple pe ed b he ineface defined in he conac ae defined ing imple pe.

XML Schema imple pe ae mainl placed in he element elemen ed in he

pe ecion of o conac. The ae alo ed in he base aibe of

restriction elemen and etension elemen.

Simple pe ae ala eneed ing he sd pefi. Fo eample, o pecif ha an elemen i of pe int,

o old ene sd:int in i tpe aibe a hon in Eample 2.2.

Eample 2.2. Defin ing an element ith a simple tpe

Fe Seice Fameok ppo he folloing XML Schema imple pe:

sd:string

sd:normaliedString

sd:int

sd:unsignedInt

sd:long

sd:unsignedLong

sd:short

sd:unsignedShort

sd:float

sd:double

sd:boolean

sd:bte

sd:unsignedBte

sd:integer

sd:positiveInteger

sd:negativeInteger

sd:nonPositiveInteger

sd:nonNegativeInteger

sd:decimal


10/29

9/11/11 XML Schema simple tpes

2/2usesource.com/docs/esb/4.4/cf_sdl/WSDLXMLSimpleTpes.html

sd:dateTime

sd:time

sd:date

sd:QName

sd:base64Binar

sd:heBinar

sd:ID

sd:token

sd:language

sd:Name

sd:NCName

sd:NMTOKEN

sd:anSimpleTpe

sd:anURI

sd:gYear

sd:gMonth

sd:gDa

sd:gYearMonth

sd:gMonthDa


11/29

9/11/11 Defining comple data tpes

1/1usesource.com/docs/esb/4.4/cf_sdl/WSDLCompleDataTpes.html

Defiig ce daa eDefiig daa ce

Defiig aa

Defiig e b eei

Defiig e b eici

Defiig eeaed e

XML Schea ide a feibe ad ef echai f bidig ce daa ce f i iedaa e. Y ca ceae daa ce b ceaig a eece f eee ad aibe. Y ca a

eed defied e ceae ee e ce e.

I addii bidig ce daa ce, ca a decibe eciaied e ch a eeaed

e, daa e ha hae a ecific age f ae, daa e ha eed f ceai ae b

eihe eedig eicig he iiie e.


12/29

9/11/11 Defining data structures

1/3usesource.com/docs/esb/4.4/cf_sdl/WSDLXMLCompleTpes.html

Comple tpe varieties

Defining data structures

In XML Schema, data units that are a collection of data fields are defined using compleTpe elements.

Specifying a complex type requires three pieces of information:

1. The name of the defined type is specified in the name attribute of the compleTpe element.

2. The first child element of the compleTpe describes the behavior of the structures fields when it is put

on the wire. See Complex type varieties.

3. Each of the fields of the defined structure are defined in element elements that are grandchildren of the

compleTpe element. See Defining the parts of a structure.

For example, the structure shown in Example 2.3 is be defined in XML Schema as a complex type with two

elements.

Eample 2.3. Simple Structure

struct personalInfo

{string name;

int age;

;

Example 2.4 shows one poss ible XML Schema mapping for the structure shown in Example 2.3.

Eample 2.4. A comple tpe

XML Schema has three ways of describing how the fields of a complex type are

organized when represented as an XML document and passed on the wire. The first

child element of the compleTpe element determines which variety of complex type is being used. Table 2.1

shows the elements used to define complex type behavior.

Table 2.1. Comple tpe descriptor elements

Element Comple Tpe Behavior

sequenceAll the complex types fields must be present and they must be in the exact order they are specified

in the type definition.

all All of the complex types fields must be present but they can be in any order.

choice Only one of the elements in the structure can be placed in the message.

If a sequence element, an all element, or a choice is not specified, then a sequence is assumed. For

example, the structure defined in Example 2.4 generates a message containing two elements: name and age.

If the structure is defined using a choice element, as shown in Example 2.5, it generates a message with

either a name element or an age element.


13/29



Defining he pa of a ce

Defining aibe

Eample 2.5. Simple comple choice tpe

You define the data fields that make up a structure using element

elements. Every compleTpe element should contain at least one

element element. Each element element in the compleTpe element represents a field in the defined data

structure.

To fully describe a field in a data structure, element elements have two required attributes:

The name attribute specifies the name of the data field and it must be unique within the defined

complex type.

The tpe attribute specifies the type of the data stored in the field. The type can be either one of the

XML Schema simple types, or any named complex type that is defined in the contract.

In addition to name and tpe, element elements have two other commonly used optional attributes: minOcurrs

and maOccurs. These attributes place bounds on the number of times the field occurs in the structure. By

default, each field occurs only once in a complex type. Using these attributes, you can change how many times

a field must or can appear in a structure. For example, you can define a field, previousJobs, that must occur

at least three times, and no more than seven times, as shown in Example 2.6.

Eample 2.6. Simple comple tpe ith occurrence constraints

You can also use the minOccurs to make the age field optional by setting the minOccurs to zero as shown in

Example 2.7. In this case age can be omitted and the data will still be valid.

Eample 2.7. Simple comple tpe ith minOccurs set to ero


14/29



element. It comes after the all, sequence, or choice element and are a direct child of the compleTpe

element. Example 2.8 shows a complex type with an attribute.

Eample 2.8. Comple tpe ith an attribute


15/29

9/11/11 Defining arras

1/2usesource.com/docs/esb/4.4/cf_sdl/WSDLDefiningArras.html

Comple tpe arras

SOAP arras

Defiig aa

Fe Seice Fae ehd f defiig aa i a cac. The fi i defie a ce

e ih a ige eee he maOccurs aibe ha a ae geae ha e. The ecd i e SOAP

aa. SOAP aa ide added fciai ch a he abii eai defie i-dieia aa

ad ai ae aed aa.

Ce e aa ae a ecia cae f a eece ce e. Y idefie a ce e ih a ige eee ad ecif a ae f he maOccurs

aibe. F eae, defie a aa f e faig i be e a ce e iia

he e h i Eae 2.9.

Eample 2.9. Comple pe aa

Y ca a ecif a ae f he minOccurs aibe.

SOAP aa ae defied b deiig f he SOAP-ENC:Arra bae e ig he

sdl:arraTpe eee. The a f hi i h i Eae 2.10.

Eample 2.10. Sna fo a SOAP aa deied ing dl:aaTpe

Uig hi a, TpeName ecifie he ae f he e-defied aa e. ElementTpe ecifie he

e f he eee i he aa. ArraBounds ecifie he be f diei i he aa. T ecif a

ige diei aa e []; ecif a -dieia aa e eihe [][] [,].

F eae, he SOAP Aa, SOAPSig, h i Eae 2.11, defie a e-dieia aa f ig.The sdl:arraTpe aibe ecifie he e f he aa eee, sd:string, ad he be f

diei, ih [] iig e diei.

Eample 2.11. Defin iion of a SOAP aa


16/29

9/11/11 Defining arras

2/2usesource.com/docs/esb/4.4/cf_sdl/WSDLDefiningArras.html

You can also describe a SOAP Arra using a simple element as described in the SOAP 1.1 specification. The

snta for this is shon in Eample 2.12.

Eample 2.12. Snta for a SOAP arra derived using an element

When using this snta, the element's maOccurs attribute must alas be set to nbonded.


17/29

9/11/11 Defining tpes b etension

1/1usesource.com/docs/esb/4.4/cf_sdl/WSDLDefiningTpes.html

Defining types by extension

Like most major coding languages, XML Schema allows you to create data types that inherit some of their

elements from other data types. This is called defining a type by extension. For example, you could create a

new type called alienInfo, that extends the personalInfo structure defined in Example 2.4 by adding a new

element called planet.

Types defined by extension have four parts:

1. The name of the type is defined by the name attribute of the compleTpe element.

2. The compleContent element specifies that the new type will have more than one element.

Note

If ou are onl adding ne attributes to the comple tpe, ou can use a

impleConen element.

3. The type from which the new type is derived, called the base type, is specified in the base attribute of

the etension element.

4. The new types elements and attributes are defined in theetension element, the same as they are for

a regular complex type.

For example, alienInfo is defined as shown in Example 2.13.

Eample 2.13. Tpe defined b etension


18/29

9/11/11 Defining types by restriction

1/2usesource.com/docs/esb/4.4//WSDLDefiningTypesByRestriction.html

Specifing the base tpe

Defining the restrictions

Eample

Defiig e b eici

XML Schea a ceae e e b eicig he ibe ae f a XML Schea ie e.

F eae, ca defie a ie e, SSN, hich i a ig f eac ie chaace. Ne e defied

b eicig ie e ae defied ig a impleTpe eee.

The defiii f a e b eici eie hee hig:

1. The ae f he e e i ecified b he name aibe f he impleTpe eee.

2. The ie e f hich he e e i deied, caed he base tpe, i ecified i he

eicion eee. See Secifig he bae e.

3. The e, caedfacets, defiig he eici aced he bae e ae defied a chide f he

eicion eee. See Defiig he eici.

The bae e i he e ha i beig eiced defie he e e. I i

ecified ig a eicion eee. The eicion eee i he

chid f a impleTpe eee ad ha e aibe, bae, ha ecifie he bae e. The bae e ca bea f he XML Schea ie e.

F eae, defie a e e b eicig he ae f a d:in e a defiii ie he e

h i Eae 2.14.

Eample 2.14. Using in t as the base tpe

...

The e defiig he eici aced he bae e ae caedfacets.

Face ae eee ih e aibe, ale, ha defie h he face i

efced. The aaiabe face ad hei aid ale eig deed he bae e. F eae,

d:ing i face, icdig:

lengh

minLengh

maLengh

paen

hiepace

enmeaion

Each face eee i a chid f he eicion eee.

Eae 2.15 h a eae f a ie e, SSN, hich eee a cia eci be.

The eig e i a ig f he f --. 032-43-9876 i a aid ae

f a eee f hi e, b 032439876 i .

Eample 2.15. SSN simple tpe description


19/29

9/11/11 Defining types by restriction

2/2usesource.com/docs/esb/4.4//WSDLDefiningTypesByRestriction.html


20/29

9/11/11 Defining enumerated tpes

1/1usesource.com/docs/esb/4.4/cf_sdl/WSDLXMLEnums.html

Defining an enumeration in XML Schema

Eample

Defining enmeaed pe

Enmeaed pe in XML Schema ae a pecial cae of definiion b eicion. The ae decibed b ing

he enumeration face hich i ppoed b all XML Schema pimiie pe. A ih enmeaed pe in

mo moden pogamming langage, a aiable of hi pe can onl hae one of he pecified ale.

The na fo defining an enmeaion i hon in

Eample 2.16.

Eample 2.16. Snta for an enumeration

...

EnumName pecifie he name of he enmeaion pe. EnumTpe pecifie he pe of he cae ale.

CaseNValue, hee N i an nmbe one o geae, pecifie he ale fo each pecific cae of he

enmeaion. An enmeaed pe can hae an nmbe of cae ale, b becae i i deied fom a imple

pe, onl one of he cae ale i alid a a ime.

Fo eample, an XML docmen ih an elemen defined b he enmeaion widgetSie, hon

in Eample 2.17, old be alid if i conained big , b i old no

be alid if i conained big,mungo .

Eample 2.17. idgetSie enumeration


21/29

9/11/11 Defining elements

1/1usesource.com/docs/esb/4.4/cf_sdl/WSDLXMLElements.html

Defining elements

Elements in XML Schema represent an instance of an element in an XML document generated from the schema.

The most basic element consists of a single element element. Like the element element used to define the

members of a complex type, they have three attributes:

name A required attribute that specifies the name of the element as it appears in an XML document.

tpe Specifies the type of the element. The type can be any XML Schema primitive type or any named

complex type defined in the contract. This attribute can be omitted if the type has an in-line definition.

nillable Specifies whether an element can be omitted from a document entirely. Ifnillable is set

to re, the element can be omitted from any document generated using the schema.

An element can also have an i-lie type definition. In-line types are specified using either a compleTpe

element or a simpleTpe element. Once you specify if the type of data is complex or simple, you can define

any type of data needed using the tools available for each type of data. In-line type definitions are discouraged

because they are not reusable.


22/29

9/11/11 Chape 3. Defining Logical Meage Ued b a Seice

1/3eoce.com/doc/eb/4.4/cf_dl/WSDLMeage.hml

Messages and parameter lists

Message design for integrating with legac sstems

Message design for SOAP services

Chapter 3. Defining Logical Messages Used by a

Service

A services operations are defined by specifying the logical messages that are exchanged when an operation is

invoked. These logical messages define the data that is passed over a network as an XML document. They

contain all of the parameters that are a part of a method invocation.

Logical messages are defined using the message element in your contracts. Each logical message consists of

one or more parts, defined in part elements.

Ti

While o meage can li each paamee a a epaae pa, heecommended pacice i o e onl a ingle pa ha encaplae he daa

needed fo he opeaion.

Each operation exposed by a service can have only one input message and

one output message. The input message defines all of the information the

service receives when the operation is invoked. The output message defines all of the data that the service

returns when the operation is completed. Fault messages define the data that the service returns when an

error occurs.

In addition, each operation can have any number of fault messages. The fault messages define the data that is

returned when the service encounters an error. These messages usually have only one part that provides

enough information for the consumer to understand the error.

If you are defining an existing application as a

service, you must ensure that each parameter used

by the method implementing the operation is represented in a message. You must also ensure that the return

value is included in the operations output message.

One approach to defining your messages is RPC style. When using RPC style, you define the messages using

one part for each parameter in the methods parameter list. Each message part is based on a type defined in

the tpes element of the contract. Your input message contains one part for each input parameter in the

method. Your output message contains one part for each output parameter, plus a part to represent the return

value, if needed. If a parameter is both an input and an output parameter, it is listed as a part for both the

input message and the output message.

RPC style message definition is useful when service enabling legacy systems that use transports such as Tibco

or CORBA. These systems are designed around procedures and methods. As such, they are easiest to model

using messages that resemble the parameter lists for the operation being invoked. RPC style also makes a

cleaner mapping between the service and the application it is exposing.

While RPC style is useful for modeling existing systems, the servicescommunity strongly favors the wrapped document style. In wrapped

document style, each message has a single part. The messages part references a wrapper element defined in

the tpes element of the contract. The wrapper element has the following characteristics:

A eice i defined b he meage echanged hen i opeaion ae inoked. In a WSDL conac hee

meage ae defined ing meage elemen. The meage ae made p of one o moe pa ha ae

defined ing pa elemen.


23/29



Meage naming

Meage pa

It is a complex type containing a sequence of elements. For more information see Defining complex data

types.

If it is a wrapper for an input message:

It has one element for each of the methods input parameters.

Its name is the same as the name of the operation with which it is associated.

If it is a wrapper for an output message:

It has one element for each of the methods output parameters and one element for each of the

methods inout parameters.

Its first element represents the methods return parameter.

Its name would be generated by appending Response to the name of the operation with which the

wrapper is associated.

Each message in a contract must have a unique name within its namespace. It is

recommended that you use the following naming conventions:

Messages should only be used by a single operation.

Input message names are formed by appending Request to the name of the operation.

Output message names are formed by appending Response to the name of the operation.

Fault message names should represent the reason for the fault.

Message parts are the formal data units of the logical message. Each part is defined using a

part element, and is identified by a name attribute and either a tpe attribute or an

element attribute that specifies its data type. The data type attributes are listed inTable 3.1.

Table 3.1. Part data tpe attributes

Aibe Decipion

element="elem_name" The data type of the part is defined by an element called elem_name.

tpe="tpe_name" The data type of the part is defined by a type called tpe_name.

Messages are allowed to reuse part names. For instance, if a method has a parameter, foo, that is passed by

reference or is an in/out, it can be a part in both the request message and the response message, as shown in

Example 3.1.

Eample 3.1. Reused part


24/29



Eample For example, imagine you had a server that stored personal information and provided a method

that returned an employees data based on the employee's ID number. The method signature for

looking up the data is similar to Example 3.2.

Eample 3.2. personal Info lookup method

personalInfo lookup(long empId)

This method signature can be mapped to the RPC style WSDL fragment shown in Example 3.3.

Eample 3.3. RPC WSDL message definitions


25/29

9/11/11 Chapter 4. Defining Your Logical Interfaces

1/3usesource.com/docs/esb/4.4/cf_sdl/WSDLInterfaces.html

Process

Port tpes

Operations

Operation messages

Chapter 4. Defining Your Logical Interfaces

Logical service interfaces are defined using the WSDL portTpe element. The portTpe element is a collection

of abstract operation definitions. Each operation is defined by the input, output, and fault messages used to

complete the transaction the operation represents. When code is generated to implement the service interface

defined by a portTpe element, each operation is converted into a method containing the parameters defined

by the input, output, and fault messages specified in the contract.

To define a logical interface in a WSDL contract you must do the following:

1. Create a portTpe element to contain the interface definition and give it a unique name. See Port

types.

2. Create an operation element for each operation defined in the interface. See Operations.

3. For each operation, specify the messages used to represent the operations parameter list, return type,

and exceptions. See Operation messages.

A WSDL portTpe element is the root element in a logical interface definition. While many Web

service implementations map portTpe elements directly to generated implementation objects,

a logical interface definition does not specify the exact functionality provided by the the implemented service.

For example, a logical interface named ticketSstem can result in an implementation that either sells concert

tickets or issues parking tickets.

The portTpe element is the unit of a WSDL document that is mapped into a binding to define the physical

data used by an endpoint exposing the defined service.

Each portTpe element in a WSDL document must have a unique name, which is specified using the name

attribute, and is made up of a collection of operations, which are described in operation elements. A WSDL

document can describe any number of port types.

Logical operations, defined using WSDL operation elements, define the interaction between

two endpoints. For example, a request for a checking account balance and an order for a gross

of widgets can both be defined as operations.

Each operation defined within a portTpe element must have a unique name, specified using the name

attribute. The name attribute is required to define an operation.

Logical operations are made up of a set of elements representing the logical

messages communicated between the endpoints to execute the operation. The

elements that can describe an operation are listed in Table 4.1.

Table 4.1. Opeaion meage elemen

Element Description

inputSpecifies the message the client endpoint sends to the service provider when a request is made. The

parts of this message correspond to the input parameters of the operation.

output

Specifies the message that the service provider sends to the client endpoint in response to a

request. The parts of this message correspond to any operation parameters that can be changed by

the service provider, such as values passed by reference. This includes the return value of the

operation.

fault Specifies a message used to communicate an error condition between the endpoints.

Logical eice ineface ae defined ing he portTpe elemen.


26/29



Return values

Eample

An operation is required to have at least one i or one element. An operation can have both i

and elements, but it can only have one of each. Operations are not required to have any fa

elements, but can, if required, have any number offa elements.

The elements have the two attributes listed in Table 4.2.

Table 4.2. Attributes of the input and output elements

Attribute Description

aeIdentifies the message so it can be referenced when mapping the operation to a concrete data

format. The name must be unique within the enclosing port type.

eage

Specifies the abstract message that describes the data being sent or received. The value of the

eage attribute must correspond to the ae attribute of one of the abstract messages defined in

the WSDL document.

It is not necessary to specify the ae attribute for all i and elements; WSDL provides a defaultnaming scheme based on the enclosing operations name. If only one element is used in the operation, the

element name defaults to the name of the operation. If both an i and an element are used, the

element name defaults to the name of the operation with either Ree or Ree respectively appended to

the name.

Because the eai element is an abstract definition of the data passed during an

operation, WSDL does not provide for return values to be specified for an operation. If a

method returns a value it will be mapped into the element as the last part of that message.

For example, you might have an interface similar to the one shown in Example 4.1.

Eample 4.1. personal Info lookup interface

interface personalInfoLookup

{

personalInfo lookup(in int empID)

raises(idNotFound);

This interface can be mapped to the port type in Example 4.2.

Eample 4.2. personalInfo lookup port tpe


27/29




28/29

9/11/11 Inde

1/2usesource.com/docs/esb/4.4/cf_sdl/i01.html

Inde

A

all element, Comple tpe varieties

attribute element, Defining attributes

name attribute, Defining attributes

tpe attribute, Defining attributes

use attribute, Defining attributes

B

binding element, WSDL elements

Cchoice element, Comple tpe varieties

comple tpes

all tpe, Comple tpe varieties

choice tpe, Comple tpe varieties

elements, Defining the parts of a structure

occurrence constraints, Defining the parts of a structure

sequence tpe, Comple tpe varieties

compleTpe element, Defining data structures

concrete part, The concrete part

D

definitions element, WSDL elements

E

element element, Defining the parts of a structure

maOccurs attribute, Defining the parts of a structure

minOccurrs attribute, Defining the parts of a structure

name attribute, Defining the parts of a structure

tpe attribute, Defining the parts of a structure

L

logical part, The logical part

M


29/29

9/11/11 Inde

eage eee, WSDL eee, Defiig Lgica Meage Ued b a Seice

O

eai eee, WSDL eee

P

a eee, Defiig Lgica Meage Ued b a Seice, Meage a

eee aibe, Meage a

ae aibe, Meage a

e aibe, Meage a

eee, WSDL eee

Te eee, WSDL eee, P e

R

RPC e deig, Meage deig f iegaig ih egac e

S

eece eee, Ce e aieie

eice eee, WSDL eee

T

e eee, WSDL eee

W

aed dce e, Meage deig f SOAP eice

WSDL deig

RPC e, Meage deig f iegaig ih egac e

aed dce e, Meage deig f SOAP eice

definindo um arquivo wsdl

Documents