Webservices Implementing webservices at UCL Agenda What are

Webservices: Implementing webservices at UCL

Agenda • • What are webservices? Concepts – XSD, WSDL, SOAP, REST Design and approval process for webservices at UCL Application servers Versioning Security Additional Considerations

What are webservices? • A web service (also webservice) is defined by the W 3 C as "a software system designed to support interoperable machine to machine interaction over a network. It has an interface described in a machine-process able format (specifically Web Services Description Language WSDL). Other systems interact with the web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other web-related standards[1]” • A webservice can be considered to be an application component, which is self contained and is self describing. Webservices can be used by any application irrespective of its implementation platform. • The basic webservice platform is XML over HTTP. Thus webservices use XML to code/decode data and SOAP as a medium of transport. To summarise a webservice is something that is expected to be consumed by an autonomous application as opposed to a browser or any other user interface. [1] http: //en. wikipedia. org/wiki/Web_service

Concepts – XSD , WSDL • XSD : XML Schema Definition. A schema defines a structure, and the actual document or data that is represented through the schema is called a “Document Instance”. XSD provides the syntax and defines a way in which elements and attributes can be represented in a XML document. It also advocates that the given XML document should be of a specific format and specific data type. • WSDL : WSDL stands for Web Service Description Language. This is the contract between the client requesting a service and the provider that provides it with the necessary information. It is because of this WSDL, and there is no dependency between the client and the service provider as both are expected to only adhere to the WSDL contract.

Concepts – SOAP, REST • SOAP: SOAP stands for Simple Object Access Protocol. This is a commonly used protocol for communication between a webservice consumer and provider. SOAP defines the format for sending and receiving messages over the Internet. SOAP being based on XML is completely independent of language and platform. • REST : REST stands for Representational State Transfer. REST is not a standard, but simply an architectural style. REST simply means that each unique URL is a representation of some object. You can get the contents of that object using an HTTP GET. REST is not a standard, but it uses standards like HTTP, XML, and URIs.

SOAP request/response <soapenv: Envelope xmlns: soapenv="http: //schemas. xmlsoap. org/soap/envelope/" …> <soapenv: Body> <req: generate. UPIRequest xmlns: req="http: //ucl. ac. uk/UPIService/"> <req: person> <req: UPI/> <req: lastname>Smith</req: lastname> … </req: person> </req: generate. UPIRequest> </soapenv: Body> </soapenv: Envelope> This person definition is imported from an XML Schema definition, referenced in the WSDL that defines the service. This web service is document-centric, which means the schema can be extended without impacting existing services. <soapenv: Envelope xmlns: soapenv="http: //schemas. xmlsoap. org/soap/envelope/" xmlns: wsa="http: //schemas. xmlsoap. org/ws/2004/08/addressing” …> <soapenv: Header> … </soapenv: Header> <soapenv: Body> <req: generate. UPIResponse xmlns: req="http: //ucl. ac. uk/UPIService/"> <req: person> <req: UPI>JSMIT 98</req: UPI/> <req: lastname>Smith</req: lastname> … The same document type is used in the response. </req: person> This is not mandatory but should be the default. </ req: generate. UPIResponse > </soapenv: Body> </soapenv: Envelope>

Web services stack

Standard • At present at UCL, we are developing SOAP based services for service enabling COTS and bespoke systems. • REST will be considered where the service is intended to used primarily by read only webpages.

Design and Approval for WS Business case for a webservice – Re-usable business logic. – Integrating applications at the server side, without the need of any UI. Integration could be for exposing services or data. – When building a web application that reads and writes from a database, implement web services between the controller and the database UNLESS all the following apply: » You are updating very few tables and there is no database-side validation or other business logic required. » There is only one client that is interested in that information. And it doesn’t seem likely anyone else would want similar data. » Consider timelines for delivery of the project. If the work to develop a webservice is considerably higher than alternate means. – When integrating System A with System B (no UI, mostly no controller) UNLESS » There is a reason the integration should not be near-real-time (e. g. end of day General Ledger upload, ETL for data warehousing)

UCL Standards for Webservices Following are the standards that must be followed when developing webservices. Ø All Web Services should be document-centric, not remote procedure calls (RPCs). Ø Web Services should reference schemas, not define complex types of their own Ø Schemas should be version controlled in SVN/All. Change. Ø Schemas and WSDL’s must include proper versioning. Ø Schemas should be approved centrally before development starts. Approvers: - Conrad Morgan, Management Systems - Simon Farrell, Information Services Division

Continued. . Ø Web service inventory of WSDL and schemas will be held on the Share. Point/ Wiki. http: //wiki. ucl. ac. uk/display/Info. Sys. ISDTech. Stds/Web+Services ØWeb Service security must be considered, when the webservice publishes any sensitive information. ØWhen developing web services, we will be using mutual authentication over SSL whereby the service end-point will also require a security credential from the client that is trying to access the web service. This credential will be a verified certificate.

Deploying webservices Tomcat – Webservices that are developed using Spring/Axis 2 framework can be deployed in Tomcat. – Eclipse provides some integration with the frameworks using plug-ins that help in webservice development and deployment. Oracle Application Server – [21 st May 2010] No new webservices being developed should be deployed on Oracle Application server. – Webservice development is fully integrated with toolset in the form of JDeveloper as the IDE. – Helps in exposing PL/SQL packages as webservices. – Java stubs and WSDL is auto-generated using the webservice wizard.

Versioning • All schemas and WSDL must include versioning. • XML schemas will use major only versioning scheme. • WSDL files name will include major version number. – Any significant structural change to the schema will mandate a major version change. • Thus being reflected in a major version change to the WSDL. – Any elements added as optional will not need a version change to the XML schema or the WSDL. • In addition to this, details on how and where to add version related information is included in the document Implementing webservices at UCL. doc

Webservice Security Transport Level Security - SSL connection is established between each pair of communicating end-points. - The message is passed over this secure connection. - Faster as compared to Message Level Security. Issue: Using Transport Level security, one cannot ensure that the request will remain secure as it’s transferred from one consumer, intermediary services to the next. Message Level Security - The XML message itself is digitally encrypted. - The security credentials are passed in the SOAP header. - Usually used in addition to TLS/SSL. Issue: CPU intensive, complex to deploy.

Flow of communication

Standard At present in UCL, when developing webservices, we will be using mutual authentication over SSL whereby the service end-point will also require a security credential from the client that is trying to access the webservice.

Additional Considerations • Load testing of webservices. - Webservices are developed with an intention that it will be used by several clients. Thus load testing the services with X number of request calls should be a planned activity. E. g. : SOAP UI is a tool available that could be used for load testing the WS. This tool also integrates with development platforms like Eclipse. • System integration using webservices. -Consider developing webservices when developing any interaction across independent systems. If there is work being planned to pull/push any information across two independent systems, one should give the following points a thought first. - Is developing this interaction as a webservice justified in terms of how many clients will be interested in this information. - If it is a candidate to replace any point to point interfaces. - A good start would be to speak to the webservice development and support team which includes Simon Farrell, Conrad Morgan and J. Anthony Rickaby. -This team will help steering this new requirement through its design, implementation and deployment stages. - A sign off would be needed for every stage from the Webservices Development team.