Why the change in architecture?

With SSPs everything was lumped together, even though some services offered very different capabilities. This made SSPs difficult to deploy and manage over the lifetime of your SharePoint deployment. Plus, because SSPs were effectively grouped together into a single database, scalability became difficult. In addition, allowing administration of a single service in the SSP, so that every administrator could administer any service, was next to impossible. Finally, you couldn’t really share services across farms. There were many restrictions and the administrative and management overhead made administration difficult.
As a developer, you can write your own Service Application that provides services to your features that run on the SharePoint WFEs. There are certain scenarios in which this makes sense. For example, if you need specialized computing and analytics, if you want to share data across sites, site collections, and farms, if you need to execute long running operations or if you want to scale out your application by taking advantage of the services infrastructure. You should not use Service Applications if your data or features are specific to a site, a site collection or a site template. Instead, you should write code that runs within the boundaries of your site or site collection, such as event receiver or web part.
Anyways I may not tell you writing a complete Service Application because even I too don’t know. But I can provide some steps to be aware of and also the APIs associated with Service Applications. To write a good Service Application, you should have a working knowledge of Windows communication Foundation (WCF), because Service Applications use WCF extensively to communicate between the Service Application Proxy and the consumer.
The steps to write a Service Application at the high level are:
1. Create Service Application
2. Create Service Application endpoint using WCF
3. Create Service Application Installers
4. Install and provision Service Application
5. Create Service Application Proxy
6. Create Service Application Proxy Installers
7. Install and provision the Service Application Proxy
8. Create Service Application consumers
9. Install, deploy and test consumers

How Does Claim Based Authentication Works?

This is the simplified version of how claims work. The easiest way to think about how claims work is to take a real world example. Let’s imagine that you need to board an aero plane. First you need to check in. That could be at the ticket counter or that could be online. Both require you to authenticate yourself in different ways. The ticket counter requires you to show some form of ID and that ID comes from a trusted source. Online you are forced to login and that login must be trusted in order for you to print your boarding pass
Your Boarding pass contains a lot of extra information rather than just your name. It contains your destination, the gate you are leaving from, your flight number, and also your seat information. When you reach the gate, the gate agent checks your boarding pass. This agent doesn’t really care whether your claim came from the ticketing agent or from your printer at home. The boarding pass is trusted claim and you are allowed to get on your flight. If we translate this to software, that boarding pass is a signed security token from a trusted issuer. Your application would validate it and allow the user or application presenting that token to have access to the resource that was requested.