Distributed Computing

● Services - any software function that carries out a business task or process (placing an
order, shipping an order, whatever). Any useful functionality exposed by a system.
○ Services can be used to share functions across different application
○ Services can be clients or servers
○ Usually found on another machine
● Distributed Object Technologies
○ Before RESTful services, services were language dependent and proprietary.
○ Based on Proxy/Stub technology. A lot harder to use
○ Client has a proxy, goes across the network to the stub, and gets customer
objects. For a distributed object.
○ Moral of the story - convoluted, confusing, and sucks.
○ Usually implemented on TCP ports that were not standardized across vendor
implementation. Sucks. Nothing universally standardized.
○ Closed Distributed Computing Representation
■ A closed graph. Only works with one vendor’s system - you cannot
expose it to anyone else but people using your vendor’s system.
● Service Oriented Architecture (SOA)
○ Definition - Style of design that guides all asploosects of creating and using
business services throughout their lifecycle.
○ SOA - paradigm for organizing and utilizing distributed capabilities under control
of different ownership domains.
○ The idea of how to expose services to people outside of one vendor.
○ Underlying structure supporting communication between services.
○ Defines how two computing entities such as programs interact so one does work
for another.
○ Service Provider → Service Broker → Service Consumer
■ Provider publishes services to broker.
■ Consumer requests broker for services.
■ Through broker, interaction.
○ Design paradigm - business functions are defined as services and logically
managed.
○ Many ways of implementing it - including REST, SOAP/WSDL. With Java
RMI, .Net Remoting.
○ Protocol independence - consumers can communicate with the service in
different ways.
○ There can be different brokers for the same services - you can use a different
broker to get the same service, because the request might be implemented
differently - works across REST and SOAP, for example.
● Web Services
○ refer to software functions that can be invoked by leveraging HTTP as a simple
transport protocol over which data is carried, or by using HTTP as a complete
application protocol that defines the semantics for service behavior.
 ■ Can be done with HTTP as a simple transport protocol - data is just
carried this way - or can be done as complete application protocol -
RESTful services rely completely HTTP.
○ Terms
■ Consumer - Service Requestor.
■ Server - provider who responds to request
● Why Web Services
○ Conceived to address shortcomings of distributed object technologies.
○ Provide means to integrate disparate systems and expose reusable business
functions over HTTP.
○ Broad reach is possible because they rely on open and interoperable standards
independent of the underlying technology.
■ Language independent - nonproprietary
○ Use HTTP and leverage data interchange standards like XML and JSON and
common media types.
■ Open standards payload
■ Standard serialization/deserialization
○ Due to their inherent interoperability and simplicity, web services facilitate the
creation of complex business processes through service composition (creating
compound services by assembling simpler services into workflow)
○ Make it easy to resuse and share services across mobile, desktop, and web
apps.
● Frameworks and Standards for Web Services Programming
○ Client Apps
○ Service layer
○ Domain Layer - Domain Models, Table Modules, Workflows, Code Libraries,
Commercial Packages, Legacy Apps
○ Data Sources - Databases, Files, Multimedia, Middleware
■ Above are layers.
● Basic Web Services Standards
○ JSON, XML, XML Schema Definition Language (XSD), Web Services
Description Language (WSDL), XPath, XSLT
● JavaScript Object Notation
○ Lightweight data-interchange format. Easy all around.
○ Text format that is completely language independent.
● Extensible Markup Language XML
○ Defines rules for encoding documents in a format that is both human and
machine readable.
○ Use it for lots of stuff - but you can also use it to send data. Can also be used for
configuration and layout.
○ More like HTML with tags
● TCP/IP Protocol
○ Application
○ Transport
 ○ Internet
