Back to Contents


Migration Notes

Summary:


Migrating GWS Server applications

Migrating GWS Server runners only

There is no need to create a special runner for Genero Web Services Extension 2.x. Instead, the GWS 2.x library is imported into your applications. If you want to migrate an existing GWS Server application to 2.x to avoid the need for a special runner, as well as to take advantage of any bug fixes, take the following steps:

  1. Add the following statement at the top of any .4gl module where you have used GWS 1.3x functions:
                     import com
  1. Then, compile and re-link your GWS  Server application (.42r). 

This imports the new GWS com library, and ensures that any GWS 1.3x functions that you have used will be compatible. Your existing Genero 1.3x Client applications, as well as third-party Client applications, will continue to work.

Migrating GWS Server runners and using new APIs

If you want to take advantage of the new features and simplify future migrations, you can migrate your GWS Server runner and also use the new GWS 2.x APIs. All the1.3x publishing functions for all the operations in your application must be replaced with 2.x publishing functions.  Since this does not change the interface, all existing Genero 1.3x Client applications, as well as third-party Client applications, will continue to work.

Since 1.3x only supports RPC-Encoded style services, you must use the RPC style functions of the new 2.x APIs as the replacement functions, with setInputEncoded and setOutputEncoded set to true. And, you cannot add  XML attributes to the records used as Web Service function parameters.

To replace  the fgl_ws_server_publishfunction() statement in an existing GWS Server application; for example:

       CALL fgl_ws_server_publishfunction(
          "EchoInteger",
          "http://tempuri.org/webservices/types/in", "echoInteger_in",
          "http://tempuri.org/webservices/types/out", "echoInteger_out",
          "echoInteger")
  1. Add the following statement at the top of each module:
           import com
  1. Define variables for the WebService and WebOperation objects:
DEFINE serv  com.WebService    
DEFINE op    com.WebOperation  -- Operation of a WebService
  1. Create the GWS Server object:
LET serv = com.WebService.CreateWebService("EchoInteger",
                         "http://tempuri.org/webservices")
  1. Use the 2.x publishing functions for each operation:
LET op = com.WebOperation.CreateRPCStyle("echoInteger",
            "EchoInteger",echoInteger_in,echoInteger_out)
CALL op.setInputEncoded(true)
CALL op.setOutputEncoded(true)
CALL serv.publishOperation(op,NULL)
  1. Compile and re-link your GWS Server application (.42r)

GWS 2.x also allows your Server application (.42r) to contain multiple services. If you would like 2.x and 1.3x GWS  to co-exist in the same .42r executable, replace the existing publishing 1.3x functions as outlined above.


Enhance the GWS Server application to be WS-I compliant (recommended)

Warning: You must be able to change all the Client applications that access your migrated GWS Server.

If you use the Literal styles now available in GWS 2.x for your Web Service, your application will be  WS-I compliant.  However, the migration techniques shown above still use the  RPC/Encoded style (Only RPC/Encoded was supported in GWS 1.3x.).  If you can change all the client applications that access your migrated GWS Server, we recommend that you enhance the GWS Server application to be WS-I compliant. 

  1. Replace the publishing functions in the GWS Server application, as shown above, but omit the setInputEncoded and setOutputEncoded lines shown in the example; the resulting style will be Literal.
          
  2. The enhanced GWS Server will have a new RPC/Literal WSDL that must be used to regenerate the client stub with the fglwsdl tool:
fglwsdl -o NewClientstub http://localhost:8090/MyCalculator?WSDL
  1. Compile that new client stub, and re-link it with the GWS Client application. This operation must be repeated for each Client application accessing that service.

     

  2. Third party Client applications must be changed to use the new WSDL also.

Migrating GWS Client applications

Migration from version 1.3x to 2.10

If you use a Genero 2.10 runner for the GWS Client application, you must:

  1. Regenerate the GWS Client stubs using the -compability option of the fglwsdl tool, so the function prototypes will be compatible:
fglwsdl -compatibility -o NewClientstub http://localhost:8090/MyCalculator?WSDL
  1. Compile the GWS Client stubs and re-link the Client application (.42r).

Migration from version 2.0x to 2.10

You must regenerate all client stubs into your application using the fglwsdl tool. This is mandatoy because the generated code is based on the low-level COM and XML APIs and is completly different from any previous versions; otherwise, you won't be able to execute the code.


com.WebServiceEngine options

In class com.WebServiceEngine, two options have been renamed and two options moved to a new class.

Renamed options

http_invoketimeout and tcp_connectiontimeout options have been respectively renamed into readwritetimeout and connectiontimeout as this is now available for either http or tcp protocol. The old option names remain for backward compatibility but it is strongly recommened to use the new option names.

Moved options

xml_ignoretimezone and xml_usetypedefinition options were part of the com.WebServiceEngine class. They are now moved to a new class xml.Serializer which gather functions on serialization.