We currently use only IS 6.1 and TN 6.1 and we have created a couple of services that are being exposed to other trading partner via Web Services. I did all the home work, which is created the flow services accordingly and tested locally, I have created the WSDL file, and I have saved the WSDL in a directory in my desktop and we have sent this WSDL file via email to our trading partners along with a technical spec on how to use the Web Services. Very primitive!
The question is: once we have a Web Service built and accessible via the internet, how (what is your suggestion) to expose the WSDL and the corresponding technical specs for trading partners eager to use these services.
I want to try to do this without being forced to deploy Fabric or Glue, and we want to stay away from ServiceNet at this moment (too much to deploy at this stage).
Pls, advise with yout experience or best practice knowledge.
Will your partners be accessing the WDSL and accompanying documentation only at design time or will they be attempting to using dynamic binding to lookup the endpoint and invoke the service?
You mentioned that you did not want to deploy Glue or Fabric (now renamed to ServiceNet). Glue 5.0.2 contained a UDDI server, while in Glue 6.x this has been moved to ServiceNet. There are other UDDI server options including some provided by app server vendors (like IBM Websphere) and Microsoft Windows Server 2003. Both are fairly easy to setup, but only offer the crudest of user interfaces and an arcane and cumbersome API.
So, you don’t want to purchase or deploy anything new, but you do want to make your docs accessible to consumers. Your options appear to be:
Build a simple user interface using IS and either static HTML, JSP or DSP pages that provides a menu allow you to find docs and wsdl’s for exposed services
Do the same, but use publish using an non-IS web server and the tool of your choice. Provide background on your company and services and treat the site as marketing and P/R for your fine work
On a side note, if you plan to continue adding more and more services I’d recommend that you move your web service operation input/output definitions from the WSDL into a separate XML Schema file. I’ve found it extremely useful to keep the two entities separate.
You can publish/host your WSDL’s and documentation using only Apache (free!) software, though your experience will probably depend on how comfortable you are working with open-source software.
I actually find open-source software much easier to use than most commercial packages, and that includes webMethods. We’ve actually used some open-source packages in place of some of the built-in webMethods modules/services because the webMethods components were not as flexible as we would have liked. Open-source software vendors just seem to expose more functionality and flexibility in their products.
There is simple way to expose webservices, put your wsdl files under installationDir/IntegrationServer/packages/package name/pub directory with .access file so anyone can access without authonication…