web-servicesrestsoasaas

Service Oriented Architecture suggestions


For personal and university research reasons I am thinking of building a simple CRM using a service oriented architecture. Its meaning is just to explain the architecture itself, not commercial use.

I was thinking of implementing a CRM that offers a simple analytics service and customer care (user storing, personal comments, and few other things).

The architecture that I'm designing defines: - WebGUI (a client of the other services) - AnalyticsService (a service that receives data, analyzes and collect it) - CustomerCareService (a service that uses RESTful APIs to apply CRUD operations).

Each service has it own database, being completely independent from others. They expose a public interface. The interface of course must provide some sort of authentication, to deny unautorized requests.

The advantages I'd like to explain in this kind of architecture is the possibility to have all things indepentent and the ability to combine them to offer new services (for example if there was an OrderService to handle orders it would be easy to combine it with Customer using the public APIs). The big advantage to me is that it'd be easy enough to build other clients that use these services.

I don't know what is some good Authentication method, that could be easy to implement, I'm also not sure about how to make this APIs (use XML or plain REST APIs with GET/POST data). I've worked with Amazon, PayPal and other company APIs, they seem to use REST services (paypal uses an ugly _cmd GET parameter while Amazon uses better URI) to know what to do, but reading something about SOAs it appears that people also use XML. Of course I also need to take into account that the web interface must be able to recognize the logged in user, get the permissions (token or whatever else) and use it with services to show information. So I'm not sure SOA is the kind of architecture I'm really building up... is it SaaS instead of SOA? I think it would be better to use RESTful applications, with JSON or something like that to implement it (I'm not a big fan of XML, I find it to be too verbose).

For clarity I'm listing here my questions:

  1. Is this kind of architecture called SOA or SaaS (or both)?
  2. What is a good implementation for what I want to obtain? (please explain it as more detailed as possible)
  3. What sort of authentication is more suitable for a client (user token vs OAuth or similiar)
  4. Do you have some suggestion for this kind of project?

I've about 3 months to do it, so I cannot do something real complex (beside the fact that it would not be realistic for a single programmer).

I know Python (WSGI frameworks), Ruby on Rails, C/C++ and other languages (.net excluded) and I'd like to develop it under a Linux environment (MySQL or Postgres, or even a NoSQL if you have any suggestion for the right choice), I could also combine several languages being these services independent programs.

What I'd like here is to have some good point of view and some good suggestion.

Thanks!


Solution

  • I would define SaaS as a Business model rather than an architecture. Like all business domain requirements, SaaS influences systems architecture, but in and of itself, it is not an architecture.

    What you have defined is essentially a Service Oriented Architecture.

    Your statement "independent and the ability to combine them to offer new services" is the essential non-functional design requirement that suggests SOA.

    Good implementations of SOA is have well-defined and flexible interfaces, with very clear delineation of responsibilities. However it is difficult to be prescriptive about this. The proof is in the eating; does it provide flexible reuse.

    My suggestion is to spend time reading SOA design pattern resources, and understanding the defining characteristics with regard to the appropriate context for use. Then apply the Single Responsibility principle appropriate level of abstraction. c.f. (Domain) Space Based Architecture is kind of SOA meta-pattern.

    In regard to Authorisation, I recommend following the service approach: use a distributed directory services system like open LDAP, and note that is entirely reasonable for service provides and users to have their own credentials and you can use Public-Private keys for signing messages.

    The main suggestion is study and learn from experience of others: