SOAPSESSION=1 effect on licensing

Question

Question

Steve Pisani · Dec 15, 2015

Hi,

In an Ensemble message bus that has a Business Service which extends EnsLib.SOAP.Service, I have the option to support SOAP Sessions by setting the parameter SOAPSESSION=1.

The comments says this also effects license consumption.

In what way is license consumption effected ?

note this is version 2015.1, Ensemble Elite (without Web-AddOn).

thanks -

Steve

Discussion (7)2

Log in or sign up to continue

Marcel den Ouden · Jan 5, 2016

Hi Steve,

I have tested with this in the past, when 2011.1 was released and the 10 seconds delay was introduced for anonymous soap calls. With SOAPSESSION=1 the calls utilize the same session on the back-end. Multiple subsequent calls will only use 1 license, and the license will be held until the normal time-out expires. I could easily see this behaviour in the license statistics.

I'm not sure what happens when you do multiple calls in parallel, will they be queued?

0 0

score 0 · Answer 1 · 2015-12-16T08:26:39-05:00

Steve,

here is a link to the related documentation from 2015.2:

http://docs.intersystems.com/ens20152/csp/docbook/DocBook.UI.Page.cls?KEY=ESOAP_web_service#ESOAP_ws_soap_sessions

If I read this correctly, then different SOAP calls do not share the same CSP license slot by default. If you set the parameter SOAPSESSION=1, then a SOAP header will be added to the response that allows the client to maintain the session for subsequent calls.

HTH,

Stefan

score 0 · Answer 2 · 2015-12-16T19:19:50-05:00

Thanks Stefan.

I had read that, and understand how with SOAPSESSIONs enabled, soap calls can utilise the same session on the back-end. My tests definitely show this working.

What I was hoping to discover however, is if license unit consumption is effected or not effected, with the SOAPSESSION=1 model, which is what is implied by the comment against the parameter which says ".Also effects license consumption".

My tests show that license unit consumption for SOAP requests that are session based are no different to others - so - I still can't see that there are an license unit consumption implications.

In fact - it seems that no SOAP calls seem to be consuming licenses in the scenarios I have tested described below when using SOAP UI from an different IP address to the web service server...:

(a) with and without SOAPSESSION=1 set (and where set, CSP header is used by the web client)

(b) with or without Unauthenticated or Password access set on the CSP Application.

(c) with a hang of,say, 10 seconds in the web method (allows me to gather license counts).

(d) web service hosted as a standalone Cache web service, or, as a webservice that's part of a Business Service in a running Ensemble production (csp Gateway used for access).

In all scenarios and combinations of each above, it seems, no license units are consumed at all. I would have expected that (at least for SOAPSESSIONs enabled) a license unit would have been consumed for the duration of the session. My tests do not confirm this, hence the question on trying to clarify what the license implication actually are.. :)

Perhaps a broader understanding of how SOAP requests consume and then release license units is a better approach to addressing this thread.

(Note that my license key does not have the Web-Add option enabled. This is 2015.1.)

Steve

score 0 · Answer 3 · 2016-01-06T01:15:35-05:00

Good question re multiple SOAP requests in parallel.(ie - 2 simultaneouse SOAP requests that have the same CSPCHD soap header identifying the same SOAP Session, send simulateously to the web service).

I have tested this. I sent two SOAP-Session enabled web service requests to the same web service and method, exactly 5 seconds apart. They both used the same session ID in the soap message. The SOAP Service hung for 30 seconds, then, returned the server time.

The responses messages where received, one after the other, in the order they where sent, and 5 seconds apart, so it seems that they are queued FIFO.

Steve

score 0 · Answer 4 · 2016-01-05T09:17:19-05:00

Steve,

I just remember someting else since this is Ensemble; it depends on whether or not you are using an Enterprise license or a C-license (Cache with Ensemble add-on). I'm not entirely sure but I think the E-licenses are unlimited with regards to SOAP.

Marcel

score 0 · Answer 5 · 2016-01-06T01:21:39-05:00

This is correct, and I have been testing this.

Ensemble E-type licenses do not count license units for SOAP service calls into Ensemble. This is true regardless of wether the user is identified, un-identified, or, SOAPSESSION is in play.

With Cache or Ensemble C-type licenses, License units are counted, and additionally, if anonymouse identity is used, a minimum 10 second grace period must be consumed for the connection regardless.

Thanks - Steve

score 0 · Answer 6 · 2016-01-06T01:31:48-05:00

Hi,

I have run some tests in order to answer my own question on this thread, and that is - what are the licensing implications of using SOAPSESSION for web services hosted within Ensemble (E-type). I thought its worth posting the answer here for completeness.

Given that Ensemble E-Type licenses do not consume license units, there are no license implications that I can see. Sure the CSP Session hangs around for the duration of the SOAPSESSION calls until the user decides to end it, but, the license count (seperate from the CSP Sessions) is not effected and remains unchanged.

Thsi is not true for Cache or Ensemble C-type licenses. With the license unit consumed at the begining of the SOAP session, and, with the session on the back-end persisting for all subsequent SOAP Service calls from the web client, until the session expires, or is programatically ended - one needs to be aware that the license unit remains in use for this whole period.

It becomes critical that SOAP applications that that implement SOAPSESSIONS make sure their session are correctly terminated with the back-end when it is no longer needed, otherwise, the license unit will remain in use for, at least, the session timeout number of seconds defined against the web application.

Steve