Forums

Hi

Concerning TCP/IP web services, am I correct in assuming IIS is still required to run them? And question 2, is it possible/reasonably straight-forward to consume them from a .NET application?

Regards
David

Hi

Concerning TCP/IP web services, am I correct in assuming IIS is still required to run them? And question 2, is it possible/reasonably straight-forward to consume them from a .NET application?

Regards
David

Hi David,

Yes, the web services, as created by the wizard, can be used by any external consumer via standard TCP/IP. SOAP and HTTP are amongst the options supported. The wizard, as documented in the Jade Developer manual and white paper will create a bunch of classes for the web service exposure. It will export a WSDL file, which is a published definition document of the web service which can be imported by the consumer platform as part of its configuration.

There is a different web service protocol which is proprietary to Jade - called Direct Web Services - which can only be used between Jade systems. It uses an unpublished TCP/IP protocol which is more efficient, but non-standard.

As standard, the Jade web services use IIS or Apache, via JadeHttp.dll (or the equivalent Apache mod).
All of this is documented in several places:
[*] DevRef.pdf - chapter 16 (a good overview of Providers and Consumers)
[*] InstallConfig.pdf - Chapter 5: configuration of IIS / Apache, JadeHttp, etc
[*] WebServices.pdf - a Jade White paper with practical example.

The IIS/Apache interface provides a test harness whereby you can test a newly created web service provider by simply pointing your web browser at it. By following the manual it should be easy to put together a simple proof of concept ("Hello world") web service to test with your .Net client. It helps to import the WSDL back into the Jade wizard to create a compatible Jade consumer to verify functionality.
The Jade Web Service classes are available for customising where you can override standard behaviour, if necessary.

Thanks Murray.

I did a proof of concept quite a while back using HTTP web services and did find them easy to consume from a .NET app, but you've answered my question I think, that the TCP ones are really Jade-to-Jade. Thanks for all that info, will be very useful when I go to recall how to do it all again.

Cheers
david

Thanks Murray.

I did a proof of concept quite a while back using HTTP web services and did find them easy to consume from a .NET app, but you've answered my question I think, that the TCP ones are really Jade-to-Jade. Thanks for all that info, will be very useful when I go to recall how to do it all again.

Cheers
david

I had asked Jade if it was possible to publish the Jade Direct Web service protocol, as we had a use for it for interfacing to an in-house Java system, but the details are not available (there is still an NFS on file, but don't hold your breath).

If you do want to use your own transport and not bother with IIS / Apache / HTTP, then the documentation gives you some clues. In the DevRef PDF manual (Jade 6.3, ch 16, p520) there is a section called "Using Communications Protocols Other than HTTP in your Web Service". By subclassing the Jade WebService classes and reimplementing key methods you can implement pretty much any transport you like. As an exercise I got sample "web services" running with alternative transports such as "memory variable" (i.e. no comms at all) and "disk file". It took a little bit of playing around to work out the correct order that the hooks get called, and I think you still may need an Application definition to get it to run. The methods to reimplement are invoke(), processReply() and sendrequest() which allow you to grab the incoming and outgoing messages and provide you own code to send and receive them.
However, the more customisation you do, the more you may consider a cleaner DIY design of your own. Sometimes a full Web Service with SOAP can be overkill when the messages are simple XML between in-house systems.