Webservices : Implementing webservices at UCL

17
Webservices: Implementing webservices at UCL

description

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?. - PowerPoint PPT Presentation

Transcript of Webservices : Implementing webservices at UCL

Page 1: Webservices : Implementing webservices at UCL

Webservices:Implementing webservices at UCL

Page 2: Webservices : Implementing webservices at UCL

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

Agenda

Page 3: Webservices : Implementing webservices at UCL

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

Page 4: Webservices : Implementing webservices at UCL

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.

Page 5: Webservices : Implementing webservices at UCL

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.

Page 6: Webservices : Implementing webservices at UCL

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>

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

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.

The same document type is used in the response. This is not mandatory but should be the default.

Page 7: Webservices : Implementing webservices at UCL

Web services stack

Page 8: Webservices : Implementing webservices at UCL

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

Standard

Page 9: Webservices : Implementing webservices at UCL

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)

Design and Approval for WS

Page 10: Webservices : Implementing webservices at UCL

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

UCL Standards for Webservices

Page 11: Webservices : Implementing webservices at UCL

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.

Continued..

Page 12: Webservices : Implementing webservices at UCL

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.

Deploying webservices

Page 13: Webservices : Implementing webservices at UCL

• 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

Versioning

Page 14: Webservices : Implementing webservices at UCL

Webservice Security

Transport Level Security Message 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.

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

Page 15: Webservices : Implementing webservices at UCL

Flow of communication

Client truststore

Server.cert

Server truststore

Client.cert

Client Server

Client.cert Server.cert

1. Request protected resource

2. Present certificate

3. Verifies certificate

4. Present certificate

6. Continue communication

5. Verifies certificate

Page 16: Webservices : Implementing webservices at UCL

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.

Page 17: Webservices : Implementing webservices at UCL

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.