| It is quite modern nowadays to decouple things. One project in USA to deal one business requirement, another in Pakistan to deal with some other business requirement and one more in Romania and one more in Bulgaria... Is it so good indeed to decouple single project into Web services and make them talk each other? Well I think as most things in this life decoupling has its advantages and disadvantages. I nearly lost my mental health becouse of an xslt to transform an xml document to another xml document so it can be sent from a system we are developing to a system, which provides document printing. Does it worth to write 14, 000 lines of xslt code only to print a document? Well, depends on the viewpoint. First of all decoupling minimizes |
The support is done by the other party, you don't need to care about it. That's good #3.
The other good thing is that there's always someone else to blame for something not working ;). That's joke ofcourse. The truth is that if your code doesn't work - you'll lose your clients. That's the simple truth about any business.
Now let's turn our attention on the disadvantages the SOA and decoupling may bring to you. The first and one of the biggest disadvantages is that YOU ARE DEPENDING ON SOMEONE ELSE. Any technical problem on their side will affect your side and what's worse - it will also affect your customers. And what is even worse- it will (in most cases) harm your reputation, not the reputation of the party that made the mistake (so be careful about what are you writing in the error messages the customer will see on other party fail;). Yeah, I mean it. You shouldn't accept the other party guilt as yours, if they could delivered it to you, you would have delivered it to the client, right? So instead of writing :
"Error, we have a problem"
write :
"Error, our partner have a problem."
Other big disadvantage is that while developing your side code you are facing a black box. You don't know what's happening in this black box and why it is responding in the way it does. You can only trust the documentation you may have. But is everything in it? No, I don't think so. Especially for complex services some small things are always missing and you need to either figure them out (which costs a lot of money for pills) or contact the other party and wait so they can clear the problem and document it.
I remember once I faced great problems with a web service which simply refuses to return any response. Only some simple empty xml document. Finally we figured out with my colleagues it needed two spaces in the begining of the document. I remember I wanted to swim from Bulgaria to USA to ask the guys who developed this thing to show me how would the request the document. The development dificulties, however are not a great obstacle, becouse once passed, they won't worry you anymore. But there is one more disadvantage which will remain - the transportation of the data. In order to get response from a third party service you need to send it request (this request is transported over the Internet), the service needs time to process it and then it returns you the request (which is also transported over the Internet). Then you may do something with this request and send response to the client (which is also done over the Internet). So instead one response / request pairs, you will have two. That's 100% bandwidth growth. It isn't something you can live with.
So the question remains. When should we use decoupling and SOA (I mean services, provided by third parties)?
I think it is a good choice to use third party services when you need some sort of information which is hard to obtain or may require too much time and which someone already have (credit reports in USA are good example, I think). You also may consider using SOA for services which will require a lot of time for development and which are already developed by third parties. For simple services - I think it is better to develope them on your own, so you don't waste too much bandwidth and depend on other parties.
