Calling services

Imports and exports allow modules to publish their services and to use services from other sources. Imports and exports require binding information, which specifies the means of transporting the data from the modules.

You can use an import to access functions that are not a part the module that you are assembling. An export is a published interface from a component or import to offer its service to the outside world, for example, as a web service. Stand-alone references allow a Java™ program to start SCA components or imports.


Business objects and interfaces for imports and exports

To use imports and exports in assembly diagrams, it is a good practice to put the business objects and interfaces that are used by the import and exports into a library so they can be shared. Then, add a dependency on the library to all of the modules that use these common resources. Avoid copying the same business objects and interfaces into different modules to use them.


Imports

You can use an import to access functions that are not a part of the module that you are assembling.

Imports are used in an application in exactly the same way as local components. This consistency provides a uniform assembly model for all functions, regardless of their locations or implementations.

Imports have interfaces that are the same as, or a subset of, the interfaces of the remote service they are associated with so that those remote services can be called. To share the interfaces between modules, put the interfaces into a library. Then, for both modules, add a dependency on the library to use its resources.

Imports and exports require binding information, which specifies the means of transporting the data from the modules. An import binding describes the specific way that an external service is bound to an import component. For an import that is generated from an export, the binding type of the import is automatically specified.

Imports can use the following bindings: SCA, web service, HTTP, messaging (JMS, MQ JMS, generic JMS, MQ), stateless session Enterprise JavaBean (EJB), and EIS. Available function (or business logic) implemented in remote systems (such as web services, EIS functions, EJBs, or remote SCA components) is modeled as an imported service.

If using the palette in the assembly editor to create the import, you must specify a binding type for the external service in order to test it.



Related tasks:

Create imports

Generating SCA bindings


Exports

An export is a published interface from a component or import that offers its service to the outside world, for example, as a web service.

Exports have interfaces that are the same as or a subset of the interfaces of the component or import they are associated with so the published service can be called. An export dragged from another module into an assembly diagram automatically creates an import. Exports that are shown under the module assembly in the Business Integration view can also be used to imports in other modules.

Each export has an address at which it is deployed on the server. The export can be exposed at that address.

Imports and exports require binding information, which specifies the means of transporting the data from the modules. When use the Generate Export action from the menu of a component, you need to select the binding so the binding is generated when the export is created. An export binding describes the specific way a module's services are made available to clients. If an export in a module assembly does not have any binding, when deployed, SCA binding is assumed.

For enterprise information systems (EIS), an export allows an event in the enterprise system, such as the creation of a business object in SAP, to drive an action. Unlike other exports, you cannot drag an export with an EIS binding to create an EIS import.



Related tasks:

Create exports

Generating SCA bindings


Stand-alone references

You can use Stand-alone references in a Java™ program to invoke SCA components or imports.

Services that are not defined as SCA components ( JavaServer Pages) can still invoke SCA components; they do so through the use of stand-alone references. Stand-alone references contain partner references that identify the components to call. On their own, stand-alone references do not have any implementation or interface.

You can use the palette in the assembly editor to create stand-alone references in the module assembly. You can add partner references to the stand-alone references and wire them to target components or target imports.

You can use only one stand-alone references node in each assembly diagram.



Bindings

Imports and exports require binding information. Binding information specifies the means of transporting the data from the modules.

Bindings for imports and exports have different purposes. An import binding describes the specific way an external service is bound to an import component. An export binding describes how that export (or service) will be published or made available to clients outside the module.

A key to service-oriented architecture is the ability to expose services with a number of binding options and the ability to call services using industry norms. Binding types are associated with imports and exports using the assembly editor.

The kind of binding determines what kind of client is supported; for example, a web service binding makes the service available to any web-based client, while an SCA binding makes it available to other SCA modules. Import bindings tell the SCA runtime processes how to access an external service. For example, if you publish a service with an SCA export binding, an import with a JMS binding will not be able to successfully call it. The SCA binding is the default binding; if no binding is specified for an export, the runtime process assumes an SCA binding when the module is deployed. You can use an import with an SCA binding to access a service in another SCA module. You can use a web service import binding to bind an external web service to an import. The import binding does not have to be defined at development time; it can be defined at deployment time.

