There is no need to create a special runner for Genero Web Services 2.x. Instead, the GWS 2.x library is imported into your applications. If you want to migrate your existing 1.x 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:
import com
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.
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")
import com
DEFINE serv com.WebService
DEFINE op com.WebOperation -- Operation of a WebService
LET serv = com.WebService.CreateWebService( "EchoInteger", "http://tempuri.org/webservices")
LET op = com.WebOperation.CreateRPCStyle( "echoInteger", "EchoInteger", echoInteger_in, echoInteger_out) CALL op.setInputEncoded(true) CALL op.setOutputEncoded(true) CALL serv.publishOperation(op,NULL)
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.
If you use a variable as the name of the function to publish, you will have an error message at compile time.
For example
com.WebOperation.CreateRPCStyle(test,"Add",add_in,add_out)
Where test is a string variable, add_in and add_out are input and output records.
At compile time, you get the error message
error:(-9054) Web service function must be a string
The function name in parameter can only be a string literal not a string variable.
Since version 2.21, FGL has introduced the concept of PUBLIC/PRIVATE function, there is a risk for a user to publish private functions. Private functions are not always available at runtime.
As a workaround you can add a switch depending on the function name value in order to call the appropriate publication API with the name in a string literal such as following sample:
CASE function_name
WHEN "Operation1"
LET op = com.WebOperation.CreateDocStyle("Operation1","Operation1",op1_in,op1_out)
WHEN "Operation2"
LET op = com.WebOperation.CreateDocStyle("Operation2","Operation2",op2_in,op2_out)
OTHERWISE
DISPLAY "ERROR"
END CASE
In Java or in .NET you cannot publish different numbers of operations for a
same service, everything is done at compile time. For instance, when you
publish a web service in Java, only the public methods will be published as
operation of the service. There is no way to add or remove some methods at
runtime. The only way you have is to create another Java class.
Be aware that if you dynamically change the service operations names you are creating a different service, which might be confusing for the web service client.
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.
fglwsdl -o NewClientstub http://localhost:8090/MyCalculator?WSDL
If you use a Genero 2.2x runner for the GWS Client application, you must:
fglwsdl -compatibility -o NewClientstub http://localhost:8090/MyCalculator?WSDL
You must regenerate all client stubs into your application using the fglwsdl tool. This is mandatory because the generated code is based on the low-level COM and XML APIs and is completely different from versions prior to 2.1x; otherwise, you won't be able to execute the code.
It is recommended to regenerate all client stubs into your application using the fglwsdl tool.
It is recommended to regenerate all client stubs into your application using the fglwsdl tool.
If you have modified the server location at runtime via the generated global variable in your client application, you MUST apply following modification:
LET Calculator_CalculatorPortTypeLocation = "http://host:port/Calculator"
LET Calculator_CalculatorPortTypeEndPoint.Address.Uri = "http://host:port/Calculator"
In class com.WebServiceEngine, two options have been renamed and two options moved to a new class.
Renamed options
The http_invoketimeout and tcp_connectiontimeout options have been respectively renamed into readwritetimeout and connectiontimeout, as they are now available for either HTTP or TCP protocol. While the old option names remain for backward compatibility, using the new option names is strongly recommended.
Moved options
xml_ignoretimezone and xml_usetypedefinition options were part of the com.WebServiceEngine class. They have been moved to the class xml.Serializer, which groups functions on serialization.