1. Middleware, Services, etc.
CSCE 315 – Programming Studio
Spring 2013

2. Goal: Reuse and Sharing
Many times we would like to reuse the same process or data for different purpose
Want ways to “reuse” code, tools, etc. for different purposes
Want ways to “share” data across different applications
A variety of technologies, techniques, etc. have been developed to do this

3. Non-sharing stuff Silos Standalone programs
Idea is that data is stored in such a way that it cannot be communicated to other applications
Standalone programs
Run locally on local data

4. Middleware
“Middle” layer between applications and resources provided elsewhere
more basic system (OS)
distributed applications running over internet
Provides a common interface for distributed applications
Allows heterogeneous HW/OS platforms
Allows use of resources provided elsewhere
Provides an API for abstracting stuff on the other side
Usually applied to distributed applications

5. Middleware for Distributed Services
Relies on common interchange formats
XML data interchange (we’ll come back to this)
JSON (JavaScript Object Notation) – XML alternative
SOAP (an XML-based message passing framework)
Simple HTTP
Application-specific formats (e.g. for a company seeking to integrate products)

6. Web Services Idea is to provide a “service” that will have common use
Service can be used by a wide variety of programs
May allow others to “plug in” to a larger system (e.g. Facebook)
May allow others to use a “component” from some other system (e.g. Google Maps)
Can vary in many ways
Access method
State maintained, or passed only through message?

7. RPC Web Services Remote Procedure Calls
Traditional type of web service
Basically like calling a subroutine or object method, but on another system
This should seem almost transparent to the user, so that it feels like just calling a local method/routine
Syntax for doing so is more complex, though
Usually use a particular message passing system (like SOAP)

8. RESTful Web Services RESTful (REpresentational State Transfer)
Very few and simple commands (GET, PUT), but more complex method of describing resources
Resources are the “objects”
In implementation, typically each resource has its own URL
E.g. a person in a database is a resource
Will have a unique URL for that person
Calling that URL will get a “document” about that person
Document will have hyperlinks to other related information, each of which is another resource

9. Service Oriented Architectures
Idea is to break up programs into a set of services
All services are accessed over a network
Communicate with each other
Applications are built by combining services
Can be especially beneficial for:
Large organizations (sharing resources throughout)
Creating mashups from multiple sources
Allowing use of an “expensive” feature
Tying a project into one with a larger user base

10. Commentary This area has had an explosion of jargon, terminology, etc.
Much of it driven by business interests
Those offering frameworks for development
Those offering software to integrate
IT/corporate groups looking to describe what they’re doing
Basic principles aren’t that different, or particularly complicated
Distribute the computation and/or data
But, there are a lot of different ways that this gets done
Different frameworks, different syntax, specializations, generalizations, etc.