Creating an export specifies that a component or import is being externalized for use outside the module. The main reason for specifying the SCA binding type on the export is that it allows for the most efficient cross-module calls of the exported entity. If, for example, you specify the web service export binding, the component or import is invoked across the web instead of through a construct that approximates a direct call. A reason to not use the SCA export binding would be to allow clients outside of the SCA programming model to invoke the exported component or import. Note that you can create more than one export for a component or import, so you could effectively export the component or import with more than one binding if you specify a different binding type on each of the exports. You could even choose to export one set of interfaces with one binding type and another set of interfaces with another binding type. Because the SCA bindings are easy to use ( the SCA export binding requires no binding information), you might choose to use them for prototyping work, and replace or augment them as the prototype later evolves.

If modules are running on the same server, an SCA binding is the easiest and fastest to use. The same is also true of modules deployed in the same cluster. For a service to be published as a web service and to be available to other modules in the same cluster, consider using two exports, one with a web service binding and one with an SCA binding.

The enterprise service discovery wizard creates imports and exports representing a service on an EIS system. These bindings are discussed in "Accessing external services with adapters." The bindings created are of an EIS type. An EIS binding provides synchronous communication with the service on the EIS system.

Java™ Message Service (JMS), WebSphere MQSeries (MQ) and WebSphere MQSeries JMS (MQ JMS) bindings are used for interactions with messaging systems, where asynchronous communication through message queues are critical for reliability. These bindings are discussed in "Accessing external services with messaging systems."

Another binding is the HTTP binding. The Hypertext Transfer Protocol (HTTP) is a widely-used protocol for transferring information on the web as defined by the World Wide Web Consortium (W3C). Today many standard HTTP requests such as GET, POST, PUT, and DELETE are a part of this widely used protocol. This binding is discussed in "HTTP data binding."

An import can also have a stateless session Enterprise JavaBean (EJB) binding, but an export cannot.

Binding resource configurations extend the supplied bindings with bindings that you can create yourself. For information on binding resource configurations, see "Working with configurations that access external services."

The assembly editor lists the bindings supported and simplifies the creation of them when you want to create an import or export. The import and export have different icons to indicate the type of binding. The following image shows an import and an export with no bindings: A properties view in the assembly editor displays the binding information of any import or export.



Related tasks:

Create exports

Generating SCA bindings

Create imports


SCA bindings

Service Component Architecture (SCA) bindings are used for SCA invocations between modules running in the same runtime cell. This binding is simple to configure and provides seamless integration between modules.

The SCA binding lets your service communicate with other services in other modules. You can use an import with an SCA binding to access a service in another SCA module. You can use an export with an SCA binding to offer a service to other modules.

All imports and exports need bindings. Within the assembly editor, by default, a runtime process applies an SCA binding to an export with no binding.

If modules are running on the same server, an SCA binding is the easiest and fastest binding to use. The same is also true of modules deployed in the same cluster. For a service to be published as a web service and to be available to other modules in the same cluster, consider using two exports, one with a web service binding and one with an SCA binding.

An SCA binding on an import specifies an SCA-bound export in another module. That export can be connected to either a component or an import. As a result, the SCA import binding requires only two pieces of information: the name of the export it is calling and the module containing that export. The export must also have an SCA export binding. If the export has any export binding other than SCA, you cannot import it in another module with the SCA import binding. You must import it with the corresponding import binding type.



Related tasks:

Generating SCA bindings

Web service bindings

You can use a web service binding to invoke existing web services and expose functionality within the module as a web service. A web service binding offers a way to enable an import or export for remote calls, or for a data request.

A web service binding provides a specification for transmitting messages to and from a web service. You can use a web service import binding to call an external web service to an import. You can use a web service export binding to provide a service to external clients as a web service.

