1) Yes, the 'middleware' you describe is the Service Provider and the 'SSO server' is the Identity Provider.
2) When the user attempts a protected resource on the Service Provider, it will redirect the browser to the Identity Provider. If the browser does not have an active session with the Identity Provider the user will be prompted for login details.
Following which the browser will be redirected back to the Service Provider along with the SAML response authenticating the user. After verifying the SAML response the Service Provider will redirect to the protected resource.
Once the user is authenticated the Service Provider can keep it's own session to save redirecting to the Identity Provider for every request.
3) The Service Provider (middleware) would not normally keep the SAML response from the Identity Provider, instead it can set up it's own session. For example in .Net this can be down via Forms Authentication.
4) When the user tries to access another Service Provider, the browser will be redirected to the Identity Provider. As the user already has an active session, the Identity Provider will redirect back to the Service Provider with the SAML repsonse. The service provider will then redirect to the protected resource and optionally create it's own session.
This happens seamlessly to the user, and they are effectively logged straight into the second Service Provider.
Also which platform are you using for development? If you are using .NET or Java then I can recommend the open source library OIOSAML. It includes working examples of both Service and Identity Providers so you can see how things work.