Java/ws – best practice for inbound thread with associated URL

What kind of data are you querying? Is the information stored in a database or external system? If an external system, then how do you query that system? Do you have to pass along the username/password to that system? Do you have a list of valid username/passwords that you’re checking against?

Is there anything in the Result message itself that identifies the intended recipient (not necessarily the User name and Password)?

If so, then perhaps a table with the relationship between the message identifiers and the client (User Name, etc.) can be used?

The question then (and maybe this is what is the essence of your question) is how to make sure only that client now properly identified receives the data and not anybody listening on that URL. The answer might lie in whatever Webservice envelope is wrapped around the payload upon delivery. I do not know the answer to that question.

I wouldn’t know how to go about using the recovery database to queue messages for an inbound WS client. It seems counterintuitive, but it may be possible.

Also, is this going to be a stream of results for each client, or are they going to be querying based on placer ID or MRN? If it’s a stream of results, are you thinking of using a web service query that is something like “get next result” that the clients would call?

The recovery DB doesn’t have the type of functionality that you’re describing. It’s just used to queue messages on each state. For an outbound interface, it’s always going to give you the first message on the outbound queue. You can’t have a thread query the recovery db to give you a different message.

You could have an outbound thread that writes all the messages to a database (SQL Server, Mysql, Sqlite, take your pick) and then your web service thread could run queries against that database to build messages to send. That sounds more doable.

Hey Rob – the design or intended scope of the webservice will be good to know once you know more. In cloverleaf CAA/WS – you will get a basic framework for creating a webservice endpoint that will reference a SOAP or REST consumer.

The underlying consumer is where the actual service will live. You will need to decide if you are exposing a consumable WSDL for SOAP in order for clients to build the calls they will be making to your webservice, or examples on how to make REST calls to initiate whatever work the threads will be doing in order to give a payload response back to the client who made the call to your webservice.

You may need to do some heavy TCL and to David’s point, some SQL to get the job done in the engine.

When i expose endpoints to clients, depending on the use case, may use the ‘PATH’ trx ID(ie. the URL). Which allows me to only expose 1 endpoint, but give each client their own URL without creating multiple java/ws server threads.

Example:

https://hospitalorg.webservice.com:5000/getResults – is the main service, but i supply the orgs querying or posting to the webservice this:

https://hospitalorg.webservice.com:5000/getResults/OrthoSurgCenter/

https://hospitalorg.webservice.com:5000/getResults/PrimaryCareCenter/

Then you can use the TRXID to have some business logic to route or call different data lakes(most likely short – long term storage of results in a sql table). From there you can take the meta data stored in results to qualify the result against your criteria and post the full response back to the client with the result(s)

These design items will be the key to the build.

Depending on release of Cloverleaf, DTC may be of use in your design in place of building your own SQL DB. Unfortunately, DTC is fairly Tcl intensive.