Most components have WSDL interfaces. WSDL files are also used to describe services, ports, and bindings. A web service binding describes how the service is bound to a messaging protocol, particularly the SOAP messaging protocol. The web service binding of an export or import references a port. That port holds details of binding information for exports or imports. The port and service are generated automatically when you create the binding for an export; however, deleting an export or an import does not delete the port.

To use a web service binding between exports and imports, you need to share the port. You can create an export with a web service binding and drag it into another module to create an import there with a matching interface. When a web service binding is generated for an export, a WSDL file is generated in the same folder as the interface. To create store interfaces in a library where they can be shared, do that before generating a web service binding for the export if you can. If you have already generated the export and the binding and need to share the interface and the port later, manually move the web service port.


Limitations

There can be many ports for an interface, but a port can only apply to one interface. Therefore, a component that needs to export or import multiple interfaces requires multiple exports or imports. Each export or import needs to have one interface and a web service binding configured with a corresponding port. The location of the port matches the location of the interface from which it is generated. Exports and imports use ports, but they do not own them.


Moving an existing web service port to a library

To share an existing web service port, move the web service port to a library.

To move an existing web service port to a library:

  1. In the Business Integration view, expand External Web Services > Web_Service_Ports.

  2. Select the port you are using.
  3. Right-click and select Refactor > Move from the menu.
  4. Choose a new location for the file. This action moves the WSDL file to the location that you have chosen.

  5. If you have previous build errors relating to this binding, run Project > Clean for all the projects.



Create exports

You can create an export for a component so that its business service can be used by other modules.

You create an export for a component by using the assembly editor. Follow any of these steps to create an export:



Related concepts:

Exports

Bindings


Create imports

You can create an import to use an existing service that is not part of the module that you are assembling.

You create an import for a component by using the assembly editor. Follow any of these steps to create an import:

The following image shows StockQuote as an import, which means the service is being called from outside the module:



Related concepts:

Imports

Bindings


Delete exports and imports

You can delete an export or import in the assembly editor, along with any resources that directly support the export or import binding.

To delete exports and imports:

  1. In the assembly editor, right-click the export or import to delete and select Delete. A Confirm Delete window opens.

  2. If you are deleting a web service export and it has a WSDL port that does not exist in the same file as a WSDL port type, select the check box that is displayed in the window to delete the WSDL file that contains the port.

  3. Click Yes.



10. Invoking a service from another module

Mediation modules and business integration modules have interfaces in their exports. You can invoke any type of module from any other type of module. You can invoke any type of module from any other type of module. You can invoke one mediation module from another mediation module. Or, if you are running your application on the WebSphere Process server you can invoke a mediation module from a business integration module.

To integrate two modules, use the Service Component Architecture (SCA) binding. You can generate SCA bindings automatically in the assembly editor. The kind of binding determines what kind of client is supported; an SCA binding makes it available to other SCA modules.

Bindings for imports and exports have different purposes. An import binding describes the specific way an external service is bound to an import component. An export binding describes how that export (or service) will be published or made available to clients outside the module.

To access a module from another module, you need an export and an import with the same interface, and with SCA binding. You also need to point the import to the module and export that it will access.

To invoke a service from another module:

  1. In the module whose service you want to use, create an export, and add an interface.
  2. Right-click the export and select Generate Binding > SCA Binding. Save the export.

  3. In the module that will import the service from the module that you created in step 1, add an import, and give it the same interface as the export to access.

    An interface must be in a dependent library in order to be shared between modules.

  4. Right-click the import and select Generate Binding > SCA Binding.
  5. To add the service to import, right-click the import and select Select Service to Import. Available services (exports) are listed for you. Select the export of the module to invoke.


Example

Another way to invoke a service from another module is to create an export with an SCA binding and then save the export. Locate the export in the Business Integration view, and drag it to another module. An import with a matching SCA binding is created in the second module.



11. Generating SCA bindings

