A Service-oriented architecture (SOA) is software built using loosely coupled software services to support the requirements of business processes and software users. Network resources in a SOA environment are made available as independent services that can be accessed irrespective of the underlying platform implementation.
More importantly, SOA architecture enables the creation of applications that are built by combining loosely coupled and interoperable services. These services inter-operate based on a formal definition (or contract, e.g., WSDL) that is independent of the underlying platform and programming language, and the interface definition hides the implementation of the language- specific service. SOA-based systems can therefore be independent of development technologies and platforms (such as Java, .NET etc), and can be made to interact between platforms.
SOA can support integration and consolidation of activities within complex enterprise systems, but does not specify or provide a methodology or framework for documenting capabilities or services.
Service Desk’s Web Services Interface enables third party applications to interact directly with the Service Desk application in a secure and controlled fashion. The interface is based on the SOAP standard for Web Services. For more information about SOAP Web Services, please see W3C.
SOAP Messages are essentially well formed XML blocks sent using http.
All examples herein are given in Java using the Apache Axis web services library. You can also do your own parsing using XML but that is out of scope for this document. Names throughout this document are exclusive of any suffixes that will be added to names by Web Services Frameworks. The framework will append the word ‘Request’ to any message sent to the Service Desk Web Services Interface. Similarly, the word ‘Response’ will be appended to any message name returned to the Customer.
The easiest way to use Web Services is through an API that will wrap the XML parsing and calling for you. Most major Web Services from Google, Amazon and eBay operate this way. Several APIs exist for SOAP but the most prevalent is Axis from the Apache Group. If you are not familiar with the Axis API, please see the Axis User’s Guide. The Axis API Reference is also a useful guide if you are interested.
Versions of Axis are available for both Java and C++. Web Services in the Service Desk application conform to the SOAP specification, so there is no reason why you could not use the XML directly from the server and parse it directly. This will require the description document that explains the object types returned and provides other useful information. Use of the Web Services API via direct XML parsing is outside the scope of this document.
While Axis is not required – the examples use Axis as it is one of the most common web services API’s in use. Successful customer implementations have also been achieved using the XFire and CXF API’s, .NET and Perl.
Session management is equally as important when using web services as it is when using Service Desk via the user interface. It is up to the user (or the client API) to maintain the http headers returned from the authentication message so that state information is retained.