○ Network Interface
■ Above are layers
○ TCP - Transmission Control Protocol
■ Breaks data into IP packets before they are sent, and assemble them
when they arrive.
■ Post office
○ IP - Internet Protocol
■ Takes care of comm with other computers.
■ Responsible for sending and receiving data packets over the internet.
■ Post person
● HTTP Protocol
○ Hypertext Transfer Protocol
■ HTTP takes care of the comm between a web server and browser.
■ Used for sending requests to a web client - returns web content.
○ HTTP has a very rich vocab in terms of
■ Verbs
■ URIs
■ Request and Response Headers
■ Internet Media Types
■ HTTP Request and Response codes, etc.
● HTTP Server Methods
○ POST
○ GET
○ PUT
○ DELETE
● Typical HTTP URI
○ http://bookstorecom/shop/book?title=XYZ&pubYear=2013
○ Protocol identifies the transport scheme that will be used to process and respond
to the request (http)
○ (bookstore.com) Identifies the server of the address resource
○ (shop/book?) Path in server directory
○ (title=XYZ&pubYear=2013) The actual request at the path
○ URI is always unique, or the server would have overriding requests - a mess.
● Web Services Frameworks
○ SOAP/WSDL/POX Frameworks
■ Java API for XML web services (JAX-WS)
■ Apache (CXF)
■ Microsoft’s Windows Communication Foundation (WCF)
○ REST Frameworks
■ Java API for RESTful Web Services (JAX-RS)
■ Microsoft’s WCF
● Web Service API Styles
 ○ API - a set of functions that one program makes available to other programs so it
can talk to it directly.
■ OS API’s
■ App API’s
■ website…
○ Three Types of API’s
■ RPC (Remote Procedure Call)
■ Message API
■ Resource API
○ RPC - Defines messages that identify the remote procedures to execute and also
include a fixed set of elements that map directly into the parameters of remote
procedures - remote function invocation
○ Message API Style
■ How clients send commands, notifications, or other information to remote
systems over HTTP while avoiding direct coupling to remote procedures?
● Define messages that are not derived from teh signatures of
remote procedures.
● May carry information on specific topics, tasks to execute, and
events.
● Have the client send the message to designated URI - executes
correct procedure based on message
○ Resource API Style
■ Uses standardized Server Methods
■ How can client manipulate data managed by a remote system, avoid
direct coupling to remote procedures, and minimise the need for domain-
specific API?
● Assign all procedures, instances of domain data, and files a URI.
● Leverage HTTP as a complete application protocol to define
standard service behaviors.
● Exchange information by taking advantage of the standard sized
media types and status codes when possible
○ REST is simpler and scales easily. Creates permeability, promotes co-creation.
Easy, everyone uses it.
○ Take decision choosing API style seriously - hard to switch.

Web Services Design Principles

