Service-Oriented Software
Michael Godwin Ben Miller
Neil Wilson Lingiie Ye
Introduction
• Background of Service-Oriented Software
• Service-Oriented Architecture (SOA)
• Where SOA is used
• How you can create your own service
What is SOA? • The future!! (arguably)
• Mash-up of multiple services in one site
• Services are autonomous
• Usually used in web-based software
• Designed to meet users ever-changing needs
Advantages • Simplifies understanding the software
• Allows for simplified modifications • Adding/removing services is easy • Debugging services is easy
• Centralized data
• Versatility
• High fault tolerance
Disadvantages
• Not suited for applications that require a lot of data transfer
• Requires complex management infrastructure
• Difficult to initially learn to create • Consumes a lot of CPU time
SOA • A Service Oriented Architecture aims create and use
small pieces of software to accomplish a greater goal
• Services are the small pieces of software used as building blocks
• A client is any piece of software that is written to use a service for some functionality
• A registry is a server that hosts information about web services so that clients can find web services
SOA
Services • Individual software systems that can be
queried by other software
• Implementation has two parts:
• The logic of the services
• The service messaging system
• Important to consider how a service will message a client
Service Design Principles
• Services should be a small unit of software with a distinct goal or purpose
• Allows for easier reuse
• If you want your service to accomplish some significant task, consider writing more than one service
• Decouple the Messaging and the logic as much as possible
• If you change your service, you don’t want to break all of the clients that are designed to access your service
• Implantation Details and Hosting Platform aren't important
Communication • Communication is huge in SOA
• We have all of these services, how do they talk to clients?
• Two different things need to be established:
• How can we expose a services interface to clients in a convenient manner?
• What is the format of messages sent to and from services?
Web Services Description Language (WSDL)
• XML Language to describe a service’s interface
• Standard document format, maintained by W3C
• Client reads the WSDL file, and discovers:
• What kind of requests can be sent to the service, and what the parameters and return type will be
• Think function prototypes
• What kind of messaging protocol must be used to send these requests
WSDL
SOAP Protocol • An XML message protocol
• Created by Microsoft in 1998
• Standardize the messages sent between Client and Service
• Can be used over any transfer protocol (HTTP, SMTP, TCP)
SOAP Protocol POST /InStock HTTP/1.1���
Host: www.example.org���Content-Type: application/soap+xml; charset=utf-8���Content-Length: nnn������< ?xml version="1.0"?>���< soap:Envelope���xmlns:soap="http://www.w3.org/2001/12/soap-envelope"���soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">������ <soap:Body xmlns:m="http://www.example.org/stock">��� <m:GetStockPrice>��� <m:StockName>IBM</m:StockName>��� </m:GetStockPrice>��� </soap:Body>������< /soap:Envelope>
RESTful Web Services • A design philosophy for creating web services
• New Idea
• RESTful web services have only been around since mid 2000’s
• REST =
• REpresentational
• State
• Transfer
• REST was defined by Roy Fielding, Creator of HTTP, in 2000.
RESTful Web Services • Key RESTful Concepts:
• Separate the concerns of the client and the service
• System should be stateless. No client information needs to be stored by the service
• Must implement a uniform interface between client and server, usually uses HTTP’s methods (GET, POST, PUT, DELETE)
RESTful Web Services • How does this actually work?
• The service has some resources or data that it would like to expose to client systems
• The web server is set up to give URIs to each of these resources or data
• Eg: http://www.myservice.org/discussion/topics/1
• A client may now retrieve that piece of information from the service by sending an HTTP GET request to that URI
• The service sends back a very simple XML or JSON file containing only the information asked for
SOAP vs. RESTful Web Services
• Current debate in development community
• If im making a web service, should I use SOAP, or make it a RESTful web service?
SOAP vs. RESTful Web Services
• RESTful Advantages:
• Lightweight: No need for extensive XML Markup. Messages are much smaller.
• Can return anything as a response message, so things like JSON can be used
• No extensive toolkits are required to create
SOAP vs. RESTful Web Services • SOAP Advantages:
• Language, Platform and Transport independent
• Built in error handling
• Strong typing guarantees type security
• Built to handle distributed computing enviroments
• Robust tool support
• Various security extensions have been developed for SOAP
SOAP vs. RESTful Bottom Line • RESTful Web Services are easy to get off the ground
and provide most of the functionality of SOAP
• If you can use RESTful, you probably should
• SOAP still has uses
• Non web based SOA systems
• Distributed computing enviroments
• Some critical security extensions
External Facing Services
• Integration • Available through public API
Google Translate API
GET https://www.googleapis.com/language/translate/v2?key=&source=en&target=de&q=Hello%20world
200 OK { "data": { "translations": [ { "translatedText": "Hallo Welt" } ] } }
The Cloud • Storage
• Computing (SaaS)
• Servers
Case Study: eBay 2 500 000 000 Hits on a busy
day
2 000 000 000 000 000 bytes of data
6 000 000 lines of code
100 000 new lines of code every two weeks
30 000 software builds per week
Internal Facing Services
Case Study: eBay • Helped to solve the complexity
issues • Helped to solve many other
technical problems such as interoperation between C++ and Java
• Greatest benefit was in management
Case Study: eBay • Business Agility
o Produced new features faster
o Quicker response to change o Easier integration with partners
• Innovation o Enabled internal and external innovation
• Operational Excellence o Reduced cost for new features o Efficient resource utilization o Reduced cost of failure
Benefits
Case Study: eBay Challenges
• Learning Curve • Governance • Migration • Deployment • Metrics • Integration Testing
Tech Talk • Service is big on sharing, and sharing requires
adherence to standards.
• SOA grants freedom to choose language.
• All major languages have SOA libraries. • Java SOAP: JAX-WS, JAX-PRC, Axis • Java REST: RESTlet, Jersey • C# SOAP: Web Reference, Service References • C# REST: OpenRasta • Python SOAP: SUDS, soaplib, pysimplesoap • Python REST: built-in web libraries suffice (guide)
29
Tech Talk
Die-hard Fundamentalist
DIY Vimer?
30
Tech Talk • Many IDE have SOA development tools & plugins
• Technologies change often, search for the latest
• To get a quick start, finding a toolkit that has up-to-date documentation is important.
• For this quick demo, I decided to use • Java • SOAP • Oracle JDeveloper with JAX-WS
31
Registry • There are very few open registry for free-lance
developers to publish their services.
• Large-corporations often host their own closed service registries.
• Maybe open to the public to consume
• But do not allow public publishing service
• JDeveloper integrated WebLogic Server to host & test services locally.
32
ESB • ESB - Enterprise service bus
• The prime duties of an ESB are:
• Monitor and control routing of message exchange between services
• Resolve contention between communicating service components
• Control deployment and versioning of services
• Popular ESB: webMethods, Mule
33
Publishing • Since input parameters and return value will
be serialized into XML, their type must be • Primitive types: int, float, double
• Primitive type Wrappers: Integer, Double
• Strings
• A Java bean with a zero-argument constructor, with a pair of "get" and "set" methods for each property to be exposed.
• Array of those types
34
Publishing • Bottom-up
• Work with existing software, turn into services
• Some say it’s better for updating legacy systems
• Top-down • Design and create interfaces first, then implement
• Some say it promotes more reuse, but may require organization-wide change.
• On-going debate
35
Bottom-up Code before
36
Bottom-up Code after
37
Testing with HTTP analyzer
38
Bottom-up
Testing with HTTP analyzer
39
Testing with HTTP analyzer
40
Testing with HTTP analyzer
41
Flow of Data
Top-down From WSDL, use wizard to generate code stub
42
Top-down From WSDL, use wizard to generate code stub
43
Top-down Implement method
44
Consuming • Discovering and binding of services
• Technologies: UDDI, ebXML, WSIL
• Facilitate discovery
• Automated, and dynamic by using simple API
• Example: JAXR - Java API for XML Registries
• Tools generate local wrapper method/functions for the service
45
Consuming Wizard to generate local wrapper methods
46
Consuming Specify WSDL location – step may be automated
47
Generated code
Consuming
48
Consuming Using service by calling wrapper method
49
Key Points to Remember • Comm. Standards are important. (SOAP, REST)
• Lots of technologies to choose from. There will be libraries to help you do SOA.
• Provider vs. Registry vs. Consumer
• Only use parameters that can be serialized to XML when creating services
• Top-down vs. Bottom-up approach • Service discovery & binding. Local wrapper.
50