The Service Component Architecture (SCA) binding is simple to configure and provides seamless integration between modules. You can generate SCA bindings automatically in the assembly editor. Bindings for imports and exports have different purposes. An import binding describes the specific way an external service is bound to an import component. An export binding describes how that export (or service) will be published or made available to clients outside the module.

The kind of binding determines what kind of client is supported; an SCA binding makes it available to other SCA modules. You can generate an SCA binding when use the palette in the assembly editor to imports and exports.

To generate an SCA binding:

  1. If there is no interface defined on the import or export, add the interface first. See related tasks for instructions on adding the interface.
  2. Do one of the following:

    • For an import, under the Outbound Imports section, select SCA and drag it onto the canvas. Add your interface to it.

    • For an export, under the Inbound Exports section, select SCA and drag it onto the canvas. Add your interface to it.
    • Alternately, under Components, drag an import or export onto the canvas. Right-click the import or export and select Generate Binding > SCA Binding. An SCA binding is generated without requiring you to supply additional information. Here is an import with an SCA binding:

  3. To add the service to import, right-click the import and select Select Service to Import. Available services are listed for you.

Another way to invoke a service from another module is to create an export with an SCA binding and then save the export. Locate the export in the Business Integration view, and drag it to another module. An import with a matching SCA binding is created in the second module.



Related concepts:

Exports

Bindings

Imports

SCA bindings


12. Import the ServiceGateway interface and schema

A service gateway has a single generic export and a single generic gateway interface. The generic gateway interface named ServiceGateway, along with schema files, is provided for you. You can import the predefined service gateway resources into your module or library.

You can quickly create all of the starter artifacts for a service gateway, including the data handlers and interfaces described here, by using pattern generators provided in the Patterns Explorer.

To import the predefined ServiceGateway interface and schema:

  1. In the Business Integration view, expand a module, mediation module, or library.
  2. Double-click Dependencies to open the Dependency Editor.

  3. Expand the Predefined Resources section.

  4. Select Service gateway interface.

  5. Select Native Body schema for Native Body DataHandler.

  6. In the Business Integration View, expand your project's Data Types and Interfaces category. Note the data types and ServiceGateway interface that are created under the StandardImportFilesGen folder in each category.

  7. Double-click the ServiceGateway interface to open it in the Interface Editor. As you can see, the interface as two operations; requestOnly and requestResponse.


You can now add the generic gateway interface ServiceGateway to the export of your gateway module.


13. WSDL import and export files

Web Services Description Language (WSDL) files are commonly shared among users working on service-oriented architecture (SOA) projects. You can import and export WSDL files with options to make the WSDL files interoperable with different vendors, and reusable within your workspace.

If you need to use a WSDL file in a module, you can copy it to the module. Alternately, copy the WSDL file to a library and, in the module, set a dependency on the library so that you can use the library's resources. If you try to drag a WSDL file from another type of project, for example a web project, an error message prompts you to copy the WSDL file to the module or library.

Interoperability and reuse are two good reasons to use the importing and exporting WSDL file wizards in IBM Integration Designer instead of any manual process.


Interoperability

SOA projects by definition integrate a wide spectrum of applications. Although these applications are themselves defined as services, that is, they have an XML layer of code that separates them from the actual implementation, even that XML layer can have inconsistencies. These inconsistencies can lead to interoperability problems. Typically, these interoperability problems occur when enterprises are building their SOA applications with development products from several vendors. One common difference is that some vendors place the port type, that is, the interface in IBM Integration Designer in one file, and the types it references in separate schema files. Other vendors place their schemas within the same file; a technique known as inline schemas or inline business objects.

IBM Integration Designer has an import wizard that can extract a web service endpoint into a separate file and extract inline schemas into separate schema files. You also have the option of importing a WSDL file containing its web service endpoint and inline schemas and extracting these elements later with a refactoring wizard.

An export wizard can place an interface and business objects inline, if they are in an external file and referenced by the WSDL file. If an endpoint such as a port is defined in one file and a port type (or interface) is defined in another file, then this wizard can merge them also.

