Using the SOAP Inbound Adapter
This appendix briefly discusses the class EnsLib.SOAP.InboundAdapter, which you can use as an alternative to EnsLib.SOAP.Service (which is described in “Creating a Web Service in a Production.”)
The standard way to create a production web service is to create a subclass of EnsLib.SOAP.Service and set up a web server to be your production web server. In this way, your system will be able to utilize all the SOAP and security features provided by a commercial web server and the InterSystems IRIS® SOAP framework. Using the EnsLib.SOAP.InboundAdapter is easier to configure and lighter weight but doing so bypasses the above mentioned formal web support machinery. Also, the adapter does not expose the WSDL and test page the way the standard InterSystems IRIS SOAP framework does.
The SOAP inbound adapter (EnsLib.SOAP.InboundAdapter) does not require web server software. Instead it spawns a TCP listener job using the InterSystems IRIS super server. This lets you run your service in a foreground window, which is useful for debugging. (To do this, you must be running the service locally. Also make sure the PoolSize setting is 1 and the JobPerConnection setting is false.) It also supports TLS.
The EnsLib.SOAP.InboundAdapter listens for HTTP input on a given port. When the adapter receives input, the following occurs:
It extracts the HTTP SOAPaction header.
It creates a stream (%Library.GlobalBinaryStream) that contains the body of the input.
It calls the web method that corresponds to the given SOAPaction.
This adapter provides an advantage in that it supports persistent connections for successive SOAP calls. Also, if you use it with JobPerConnection=0, it can retain expensively instantiated resources such as XPath parsers even across successive connections that encompass individual SOAP service calls.
To use the InterSystems IRIS SOAP inbound adapter, write and compile a new business service class in Studio. The following list describes the basic requirements:
Your class should provide values for SERVICENAME and other parameters, as described in “Basic Requirements.”
The class should define web methods, as described in “Defining Web Methods for Use in InterSystems IRIS.”
Optionally, to disable support for calls via the adapter in your service, add this to your class:
Use the Management Portal to do the following:
Add an instance of your custom class to the production.Important:
Ensure that the configuration name is the same as the full class name, including package. This is a requirement for running a production web service.
Enable the business service.
Set the PoolSize setting to 1 so that the adapter can use its TCP listener.
Set the StayConnected setting to 0. Otherwise, clients may hang for their timeout period while waiting for the server to drop the connection.
Run the production.