Comparing the two tools is like comparing apples to oranges at best.. The are two completely different tools with completely different set of capabilities with only a couple of capabilities in common.
The number one reason I would choose the SQL routes over others if the SQL route is a possible solution, is its efficiency assuming you have a good SQL code. Executing SQL code bypasses the ARS application layer, and that in itself, is an advantage for performance reasons. Direct SQL's are thrown to the DB server AS-IS, even if it is garbage. Is that a bad thing? Not necessarily. You just don't write code without validating it for its correctness and efficiency do you? Agreed, if you move databases, some SQL code MAY not remain valid, and may have to be modified. This is true even sometimes with a DB upgrade. But how often does that really happen? If that is the primary concern, it is possible to pre-prepare code for other databases, if the code would differ for the same operation by doing a $DATABASE$ check of what is the current database. Examples of when web-services over any other direct method may be preferred: 1) You have absolutely no clue about the other application you want to submit or retrieve information from and that system does have web service publishing capabilities. 2) You have no time or reasons to justify the re-invention of a wheel, if its just a simple submit/query type of an action you want the ARS to perform on the other application or vice versa.. 3) You trust the other application is well written, if you have to query from a large table, so the underlying query performed by the web service is efficient. If not, you might be better off with a DB-Link solution. Examples of when a DB-Link may be preferred: 1) You want to display the results of a query into another application on a table field in the ARS. 2) An external application needs to query an ARS join form, that could more efficiently be done with a union join. Creating that union join at DB level and publishing a DB-Link to it might be a better idea than to create that join at DB level and creating a Remedy view form. If you are going to create a join at DB level, you might as well maintain the whole integration effort from the DB perspective.. 3) Querying large tables where you suspect default application queries are inefficient.. Joe -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]]on Behalf Of Chintan Shah Sent: Saturday, July 10, 2010 1:55 AM To: [email protected] Subject: Re: DB Links vs Webservices ** 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 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
