Intro to Service Oriented Middleware

finishing up!

service oriented middleware

each component provides a single service where a service is a cohesive collection of functions

does service oriented middleware have state

no notion of state, lots of value passing, often document based

step 1 service publication

make a service’s endpoints accessible to clients

approaches to step 1 service publication

naming service, trading service, urls

step 2 service discovery

look up the service in whatever discovery services it has published itself to

lifecycle issues with step 2 service discovery

service might want to un-publish itself when it is no longer available or relevant, you can’t assume services will always remain available

step 3 service interaction

access the service through its endpoint

main vehicles for web services

XML RPC (smaller systems), SOAP (larger systems)

web services 1

get away from a single monolithic middleware architecture

web services 2

a service that can be invoked using web protocols, as opposed to an object that needs its own specialised protocol

distributed objects vs service oriented architectures

distributed objects emphasise the state involved in a system, service oriented architectures decompose in terms of the sub-processes involved

why use service oriented middleware 1

integrate into existing network

why use service oriented middleware 2

portable, language neutral and platform neutral

why use service oriented middleware 3

wrap up existing services