170 likes | 341 Views
CSE 762 “Advanced Operating Systems Laboratory’’. Today’s Agenda. CSE 762 / Background / Format Motivation and history of web services Project description. Background. Operating systems sequence CSE 660 – Basics of operating systems
E N D
Today’s Agenda • CSE 762 / Background / Format • Motivation and history of web services • Project description
Background • Operating systems sequence • CSE 660 – Basics of operating systems • CSE 662 - Implementation of basic uniprocessor OS modules • CSE 760 - Concurrency / Distributed algorithms • CSE 762 - ``advanced operating system laboratory - capstone class
762 • Old Format • Focus on operating system shell implementation and sockets programming • Well defined labs • Capstone requirements • Open-ended design projects • Technology Trends • Middleware replacing ``distributed operating systems’’
New Format • Web-services as the implementation vehicle • Open-ended design projects • Team work • More independent work • Define projects • Learn details of underlying technologies
Web-Services Background: The Next Internet Generation • HTML and browsers were app to human communication • Universal human to application access • SOAP and XML-based web services are for program to program communication • Separated by program, machine, operating system and organizational boundaries • Universal application to application access
What is a Web Service? • Application capability, function or operation exposed to other programs via open, interoperable standards • Service defined as XML document • “transports” over http or other open Internet protocol • Can be accessed from any programming language, hardware platform or operating system
What is a “Good Web Service”? • “self describing” • XML Schema or DTD for grammar of payload • human readable instances • discoverable • UDDI, WS-Inspection, or some other method of advertising availability • Realize promise of many to many integrations that are enabled by a web service (one to one ad hoc integrations can be done with earlier technology) • “coarse grained” • Large documents representing entire business events or business objects • e.g. CRUD operations: CreateOrder, ReadOrder, UpdateOrder, DeleteOrder • NOT operations such as SetPrice(), SetProduct(), SetCustomer(), CompleteOrder() • asynchronous • When appropriate (often for large scale work)
eXtensible Markup Language • Specification of asyntax for “encoding” data, with strict syntax rules about how to do so. • A text-based syntax -- written using printable characters (no explicit binary data) • Extensible -- you can define your own tags (essentially data types), within the constraints of the syntax rules • Universal -- the syntax rules ensure that all XML processing software MUST identically handle a given piece of XML. Almost an ideal data exchange format
attributeof this quantityelement element tags XML Example <order> xmlns=“http://w3c.org/Spec/” > <item> <code>“30100026266” </code> <desc>Viewsonic E90f Monitor, 0.21mm, DELL Outlet </desc> <price> 229.99 </price> <quantityunits=“gross”>2</quantity> <deliveryDate date=“20APr2004-12:00h” /> </item> <item> <code> “2001234” </code> . . . . . . </item> </order>
SOAP • Simple Object Access Protocol • SOAP is a simple XML based protocol to let applications exchange information over HTTP. • Or more simply: SOAP is a protocol for accessing a Web Service.
Basic SOAP Message Exchange WSDL describing service Exposing Program Service Provider Consuming Program Service Requestor SOAP message http transport SOAP message http transport discover services Service Registry UDDI WSDLs describing services
Distributed Systems and RPC • How applications once communicated with each other across machine and OS boundaries? • remote procedure calls • Java RMI • Corba • DCOM
So What’s Different? • Open format usable from any platform • Easy to understand and debug • Stable support interfaces • Standards enable “expose service once” and have multiple consumers • versus typical point to point integration efforts • Easy for intermediaries to process messages and add value • Routing and delivery • security • management and monitoring • schema and service design • acceleration • Easy to extend with additional transport semantics
Course Project • Goal • Build a web service and a consuming client application • Requirements • Motivated by a real need and has realistic constraints • All communication between processes should be through web-services • Implement a significant distributed algorithm (e.g. distributed mutual exclusion, voting, serializability of transactions) • Team size • Three students
References • Specs • SOAP Specification, http://www.w3.org/TR/soap/ • WSDL Specification, http://www.w3.org/TR/wsdl • UDDI Specification, http://www.uddi.org/specification.html • Tools • Visual Studio, http://microsoft.com/vstudio • Microsoft Web Services Enhancements, http://msdn.microsoft.com/webservices/building/wse/default.aspx • Apache Axis, http://ws.apache.org/axis