Use these importing, exporting, and refactoring wizards, you can share WSDL files created in IBM Integration Designer with others in your organization regardless of the different development environments. Conversely, you can share WSDL files and refactor WSDL files produced by other tools from different vendors inside IBM Integration Designer.


Reuse

When you are working on large SOA projects that share many modules among many developers, reuse can play a significant role in reducing development time. On SOA projects, sharing interfaces and business objects in libraries is a good programming practice to minimize development time. The wizard supports and encourages reuse. For example, the import wizard can extract a service endpoint from a WSDL file, so the port type can be reused. It can also extract inline schemas so the business objects can be reused. The extracted business objects can themselves be extended and reused.


Interoperability with services from other vendors

Web Services Description Language (WSDL) files are commonly shared amongst users working on service oriented architecture (SOA) projects. Different users use different software vendors. The vendors have different interpretations of the WSDL standard. This section describes some helpful wizards that ensure WSDL files you import are compatible with IBM Integration Designer editors and WSDL files you export are compatible with other software vendors. SOA projects by definition integrate a wide spectrum of applications. Although these applications are themselves defined as services, that is, they have an XML layer of code that separates them from the actual implementation, even that XML layer can have inconsistencies. These inconsistencies can lead to interoperability problems. Typically, these interoperability problems appear when enterprises are building their SOA applications with development products from several vendors. One common difference is that some vendors place an interface in one file and the references in that interface, that is, the schemas, in separate files. Other vendors place their schemas within the same file, a technique known as inline schemas.

Both types of vendors are technically correct as they both comply with the formal WSDL specification. Practically speaking, however, these two types of WSDL files lead to aggravating interoperability problems that can usually only be solved by manual workarounds.

If you are experiencing this interoperability problem, IBM Integration Designer has some helpful wizards.



Related tasks:

Import WSDL or XSD files

Export WSDL files


Related reference:

WSDL binding styles

Import WSDL or XSD files

Import Web Services Description Language (WSDL) files or XML Schema Definition (XSD) files into a module or library through an import function are discussed. To import WSDL or XSD files into a module, right-click the module or library name in the Business Integration navigation view, and select Import from the menu. In the Import window, select WSDL and XSD and click Next. The Import a WSDL, XSD or Both wizard opens. Alternately, from the menu, you can select File > Import. In both cases if a module is selected then it will be preselected as the module for the imported files. If no module is selected, then you must select the module from the list available or create a new module.

Choose between importing a local WSDL or XSD file, which also lets you import both, or a remote WSDL or XSD file. Importing locally means the file is on your file system Importing remotely means the file is on a remote location that can be accessed through a URL address.

At run time, business objects are rendered. See Supported XSD and WSDL artifacts. Avoid duplicate business objects and duplicate WSDL interfaces. You might not notice the duplicates if they are in another library or module that you are interacting with. See Duplicate business objects.



Related tasks:

Interoperability with services from other vendors

Export WSDL files


Related reference:

WSDL binding styles

Export WSDL files

Export Web Services Description Language (WSDL) files from a module along with the options you can use at export time are discussed. To export WSDL files from a module, right-click the module name in the Business Integration navigation view, and select Export from the menu. In the Export window, select WSDL/Interface and click Next. The WSDL/Interface Export to File System page opens. You can also select an interface, business object or web service port in the module; and the wizard will open with all the artifacts. Alternately, from the menu, you can select File > Export.

Default file naming rule: The existing WSDL file name remains the same in an export. If you merge all contents into a single WSDL file then the interface (PortType) is used as the container. In refactoring (that is, if you are extracting WSDL and XSD elements), a new name is not generated. The default name is <old name>_Endpoint.wsdl for the file that contains the WSDL though you may override the name.

Note that if you use a web services binding that uses the Java API for XML Web Services (JAX-WS), the export name must comply with Java class name rules.



Related tasks:

Interoperability with services from other vendors

Import WSDL or XSD files


