*Disclaimer: This is just theory crafting

I'm interesting in learning about Service Oriented Architecture and have been reading up on it the past few days. I've been thinking about how I could take a Laravel application and separate its functionality in to services. For example, suppose I have an app that allows business owners to log in and create invoices and generates reports about their finances.

To my understanding, this kind of app could be separated in to three services. A user service, to log users in/out and perform authorization/authentication. An invoice service that generates and dispatches invoices. And a report service that would create reports (total number of invoices for a given time period, how many are outstanding, how many are overdue, etc).

How might we apply SOA to this Laravel application? I've been thinking about this and have the following theory:

1 - A central app attached to the root domain that would 1a - Deliver the user service 1b - Consume the other two services, invoice service and report service. In this way it would act as a thin client of sorts. 2 - The invoice service and report service would be web services 2a - These could be written in anything (Rails, Sinatra, Silex, etc) 2b - Both of these services would publish an API by which they can be consumed by the central app.

Is this an acceptable approach to applying SOA to a Laravel application? What problems might I run in to? The immediate problem I can imagine is how to do authentication/authorization via web services? And, is web services the only means by which this could be implemented? The benefit of using web services is that I can fairly easily create APIs and consume those over HTTP and I have a predefined standard (HTTP1.1) Which other ways exist to allow two services to communicate data privately to one another?

Any information/insights/suggestions/criticisms are welcome :)