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:
Is this kind of architecture called SOA or SaaS (or both)?
What is a good implementation for what I want to obtain? (please explain it as more detailed as possible)
What sort of authentication is more suitable for a client (user token vs OAuth or similiar)
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!
I would define SaaS as a Business model rather than an architecture; however like all business domain requirements it will influence systems architecture but it, itself is not. What you have defined is essential 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 implementation for SOA is about having well defined and flexible interfaces, with very clear delineation of responsibilities. However it is difficult subject to be prescriptive about. The proof is in the eating; does it provide that flexible reuse. My suggestion is spend time reading SOA design pattern resources, and understand 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 distribute 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:
http://www.soapatterns.org/
http://martinfowler.com/eaaCatalog/
SOA doesn't forces to use XML.
Currently web technologies dominate, and define future.
So we in my company selected JSON RESTful services as foundation. And SOA as principles.
There is no sense to suggest languages, because the purpose of SOA and good implementation is
- to enable any language or framework to be used
(FYI we use Java with Spring MVC-based web-services, Node.js, PHP)
Related
I'm struggling with the decision between a traditional backend (let's say a Django instance managing everything) and a service oriented architecture for a web app resembling LinkedIn. What I mean with SOA is having a completely independent data access interface - let's say Ruby + Sinatra - that queries the database, an independent chat application - Twisted - which is used via its API, a Django web server that uses those APIs for serving the content, etc.
I can see the advantages of having everything in the project modularized and accesed only via APIs: scalability, testing, etc. However, wouldn't this undermine the site performance? I imagine all modules would communicate via HTTP requests so wouldn't this arquitecture add a lot of latency to basically everything in the site? Is there a better alternative than HTTP?
Secondly, regarding development ease, would this really add much complexity to our developers? Specially during the first phase until we get an MVP.
Edit: We're a small team of two devs and a designer but we have no deadlines so we can handle a bit of extra work if it brings more technical value
Short answer, yes, SOA definitely trades encapsulation and reusability for latency. Long answer, it depends (as it always does) on how you do it.
How much latency affects your application is directly proportional to how fine-grained your services are. If you make very fine-grained services, you will have to make hundreds of sequential calls to assemble a user experience. If you make extremely coarse-grained services, you will not get any reusability out of your services; as they will be too tightly coupled to your application.
There are alternatives to HTTP, but if you are going to use something customized, you need to ask yourself, why are you using services at all? Why don't you just use libraries, and avoid the network layer completely?
You are definitely adding costs and complexities to your project by starting with an API. This has to balanced by the flexibility an API gives you. It might be a situation where you would benefit from internally structuring APIs to your code-base, but just invoking them as modules. Or building libraries instead of stand-alone APIs.
A lot of this depends on how big your project is. Are you a team of 1-3 devs cranking to get out your MVP? Or are you an enterprise with 20-100 devs that all need to figure out a way to divide up a project without stepping on each other?
There is clearly a LOT of misunderstanding surrounding the term REST. Many people still seem to tie it directly to HTTP, or even equate the two, simple because they often come together. I'll admit, I'm still improving my understanding of when the term "REST" is applicable.
However, there are clearly (in my mind) web service that support the transfer/retrieval of formatted data (e.g. JSON, XML, etc.) that do not deal in hypermedia or the details of a more general protocol like SOAP. In general the concept of web services seems to be overly conflated with protocols and architectures when in many cases a simple query string key-value pair request and a 1 or 0 as a response would suffice (and probably cut down on development time and application dependencies). Why all the fluff all the time?
I imagine I can't be the only one looking at things this way—so is it possible to avoid the buzz-words and get across the concept of a simple, custom-data HTTP web service? Or am I being overly semantic when I should just be saying "REST"?
Is there a standard term for an HTTP web service that is not RESTful or for a call to such a web service?
A custom web service, you said it yourself, or maybe a WebAPI, or HTTP API ?!?
A web service is a software system designed to support interoperable machine-to-machine interaction over a network. There are lots of ways to implement one and a simple query string key-value pair request and a 1 or 0 as a response would indeed suffice.
This is about the audience.
If this is an internal service, you can build it however you want and name it however you like. But if you want to expose it to clients or users, other than yourself, then you really only have to choices: SOAP or REST.
Why?
Because of existing tools, existing documentation, existing experience, available libraries, support in servers, languages etc.
The title of your question expresses this: you are looking for a term, something that people understand what it means. Right now people understand SOAP and they (think they) understand REST.
I am developing a SOAP interface and am having trouble deciding what to name the endpoint address.
Options:
- {soap,api,service,???}.foo.com.au
- www.foo.com.au/{soap,api,service,???}
What are the typical names that a SOAP service gets?
I would use www.foo.com.au/soap, mostly because it's an easy way to tell people that it's a SOAP service, and if you want to add a REST service later, you can use www.foo.com.au/rest
Keep in mind, in practice, all solutions are technically equivalent. The benefits of one naming system over another are only at the ease or understanding what the URLs are about (for humans), or maintainability, really. So, if you are searching for a standard we can tell, at best:
If you have a big company with lots of applications, go for the http://api.company.com/application/rest and/or http://api.company.com/application/soap approach
Reason: you can separate, right from the start (networkwise) the web service servers (http://api.srv.com/app) from the human web browsing servers (http://www.srv.com/app).
All applications have one big root "meeting" point (the root URL api.company.com), so if anyone wonders what is company-wide available, just check http://api.company.com and it can list all services available.
If your setup is not that big, it is probably not worth the trouble, so don't fear using the www.. But keep in mind it's best to use at least a different context, such as api/, so that anyone knows right off the bat a service URL is about a web service(!): http://www.company.com/application/api/rest / http://www.company.com/application/api/soap
Note: It's also common to use service, although api seems to be somewhat better descriptive (api.something.com leaves no doubt about what that page is about).
Some examples (as you can see, there is really no global standard):
Google's search API: http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=test
Twitter's search API: http://search.twitter.com/search.json?q=w00t
Facebook' Graph API: http://graph.facebook.com
Facebook' Dialog API: http://www.facebook.com/dialog (see, no standard even within facebook!)
Weather Gov SOAP forecast: http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl
Buy many seem to keep the good ol' company-wide APIs "meeting points":
http://developers.google.com
http://developers.facebook.com
http://dev.twitter.com
I am in the process of developing a rich internet web application that communicates to a (Java) back-end via web services. I have prototyped a user interface in both Flex/Flash and GWT/Javascript and have noticed that these RIA platforms tend to favor an RPC-style method of back-end communication (AMF for Flex and GWT-RPC for GWT).
In my case, the server also needs to provide web services other clients that I do not author. Because of this, I am leaning towards standards-based web services (e.g. SOAP and REST). I am convinced that the RIA must use the same web service we provide for others. I "get" SOAP because it models the RPC style I am familiar with from experience. I am new to REST, but have prototyped a REST back-end using CXF/Jackson. At this time, however, my REST API still feels like an RPC-style API and I realize it's because I am having trouble getting my head around the idea of HATEOAS.
I have read Roy T. Fieldings helpful blog post about 10 times and I think I am beginning to see the light. For example, it is clear to me that if I were to include links to various state transitions along with my resource I could really reduce the amount of coupling between my client and server. My client could just render buttons that provide the user with access to the legal operations that can be performed on the displayed entity at that time.
But does loose coupling between a RIA and its server application matter?
By their very nature, RIAs are pretty tightly coupled with the server data model. Out of the box they presuppose many things. I am guessing that is why they also prefer an RPC-style application protocol...because loose coupling is not a design goal. But I am beginning to realize that if we took HATEOAS seriously, we could write a much more generic RIA client that would make VERY few assumptions about the data model and operations that can be performed. That could reduce the amount of effort to maintain the client through changes in the back-end, but does this make sense? does the benefit outweigh the cost?
p.s. - Two more details -- This application has an extremely complex, deeply nested data model. Also, I could not care less if somebody tells me we are not a 100% pure REST web-app.
It's an excellent philosophical question. My general response is some coupling should be expected.
Let me explain more. While it's possible to conceive of a fully generic application interface that just exposes the model in a human-usable way, it's actually incredibly difficult to write such a piece of software except for truly miniscule domains (e.g., filling a record that will be used to populate a DB where all the fields are picked from finite simple enumerations). If your application doesn't fit that model, you're going to have to have something in there that is specific to the app. If you do that in a “generic” way, you'll be downloading a complex description of what your generic client app is supposed to do, and that description will itself start to feel more and more like a programming language. Now you're back to square one, except with a (probably badly-designed) new domain-specific language in the mix as well. You might as well cut to the chase and accept that going wholly generic isn't worthwhile.
But that's not to say that you shouldn't take care to think carefully about what resources you expose, what verbs apply to those operations, and how users' software will discover those resources. Following REST and HATEOAS there will help a lot (and it helps if you've got a clear idea about what the application's underlying abstract model is; you should aim to expose that in a natural way).
Given that the GWT app is served by HTTP, having it tightly coupled with the server is not violating HATEOAS. It's" code on demand".
Google, Twitter and Facebook all use specific APIs for their app, different from the one exposed to third parties (Twitter has recently moved to using their public API for their web app, but it wasn't originally the case). Google said they had no plan to move G+ over to its public API, because it allows them to experiment and make breaking changes without breaking third parties.
I have read a tutorial "web-service-php-mysql-xml-json".
It seems everything is ok. But then why we should use soap for web services?
When building web services you can go two ways:
SOAP
REST
Most people choose the path of less resistance, which is REST. This means simplicity, ease of development, using HTTP the way it's meant to be used, make good use of cache proxies, more human readable results etc.
SOAP on the other end is more heavyweight than REST and is also backed up by a large set of specifications. But because it is more complex (SOAP used to be the acronym for Simple Object Access Protocol – which proved to be... NOT) SOAP is not liked by lots of people.
Both approaches work and both have advantages and disadvantages.
For example, SOAP can make use of any transport protocol not just HTTP(S), SOAP offers more options when security is concerned, SOAP offers reliable messaging etc etc. REST on the other hand permits many different types of data formats, REST allows better support for browsers because of the JSON format, REST has better performance etc etc etc.
I’m not going to go into more details since you can find a lot of comparisons SOAP vs REST on the web. The thing that I want to emphasize is the fact that in some cases one works better than the other and it is up to you to determine and choose which one to implement given your particular case.
EDIT: To answer your question:
why use SOAP or REST? we can have web service without them?
Well, the W3C defines a web service as "a software system designed to support interoperable machine-to-machine interaction over a network".
OK... that's nice for a definition. But this is not the definition for SOAP/REST, this requirement can be successfully thrown at a communication protocol to handle.
So basically you could have a web service using whatever communication protocol you want (even creating your own) as long as is supports the "interoperable machine-to-machine interaction". This also means something else than SOAP or REST (OK... REST is not a protocol, I just use it here as reference to prove my point... so bear with me).
But you create a web service because you want some clients to use your service. And your clients are out there in the wild wild west (i.e. the web :D) and people there speak SOAP/REST. An there you come and say: "We relly don't like SOAP and REST here in our shop, we like stuff like RPC, CORBA and our own unique creation the "Bone Crusher 10000" protocol. If you want to do business with us, you go learn the "Bone Crusher 10000"". And your clients will say (eyebrow raised) "Yeaaaaah righttttt.....".
(I'm assuming here that your protocol won't be something ground shacking that will totally outclass SOAP/REST :D)
So, if you don't use SOAP/REST you will limit your target audience. It's like English for example. I'm not a native English speaker, are you? Well, it does not really matter since we are able to communicate in English. Want to try this in Icelandic? . Will you wait for me while I learn Icelandic, cause that's not my native language either?
As I already said, it is up to you to determine and choose what to implement given your particular case, but if you move away from known technology stacks you throw away what comes with that: lots of experience, resources, tools and communication options.
As a closing example, there's a lot of support for the SOAP protocol today and you can generate clients very easily starting from the WSDL file. And presto... your clients can communicate with your web service. Will it go as easy as this with "Bone Crusher 10000"? If you write the tools, provide the resources, support etc... Yes! But that will cost you time and money to create something that was already invented and is in wide use today.
An important point user159088 mentions in her/his answer is "[...] you can generate clients very easily starting from the WSDL file [...]"!
I'd like to further elaborate on this:
You can use SOAP in conjunction with WSDL which is standardized what means that people who know the standard (WSDL) can learn from it what operations a webservice offers and how data is exchanged.
This knowledge can be used f.e. to create tools that generate type safe binder classes/objects out of the WSDL file. You can make use of those generated classes (to make RPCs) without manually implementing the requests and encoding/parsing of the data that is exchanged.
Whereas for REST there is no standard (like a WSDL schema) on how the exchanged data looks like. As a result you often end up parsing the data on your own.
A second point is that REST works mainly with the HTTP(s) protocol (it is based on it). It uses the CRUD verbs (CREATE/READ/UPDATE/DELETE) of the HTTP(s) protocol. SOAP does not rely on it and can thus be used with other protocols as well.