Related reference:

WSDL binding styles

WSDL binding styles

A Web Services Description Language (WSDL) binding can be created in several forms. For most purposes, document literal wrapped is the best binding style.


Introduction

A WSDL document describes a web service. A WSDL binding describes how the service is bound to a messaging protocol, particularly the SOAP messaging protocol. A WSDL SOAP binding can be either a Remote Procedure Call (RPC) style binding or a document style binding. A SOAP binding can also have an encoded use or a literal use. This combination gives you four style and use models: RPC encoded, RPC literal, document encoded, and document literal. Add to this collection a pattern which is commonly called the document literal wrapped pattern and you have five bindingstyles to choose from when creating a WSDL file.

Bindings generated from IBM Integration Designer always use the document literal wrapped pattern. Here are the basic characteristics of that pattern:

The following tables illustrate the various WSDL patterns. For a more detailed discussion of this topic, see "Which style of WSDL should I use?" at http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/ .


RPC styles

Table 1 uses one Java™ method and shows the approximate code that would result if you run that method through a Java-to-WSDL tool specifying to generate RPC encoded and RPC literal WSDL files. The Java method is public void myMethod(int x, float y);. This method is invoked with 5 as the value for parameter x and 5.0 for parameter y.

WSDL Styles Quick Reference - RPC

  RPC encoded RPC literal
WSDL Example
<message name="myMethodRequest">
 <part name="x" type="xsd:int"/>
  <part name="y" type="xsd:float"/>
</message>

<message name="empty"/>

<portType name="PT">
 <operation name="myMethod">
  <input message="myMethodRequest"/>
  <output message="empty"/>
 </operation>
</portType>

<binding .../>
<message name="myMethodRequest">
 <part name="x" type="xsd:int"/>
  <part name="y" type="xsd:float"/>
</message>

<message name="empty"/>

<portType name="PT">
 <operation name="myMethod">
  <input message="myMethodRequest"/>
  <output message="empty"/>
 </operation>
</portType>
<binding .../>
Instance Message
<soap:envelope>
 <soap:body>
  <myMethod>
   <x xsi:type="xsd:int">5</x>
   <y xsi:type="xsd:float">5.0</y>
  </myMethod>
 </soap:body>
</soap:envelope>
<soap:envelope>
 <soap:body>
  <myMethod>
   <x>5</x>
   <y>5.0</y>
  </myMethod>
 </soap:body>
</soap:envelope>
Advantages

  • The WSDL is about as straightforward as it is possible for a WSDL to be.
  • The operation name appears in the message, so the receiver has an easy time dispatching this message to the implementation of the operation.

  • The WSDL is still about as straightforward as it is possible for WSDL to be.
  • The operation name still appears in the message.
  • The type encoding info is eliminated.
  • RPC literal is WS-I compliant.

Disadvantages

  • You cannot easily validate this message since only the <x ...="">5</x> and <y ...="">5.0</y> lines contain things defined in a schema; the rest of the soap:body content comes from WSDL definitions.
  • The type encoding information (such as xsi:type="xsd:int") can degrade throughput performance.
  • Although it is legal WSDL, RPC encoded is not WS-I compliant.

  • You still cannot easily validate this message since only the <x ...="">5</x> and <y ...="">5.0</y> lines contain things defined in a schema; the rest of the soap:body content comes from WSDL definitions.


Document styles

Table 2 uses one Java method and shows the approximate code that would result if you run that method through a Java-to-WSDL tool specifying to generate document literal and document literal wrapped WSDL files. Again, the Java method is public void myMethod(int x, float y);. Again, this method is invoked with 5 as the value for parameter x and 5.0 for parameter y.

The document encodedstyle is not WS-I compliant and is not useful, so it is not included in this evaluation.

WSDL Styles Quick Reference - DOC

  DOC literal * DOC literal wrapped
WSDL Example
<types>
 <schema>
  <element name="xElement" type="xsd:int"/>
  <element name="yElement" type="xsd:float"/>
 </schema>
