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

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

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

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

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)

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?

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)

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

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

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.