Using the SOAP Inbound Adapter
This topic briefly discusses the class EnsLib.SOAP.InboundAdapterOpens in a new tab, which you can use as an alternative to EnsLib.SOAP.ServiceOpens in a new tab (described in Creating a Web Service in a Production).
The standard way to create a web service in an interoperability production is to create a subclass of EnsLib.SOAP.ServiceOpens in a new tab 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. In contrast, using the EnsLib.SOAP.InboundAdapterOpens in a new tab 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.InboundAdapterOpens in a new tab) 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.InboundAdapterOpens in a new tab 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.GlobalBinaryStreamOpens in a new tab) 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:
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.
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.
Specify other settings as needed; see Settings for the SOAP Inbound Adapter.
Run the production.