</types>

<message name="myMethodRequest">
 <part name="x" element="xElement"/>
 <part name="y" element="yElement"/>
</message>

<message name="empty"></message>

<portType name="PT">
 <operation name="myMethod">
  <input message="myMethodRequest"/>
  <output message="empty"/>
 </operation>
</portType>
<types>
 <schema>
  <element name="myMethod">
   <complexType>
    <sequence>
     <element name="x" type="xsd:int"></element>
     <element name="y" type="xsd:float"></element>
    </sequence>
   </complexType>
   </element>

   <element name="myMethodResponse">
    <complexType></complexType>
   </element>
 </schema>
</types>

<message name="myMethodRequest">
 <part name="parameters" element="myMethod"/>
</message>

<message name="empty">
 <part name="parameters" element="myMethodResponse"/>
</message>
<portType name="PT">
 <operation name="myMethod">
  <input message="myMethodRequest"/>
  <output message="empty"/>
 </operation>
</portType>
Instance Message
<soap:envelope>
 <soap:body>
  <xElement>5</xElement>
  <yElement>5.0</yElement>
 </soap:body>
</soap:envelope>
<soap:envelope>
 <soap:body>
  <myMethod>
   <x>5</x>
   <y>5.0</y>
  </myMethod>
 </soap:body>
</soap:envelope>
Advantages

  • You can finally validate this message with any XML validator. Everything within soap:body is defined in a schema.
  • There is no type encoding information.
  • Document/literal is WS-I compliant, but with restrictions (see "Disadvantages").

  • Everything that appears in soap:body is defined by the schema, so you can easily validate this message.
  • The method name appears in the SOAP message.
  • There is no type encoding information.
  • Document literal is WS-I compliant, and the wrapped pattern meets the WS-I restriction the SOAP message's soap:body has only one child.

Disadvantages

  • The operation name in the SOAP message is lost. Without the name, dispatching can be difficult, and sometimes impossible.
  • WS-I only allows one child of soap:body in a SOAP message, but this example has two children.
  • The WSDL is more complicated.

  • The WSDL is more complicated still.

  • If you have overloaded operations, you cannot use the document literal wrapped style.



Related tasks:

Interoperability with services from other vendors

Import WSDL or XSD files

Export WSDL files


14. Change an external service without interruption

When you design a system or develop modules, it is sometimes helpful to place an intermediary module between a module and an external service that it invokes. You can use this approach only if you use SCA bindings.

One advantage of using an intermediary module is that you can then change the external service or application that your application is invoking without interruption. This example uses a web service import to illustrate the concept.

The first figure below shows module A with an import that invokes a remote service through a direct connection. If you wanted module A to invoke a different remote service, you would need to update the logic. You would then need to stop the old version of the module and uninstall it from the server. The new version of the module can then be installed and started. During this process, there is an interruption of service for module A.

If you use an intermediary module in your application and connect it to module A with an SCA binding, you have more flexibility. The figure below shows that configuration. Module A has an import that is wired to the export of an intermediary module or mediation module, module B. The modules must have matching interfaces. In the scenario described in this topic, they must have an SCA binding. Module B invokes the service. Module B is a facade; module A contains the real business logic.

The figure also shows another service, remote web service 2. In preparation for using that service, module C and its web service import have been built and tested using the WebSphere Test Environment.

When that new module is ready to be deployed, you can use the Process Server administrative console to point the SCA import in module A from the old target module (module B) to the SCA export in the new one (module C), creating a seamless transition to the updated service. The figure below shows the new deployment. You can use this method to update an application without causing any interruption in service.

This pattern can also be used for external exports. For example, a module can expose a service through a web service export. Typically, if the logic of the module needs to be updated, there would be an interruption in service. However, if a facade module is used for the web service export, the business logic can be updated without a break in service.

This design principle is more fully explained in documentation for Process Server; see the instructions for isolating modules and targets and for changing targets.



+

Search Tips   |   Advanced Search