This complex property @xml contains
data that affects runtime access of a SOAP service. The property is
available on Service parts, on Interface parts, and on functions within
Service and Interface parts.
The
@xml property is useful in the following
cases:
- You are creating a WSDL file and want to avoid exposing your organization's
naming conventions to the people who will receive the WSDL file.
- You are creating an Interface part from a WSDL file and want to
use an EGL package name other than the one provided for you. The property
is also useful when names copied from the WSDL file are not valid
in EGL.
The
@xml property includes the following
property fields, as further described later in this topic:
- name
- A string that maps a pair of names:
- In relation to an EGL Service or Interface part, the pair is as
follows: the name of the EGL Service or Interface part and the name
of the corresponding portType element in the WSDL document
- In relation to an EGL function, the pair is as follows: the name
of the EGL function and the name of the corresponding operation element
in the WSDL document
- namespace
- A string that maps a pair of names:
- In relation to an EGL Service or Interface part, the pair is as
follows: the name of the EGL package and the name of the target namespace
in the WSDL document
- In relation to an EGL function, the namespace property
is ignored
Here is a fuller explanation:
- When you create a WSDL file from an EGL Service part (as occurs
when you generate a Web service), the default behavior is as follows:
- The portType element is given the name of the EGL Service.
- The target namespace of the WSDL file is given the name of the
EGL package, in reverse order and with the prefix http://.
For example, if the package name is com.ibm.egl.mypkg, the
target namespace in the WSDL file is http://mypkg.egl.ibm.com.
You can add an @xml property to
specify the name of the portType element (using the name property
field); to specify the target namespace of the WSDL document (using
the namespace property field); or to specify
both.
The endpoint generated in the WSDL for EGL Web Services
defaults to http://localhost:9081. You might need to change the WSDL
file manually, to match the server port in use on your machine. For
details on the server port in use, see your server documentation.
- When an EGL tool creates an Interface part from a WSDL document,
the default behavior is as follows:
- Takes the name of the Interface part from the portType element
in the WSDL document.
- Takes the name of the EGL package from the target namespace of
the WSDL document. The tool includes the package name in the created
EGL file and, if necessary, creates the package itself.
In this
case, the tool removes the prefix http://, if any, and reverses
the order. For example, if the target namespace is http://mypkg.egl.ibm.com,
the EGL tool makes the EGL package name be com.ibm.egl.mypkg.
In some cases, the names are not valid in EGL. In those
cases, the EGL tool creates valid names and uses the @xml property
to identify the names that are in the WSDL document. The property
ensures that service invocations succeed despite the mismatch in names.
The
EGL tool lets you change the names that it assigned to the Interface
part and package.
Functions in an EGL Service or Interface part represent operation
elements that are embedded in a WSDL portType element. In this case,
workbench processing never considers the target namespace for the
operation element; that namespace is assumed to be the same as that
of the portType element. However, the name of the operation element
in the WSDL file is of concern:
- When you create the WSDL file, the operation name is taken from name property
field of the @xml property. The default
value is the EGL function name.
- If, when an EGL tool is creating an Interface part from a WSDL
document, the operation name is not valid in EGL, the EGL tool creates
a different name for the EGL function but uses the name property
to retain the name of the operation element.