● 12 Factor App
○ Used by Heroku that outlines the best practices to design and develop web-
based applications
○ Good to do. Makes it easy to migrate to cloud.
○ 12 FACTORS (http://12factor.net | http://www.clearlytech.com/2014/01/04/12-factor-apps-plain-english/)
■ Codebase
■ Dependencies
■ Config
■ Backing Services
■ Build, Release, Run
■ Processes
■ Port Binding
■ Concurrency
■ Disposability
■ Dev/Prod Parity
■ Logs
■ Admin Processes
○ Codebase - ‘One code base tracked in revision control, many deploys’
■ Common code shared between multiple apps should be externalized in
jars
■ Can be deployed in multiple environments and local dev machines
■ One codebase in a VCS.
○ Dependencies - “Explicitly declare and isolate dependencies”
■ Explicitly declare and isolate dependencies
■ Never rely on the implicit presence of system-wide packages, tools, and
libs
■ Use management tools like Chef
○ Config - ‘Store config in the environment’
■ Config data should be stored in a different repo location from the code
and read by the code at runtime.
■ Config should be copied to the enviro at time of code deployment
■ Store configs in environmental variables
○ Backing Services - ‘Treat backing services as attached resources’
■ Treat backing services as attached resources
■ Attaching and detaching resources requires no code changes
■ Treat URLs as environmental variables stored in configs
■ Make no distinction between local and third party services (no distinction
between a service run locally or on the cloud).
○ Build, Release, Run - “Strictly separate build and run stages’
■ Build - Transforms codebase into executable
■ Release - Combines a build with configuration to create a release
■ Run: runs the released app in an execution environment
○ Processes - ‘Execute the apps as one or more stateless processes’
■ Do not carry over state between transitions
■ Session state or persisted data must be stored in an attached services
such as a cache
 ■ Store intermediate data, so if one service goes down, possibly another
instance can pick it up and continue.
■ Enables concurrency, scales horizontally, fault tolerant.
○ Port Binding - ‘Export services via port binding’
■ The idea is that, just like all the backing services you are consuming, your
app also interfaces to the world using a simple url.
■ Processes communicate by binding to a port and listening to request.
■ Usually you get this for free because your app is already presenting itself
through a web-server.
■ One app can become the backing service for another app, by providing
the URl to the backing app as a resources handle in the config for the
consuming app.
○ Concurrency - “scale out via the process model’
■ You’ll be able to do more stuff concurrently, by smoothly adding additional
servers, or additionally CPU/RAM and taking full advantage of it through
the use of more of these small, independent processes.
■ Scale horizontally by spawning more app processes.
○ Disposability - ‘Maximize robustness with fast startup and graceful shutdown’
■ Processes can be started or stopped at any time.
■ Rapid startup.
■ Fault-tolerant and rapid-release
■ No mandatory ‘cleanup task’ when the apps shut down
○ Dev/Prod Parity - ‘Keep dev, staging, and production as similar as possible’
■ Continuous deployment - small gap between development and production
■ Backing services parity dev/prod environment
■ Use tools such as Vagrant for dev to manage developer’s local virtual
server - local config rewrites
○ Logs - ‘Treat logs as event streams’
■ Apps should never manage the routing and storing of its output stream.
■ Processes should write all logs to stdout as a stream.
■ Execution environment captures and routes the log stream
○ Admin Processes - ‘Run admin/management tasks as one-off processes’
■ You’ll want to do lots of one-off administrative tasks once you have a live
app.
■ Having console access to a production system is a critical administrative
and debugging tool, and every major language/framework provides it.
■ They run against a release, using the same codebase and config as any
process run against that release.
■ Admin code must ship with app code to avoid sync issues.
○ Conclusion
■ Use declarative formats for setup automation, to minimize time and cost
for new devs joining project.
■ Have a clean contract with the underlying operating system, offering max
portability between execution env.
 ■ Are suitable for deployment on modern cloud platforms
■ Minimize divergence between development and production, enabling
continuous deployment for max agility.
■ And can scale up without significant changes to tooling, architecture, or
development practices
○ Principles of Web Service/API Design
■ Encapsulation
● Services hide their implementation detail
● Client should not know and not make any assumptions.
● When domain layer change, client should not be impacted.
● Service can be swapped as long as the API remains the same
■ Service Contract
● An agreement that specifies how clients and services interact.
● Contract
○ Pre-conditions: what must be true befroe service can be
called
○ Post-condtions: what must be true after service is
completed
○ QoS: quality of services such as performance (latency),
security, privacy
■ Description of API
● Should be unambiguous, formal representations of:
○ A service’s functionality
○ A service’s non functional attributes
○ A user’s needs and preferences
■ Autonomy
● Consistent and reliable outcomes are more likely when the service
controls its own execution and has fewer dependencies.
● Reduce relying on distributed services so that the outcome will not
be partially determined.
■ Partial Failures
● Involves a remote service that involves networks
● Clients must be prepared for services to fail
● Both service and clients must be ready to handle when network
fails and saturated with traffic.
■ Completeness
● Loose coupling
● Implementation neutrality
● Flexible configurability
● Persistence
● Granularity
○ Principles of Web Service/API Designface - Words of Wisdom
■ Multiple variables to consider.
■ Going extreme on one may create problem on others.
 ■ Need to be looking all together and consider trade off
■ Not all come without consequences

Representational State Transfer (REST)

● Resource Web service/API (Resource API)
○ Why?
○ CRUD Services
■ Create, Read, Update, Delete
■ Many web services use message to form their own domain-specific APIs
■ Message incorporate common logical commands…
● Create, Read, Update, Delete
■ This can lead to a proliferation even in relatively small problem domains
○ Instead of creating our own methods for creating/deleting/posting things...we can
use…..
● Resource API
○ Assign all procedures, instances of domain data, and files a Uniform Resource
Identifier
■ Procedures, objects, and files have a URI
○ We leverage HTTP as a complete application protocol to define standard service
behaviors.
○ Exchange information by taking advantage of standardized media types and
status codes when possible.
● HTTP uses crud, but wraps it.
● Rather than creating domain specific API messages, we just use HTTP specified verbs.
○ Delete is DELETE
○ Update is PUT
○ Read is GET
○ Create is POST
● Resources
○ Resource API provides access to resources - data sources. ANYTHING.
● Request/Response Mechanism
○ Clients invoke services by sending requests to distinct URI to designated for
each resources
○ Resource APIs use HTTP as a complete application protocol which prescribes
standard service behaviors.
○ A client must therefore issue a GET to retrieve data, PUT to update a resource
etc…
○ Each request and response may carry a standardized or proprietary MediaType.
● URI, HTTP Methods and Media Type
○ The requested UR and HTTP server methods issued by the client along with the
submitted or requested media type are used by the server to determine the
client’s intent and service to be invoked.
 ○ Once the service has been invoked, it may process the client’s request and
return a response containing the requested media type or a standard status
code.
● URI
○ A uniform resource identifier is a string of characters used to identify a name or
resource.
○ Identification enables interaction with representations of the resource over
network using specific protocols (HTTP or FTP)
○ URIs can be classified as locators (URLs) as names (URNs) or both.
○ A URN functions like a person’s name, URL is that person’s street address. URN
defines the item’s identity, whiel the URL provides a method for finding it.
○ Schemes specifying a concrete syntax and associated protocols across URI
● Media Type
○ internet media type is a two part identifeer for file formats on the internet
○ There types were called MIME types (multipurpose internet mail extensions) and
are sometimes referred to as Content-Types
○ Without MIME types, email clients would not be able to handle attachments
correctly.
○ MIME types are not jsut used for email - adopted by web servers to define media
types, so they can handle them correctly.
○ Media type made up of a type, a subtype, and zero or more optional parameters.
■ image/gif for image files
■ text/html for HTML files
■ application/xml for application related XML
● Main Points
○ Resource APIs use:
■ HTTP as an application protocol to prescribe standard service behaviors
■ Media type consumed or produced by service
■ Service status code
■ URI or URI schemes/patterns to identify resource.
■ Analogous to CRUD, just uses HTTP
■ The use of GET, PUT, DELETE
■ POST
● behavior of post varies, can be used to replace behavior where
other beahviors are not fit.
● For instance, for a mutual fund - “Exchange funds”, “Sell X Share”
and “Sell Dollar Amount” through POST
● POST can be used for creating, updating, or deleting
● Representational State Transfer
○ REST
■ Defined by Fielding in PHD thesis (rest bible)
■ Primary designer of big protocols like HTTP and URIs
■ Architectural style comes with a set of constraints that define it - Fielding
defined constraints that make up REST.
○ What is REST?
■ REST is a high level architecture style that could be implemented using
many different technologies
■ Includes concepts of resources and uniform interfaces
● Uniform interface - the idea that every resources should respond
to the same methods
■ One example of RESTE style is HTTP and URs
■ HTTP instantiatees the REST uniform interface consisting of the HTTP
verbs
■ The internet is an example of REST style as a whole
○ Definition of REST
■ Rest is a set of architectural constraints for distributed hypermedia
systems
■ Constraints…
● Identification of resources
○ Everything is uniquely identifiable
● Manipulation of resources through representations
○ Separate a thing’s identity from its representation. For
instance, a thing may be represented as XML, HTML,
PDF, or an image.
● Self-descriptive messages
○ Communication is stateless - server doesn’t save anything
other than requests.
○ Use standard verbs to operate on your things.
● Hypermedia as the engine of application state
○ HATEOAS
○ Link things together by their identifiers. Enable the client to
move the application from one state to the next by
following a link.
■ REST Explained
● Clients and servers. Clients initiate request to server. Servers
process request and serve back appropriate responses.
● Resource can be any coherent and useful concept that can be
addressed.
● Request and responses are built around the transfer and
representations of resources.
● A representation ofa resource is typically a document that
captures the current or intended state of a resource.
■ REST Implementations
● REST was inititally descibred int he context of the HTTP, but is not
limited to that protocol.
● RESTful architectures can be based on other applcaiton layer
protocols if:
 ○ If they have a rich vocabulary of applications based on the
transfer of meaningful representational state.
■ REST and Web
● REST governs proper behavior of participants of the Web.
■ REST Verbs Description
● GET - retrieves a represetnation of aresource.
● A safe opreation.
○ No side effects.
○ It can be cached.
● GET requests have no entity body payload.
○ Should not contain a request body, as it will be discarded.
○ There is no extra data with a GET request; everything is
specified in the URL and the headers.
● POST appends to an existing resource or creates a new
resources
○ Submits data to be processed with the identified resoruce.
○ Unlike GET, has a body/payload.
○ Usually means “create newresource”, can also be used to
invoke arbitrary processing.
○ Query strings will be included in body of POST - GET is in
the command.
● PUT creates a resource, or updates it if it already exists on the
server.
○ Unlike a POST, client specifies the URI of the resource.
○ “Update this resource with this data, or create it if its not
there already”
● DELETE deletes a resource.
○ Inverse of a GET request - instead of retreiving a request,
it deletes it. Retrieve it, then throw it away.
○ Delete requests have no entity body payload.
● OPTIONS retreives allowed HTTP methods
○ Returns the HTTP methods that the server supports for
specified URL
○ Built in discovery
■ You can say “OPTIONS *” to see what HTTP
methods are allowable on the server.
● HEAD
○ Asks for the response identifcal that would correspond to a
GET request, but without the response body.
○ This is useful for reterving meta-information written in the
response header - without retreiving the whole
object/content.
● TRACE and CONNECT
 ○ TRACE echoes back the received request so the client can
see what intermediate servers are adding or changing in
the request.
○ CONNECT converts the request connection to a
transparent TCP/IP tunnel, usually to facilitate SSL-
encrypted communication (HTTPS) through an
unencrypted HTTP proxy
■ Status Codes
● Status codes are an indicators of the result of the server's attempt
to satisfy the request. Broadly divided in categories
○ 1XX: informational
○ 2XX: Success
○ 3XX: Redirection
○ 4XX: Client error
○ 5XX: Server error
● Success Status Code
○ *200 - all is OK
○ *201 - created
■ newly created resource location returned in the
location header.
○ 202 - Accepted
■ Server has accepted the request but isn’t complete
yet.
■ A location to determine the request’s current status
can be returned in the location header.
● Client Error Status Codes
○ 400 - Bad Request
■ Malformed Syntax. Don’t try again without
modifying what you’re looking for
○ *403 - Forbidden. server understood your request but is
not going to fulfill it. Authorization will not help and
requests should not be repeated.
○ *404 Not Found
■ Server cannot find a resource matching a URI
○ *409 Conflict
■ The resource is in a state that is in conflict with the
request
■ Client should attempt to rectify the conflict and
resubmit.
● Server Error Status Codes
○ *500 - Internal Server Error
■ The server encountered an unexpected condition
which prevented it from fulfilling the request.
○ 503 - Service unavailable.
 ■ HTTP Headers
● Headers from the core of an HTTP request, and are very
important in the response.
● They define various characteristics of the data that is requested or
the data that has been provided.
● The headers are separated from the request or response body by
a blank line [CRLF].
● Headers are included on both Request and Response content.
● Examples of headers:
○ Accept, Cookie, Host, Data, Agent, Referer, Ages, Allow,
…
REST Service Architecture
● Resource Oriented Service Architecture - REST
● HTTP/REST
○ Has rich vocabulary
● RPC Contrast to REST
○ SOAP/RPC over HTTP encourages each application designer to define a new
and abitrary vocabulary of nouns and verbs.
○ Disregards HTTP’s existing capabilities such as authentication, caching, content
type negotion, and may leave the app designer revingenting many of these
features within the new vocab.
● SOAP/WSDL vs REST/HTTP
○ Defined methods in SOAP/WSDL, vs HTTP verbs that link to certain addresses
in REST/HTTP

● Guiding Principles of REST Architecture

○ Identification of Resources
■ Everything is unique - we wouldn’t send entire databases, just individual
members of that database using HTML or JSON
○ Manipulation of Resources through the representations
■ When client holds a representation of a resource it has enough
information to modify or delete the resource on the server, provided it has
permission to do so.
○ Self-Descriptive Messages
■ Each message includes enoug info to describe how to process the
message
■ From type, client must know how to process its contents.
■ Shouldn’t have to read the message/payload to see what it means - you
should know based on HEADER
■ Server is Stateless
○ Hypermedia as the Engine of the Application State
 ■ If it is likely that the client will want to access related resource, should bt
indentifed in the representation returned.
■ Example - providing their URIs in sufficient context, such as hypertext
links.
■ At any particular time, a client can either be transitionsing between
application states or at reast.
■ A client in a rest state is able to interact with its user, but creates no load
and consumes no per-client storage on the set of servers or on the
network.
■ Client begins sending requests when it is ready to transition to a new
state.
■ While one or more requests are outstanding, the client is considered to be
transitioning states.
○ REST is an architectural Style
■ No client state for the sake of scalability
■ Uniform interface
■ Layered system
● Summary (Tilkov)
○ The promise is that oyu adhreere to REST principles while designing your
application, you will end up with a system that exploits the web’s archietcture to
your benefit.
○ In summary, the five key principles are:
■ Give every thing an ID
■ Link things together
■ Use standard methods
■ Resource with multiple represntations
■ Communicate statelessly
● HTTP REST Basics
○ Accept and Content-Type (Requests)
■ Client’s responsibility to use the Accept request header to identify the
expected content type of the returned resource.
■ Server (and client during POST and PUT) describes what is sending with
content-type headers - POST/PUT
● Whoever is sending stuff has to describe what it is.
○ Idempotent/Safe (Responses)
■ Methods GET, PUT, and DELTE are defined ot be idempotent:
● Meaning that multiple identical requests should have teh same
effect as a single request.
■ Some methods (HEAD< GET, OPTIONS, and TRACE) are defined as
safe, which means they are inteded only for information retrieval and
should not change the stat eof hte server.
● In other words, they should not have side effects besides relatively
harmless effects such as logging or caching.
 ■ Methods GET, HEAD, OPTIONS, and TRACE, ebing safe also implies
should also be idempotent.
● REST URI
○ Some of the fundamental rules of structuring the URI
■ Use nouns instead of verbs - since oyu are dealing with a resource
■ Use proper HTTP Methods to indicate your intentions - use GET to
reterive the data and DELTE if oyu want to remove it, etc…
■ GET is the only operation that does not modify the resource.
■ Utilize HTTP Response codes to communiate the stats of the request -
200 for success, 500 fo rsevice error, etc.
■ Query String should be used for providing optional filtering parameters or
collections, such as multiple ID’s.
● Content Negotiation/Media Types
○ A resource can be represented in different ways
■ JSON, CML
○ A client doesn’t know what server is sending.
○ Server doesn’t know what client cna handle.
○ Content types are negotiated using headers.
○ Content Negotiation is a mechanism defined int he HTTP specification that
makes it possible to serve different version s of a document at the same UR, so
that the user agents can specify which version fit their capabilities the best.
○ When user agent submits a request to server, the user agent informs the server
what media types it understands.
○ The server at the same URI (employ123..) has XML, JSON, whatever
reperesentation - server says “We have XML or JSON”. Client says “I can accept
JSON”, so server serves that.
● REST Frameworks
● Producing REST services
○ REST services in java apps can be implemented in several ways:
■ As a plain Java Servlet
● Adequate for very simple REST Services.
■ REST service framework eliminates the need to write boilerplate code.
○ JAX-RS, Java AP for RESTful Web Services, is a Java programming language
API that pvoides support in creating web services according to the REST
architectural style.
■ Methods to help.
● REST Frameworks
○ jrest
○ Spring3
○ CXF
○ Jersey
● CXF Framework for REST
○ Apache CXF provides robust support for several web service patterns and
specifications
 ■ Rich support for:
● Message Transports
● Protocol bindings,
● Content Negotiation
● Data Bindings and So Forth
○ Flexible, lightweight deployment for several varieties of applications that are
standalone.
● How CXF Works
○ Allows to start from existing java code and build a web service.
○ Supports for JAX-RS annotations
○ Uses request and response processing flows composes of configuratable
componets.
○ uses components incercepters and filters.
● REST Services with CXF/JAX-RS
○ Services are annotation driven
○ Provides support for data binding
○ CXF provides an implementation of JAX-RS
○ Implementation of JAX-RS
● CXF and JAX-RS Basics
○ JAX-RS applications consist of a hierchy of resources
■ Resources are served up by a CXF controller servlet.
■ Each REST resource is mapped to a request URI that is relative to the
CXF servlet path.
■ Relative path of each resource is mapped to a method on a JAX-RS
annotate service bean that returns the resource.
■ Service bean methods that return a resource must be annotated with a
single JAX-=RS haTTP method annotation
■ Additional optional annotations can be used to customize the service API
■ JAX-RS service beans are the view or public view of the service
application
■ Each bean will be scanned by CXF for annoatates resources that can be
served up RESTfully
● What is HATEOAS
○ Hypermidea as the Engine of Application State
○ Client doesn’t have a built in knowledge of how to navigate and manipluate teh
mode.
○ Client doesn’t know layout of mode,l, instead server provides that info. Uses
media types and link relations.
○ Representation of each state contains links that may be used next time the client
chooeses to initate a new state transiton
○ At its core is the concept of hypermedia
○ Links are something we’re all familiar with - not just for HUMANS!
● Link Relations
○ Client doesn’t know what a resource is related to or where it is located
 ○ Link has two parts
■ rel
■ href
○ rel avalues are standardaized so client can recognize them
■ Like, style sheets.
● HATEOAS Linked Applications
○ An applicatyion that has retreieved it can follow the links to retreive more
infomation.
○ Using URs the links can point to resources that are provided by a diffrent
application or a different server.
○ Since the URI naming scheme is a global standard, all of the resources that
make up the Web can be linked to each other.
■ BOOM. HEADSHOT

● HTTP vs HTTPS
○ HTTPS creates secure channel on insecure network.
○ Protects from eavesdroppers and man in the middle attacks, and the server is
trusted.
○ Encrypts an HTTP message prior to transmission, and decrypting a message
upon arrival.
○ HTTPS is not a seperate protocol, but refers to use of ordinary HTTP overa an
encrpytred Secure Sockets Layer (SSL)
● Filters, Interceptors, and Invokers
 ○ It is possible to intercept and modify the inbound and outbound calls with the help
of CXF JAX-RS filters and or CXF Interceptors
○ Filters - often necessary to pre- or post-process some requests according to a
number of rquirement.
○ CXF filter which will introspect the resource class, input or output meessage, the
operation which was invoked and modify the request or response accordingly.
○ JAX-RS filters can be thought of as additional handlers.
● Configuring JAX-RS Services
○ JAX-RS services can be configured programmatically using
■ Spring
■ CXFNonSpringJAXRSServlet
■ Or using configuration files

REST Implementation - JAX-RS Annotations

● JAX-RS Annotations customize many parts of the REST service
○ They identify the HTTP method for accessing a resource.
○ Identity the relative path for accessing a resource.
○ Identify how query and form parameters, headers, cookies, and other pieces of
HTTP request message map to jaa parameters and fields.
○ They identify the available content types that can be consumed or produced for
resource.
● JAX-RS Method Annotations
○ @GET
○ @PUT
○ @OPTIONS
○ @POST
○ @DELETE
○ @HEAD
○ Applied to Java method to bind it to an HTTP method.
○ Only one HTTP annotation may be applied to a single Java method
○ Multiple Java methods may be given the same annotation, assuming they are
bound to different paths.
● @Path Annotation
○ @Path annotations customize the request URI of resource.
○ @Path ona class defines the base relative path for all resources supplied by that
class.
○ @Path ona Java class method deinfes the relative path for the resource bound
to that method.
○ @Path on a method is relative to any @Path on the class.
○ In the absence of @Path on the class or method, the resource is defined to
reside at the root of the service.
● JAX-RS Parameter Annotations
○ Common JAX-RS Parameter Annotations
■ @QueryParam - maps to a query string paramete.
 ■ @FormParam - maps to a form POST parameter.
■ @PathParam - maps to a path segment.
■ @DefaultValue - supplies a default parameter value.
○ Most often used on service methods to annotate input parameters.
○ Additoinal parameter annotations are also available.
■ See the JAX-RS API documentation for details.
○ @Produces - the client submits content-type x
○ @Consumes - the client accepts content-type x
● @Produces
○ Used on a class or method to identify the content types that can be produced by
that resource class or method.
○ Method annotation overrides class annotation.
○ @Produces identifies the content type produced by the method its annotating. If
you don’t have one it assumes you are producing any content type.
● @Consumes
○ Same as the other one, except on the accepting side.
○ If not specified, assumes everything. Can’t find one that’s appropriate, will say
“406 Not Acceptable”

REST Implementation Layered Architecture Approach

● Service Architecture
○ HTTP Layer - where JAX-RS/CXF lives. Programmatic binding to underlying web
service.
○ Representation Layer - where representation of resources are
○ Resources Layer - Controllers that control - pass info that they get from
representation. Resources are the driving controller force.
○ Workflow Activities - Implement the individual activities in terms of resource
lifecycles; create, retrieve, update, delete, ...also responsible to changing states
of the underlining domain objects.

More on Service Architecture and JAX-RS/CXF Features

● Resource Class
○ Resource expose service implementation.
○ Java class annotated with JAX-RS annotations to represent a Web resource.
○ Root resources and sub-resources - root resources have to be annoated with a
@Path annotation, sub does not.
● Representation Class
○ Looks like the underlying domain object.
○ Sent over the wire after being converted to XML, JSON,...
○ It is marked with JAXB annotation to support XML serialization.
○ It will contain the links - HATEOS.
● Workflow Activity Class
○ These are unites of work
 ○ Delegated to work with the domain objects on behalf of the Resource class.
○ Executes some business interactions with the domain model.
○ Each activity knows about the valid activies that follow and is able to map those
activities to URIs.
● Client API
○ CXF JAX-RS provides a comprehensive support for developing RESTful clients
by intrdocing 3 flavors of the client API:
■ Proxy-based
■ HTTP-centric
■ XML-centric
● JAX-RS: XML and JSON Providers
○ As a requirement of JAX-RS, CXF automatically provides support for reading and
writing XML to and from JAXB annotated classes.
● How URIs are Matched
○ Four rules
■ Prefer the resource class which has more literal characters in its @Path
annotation
■ Prefer the resource class which has more capturing groups in its @Path
annotation.
■ Prefer the resource class which has more capturing groups with arbitrary
regular expressions in its @Path annotation.
■ Prefer a resource method to a sub-resource locator method.
●