1 / 17

Webservices : Implementing webservices at UCL

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?.

len-griffin
Download Presentation

Webservices : Implementing webservices at UCL

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Webservices: Implementing webservices at UCL

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

  3. What are webservices? • A web service (also webservice) is defined by the W3C 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 webservicecan beconsidered 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

  4. 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.

  5. 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.

  6. SOAP request/response <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" …> <soapenv:Body> <req:generateUPIRequest xmlns:req="http://ucl.ac.uk/UPIService/"> <req:person> <req:UPI/> <req:lastname>Smith</req:lastname> … </req:person> </req:generateUPIRequest> </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:generateUPIResponse xmlns:req="http://ucl.ac.uk/UPIService/"> <req:person> <req:UPI>JSMIT98</req:UPI/> <req:lastname>Smith</req:lastname> … </req:person> </ req:generateUPIResponse > </soapenv:Body> </soapenv:Envelope> The same document type is used in the response. This is not mandatory but should be the default.

  7. Web services stack

  8. 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.

  9. 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)

  10. 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/AllChange. • 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

  11. Continued.. • Web service inventory of WSDL and schemas will be held on the SharePoint/ Wiki. • http://wiki.ucl.ac.uk/display/InfoSysISDTechStds/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.

  12. Deploying webservices Tomcat • Webservices that are developed using Spring/Axis2 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 • [21st 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.

  13. 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 documentImplementing webservices at UCL.doc

  14. Webservice Security

  15. Flow of communication

  16. 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.

  17. 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.

More Related