Hi Naveen, I prefer 3-tier architecture rather than 2-tier solely because working with data-model directly is not a scalable design.
I prefer web-services route only because I dont have to deal with SQL havocs(I am not SQL guru :)) and working with Databases which I dont own and have no control on. Furthermore, if database gets changed then you have to re-generate your view forms and re-attach workflow which is tedious and difficult to maintain over time(actually this is something that we just realized in our team). Think of databases as confidential papers or stores of personal information. If somebody knocks at your door and asks you about those confidential papers, how would you like to give them? Would you just, tell them to go and get them yourself, they are in so and so locker, or would you rather have them wait there and fetch papers yourself or through a trusted party? Tomorrow if the team with whom you are integrating changes their DB provider and if for God knows what reason your SQL breaks, then you are in trouble. Instead if they have a web-service in front of their DB, you wouldnt even care what they use on backend. Web-service itself is a binding contract between you and them. Also, I believe you can do tonnes of things on middle tier (like transaction/messaging management, writing to logs etc.)..which otherwise if you want to do in Remedy then it will become heavy task. Web-services are good for transactions..like if you are inserting data into db and waiting for an ID in response, that's where they could be really good, since you would be getting real-time data. 1 thing I really admire about web-services is their synchronous/asynchronous behavior. I am not really sure if it is achievable through direct SQL. I am having a real-time scenario where we are inserting data into other team's DB and it takes about 15 minutes for them to generate an ID. Since, they dont have web-services infrastructure, we have to go and poll their DB every 15 minutes, and sometimes it could be a hit- and-miss kind of situation. With web-services on both sides, data would flow seamlessly as and when available and we dont need any unnecessary escalations. Also, if you look at Remedy's architecture, its good practice to use either api or web-services...and as far as I am concerned I would like to minimize direct SQL unless extremely necessary...since we want Remedy server to handle all our DB transactions instead of our hand-written SQL code. My 2 cents. No offense to any SQL experts or people who prefer to go directly to DB. I know that this could be a never-ending discussion, but I just wanted to point out few things where I believe web-services would be good. Thanks Chintan. --- On Tue, 7/6/10, NNMN <[email protected]> wrote: From: NNMN <[email protected]> Subject: DB Links vs Webservices To: [email protected] Date: Tuesday, July 6, 2010, 4:38 AM Hi ARSers, Something which i have been thinking about. I want to know your views on this. Let us imagine we have systems, SYS-A(Remedy with its backend) and SYS-B(another platform app(like java,.NET etc) with its backend). Now if i want the data from both these systems to flow from each other for certain interactions, lets say i have the possibility of below methods. Method-1) I use web-services exposed from both sides to mutually call and get the input/output approprately and thus i acheive transactions. Method-2) I expose some relavant schema details as DB links and then i access them from where ever required (as view forms Remedy). Now i want to know about the pros and cons of above methods with respect to . I always feel that Method 2 is kind of crude way of implementing, but in a way i get this feeling from many i talked, that it is an easier and effortless way to go about it. Still thinking on a long term, reliability, data-transfer speed etc factors. Cheers, Naveen ----- With Warm Regards, Naveen -- View this message in context: http://old.nabble.com/DB-Links-vs-Webservices-tp29084418p29084418.html Sent from the ARS (Action Request System) mailing list archive at Nabble.com. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
