I do agree that it can help with benchmarks to lock into some "givens" and go from there, but even choosing something as common as SOAP gets you into the SOAP vs REST discussion (e.g. http://www.oreillynet.com/pub/wlg/3005). I can imagine doing benchmarks where you say "given these technologies, what else works well with them" but would prefer to also have benchmarks that leave more open.
Starting with user requirements and measuring a full range of quality requirements, including various performance and scalability measures would keep those technology wars out of the testing. It is the fact that SQL, an industry standard, is tightly coupled to industry benchmarks that we are even having this discussion. How can you get to something better if you lock into a specific technology or approach when doing benchmarks? That said, at this point in time we could at least do tests with TCP/IP as a given, I suspect, then tests with http, and then with SOAP and REST and all such information would be helpful. The other thing I found was that most of the really good benchmark testing is done by large companies in their R&D areas. I would guess that companies like IBM really do know the various performance and scalability comparisons among their own products and likely those of competitors too. If they do not, then large database users have done such testing. That information doesn't leak out so easily, however. --dawn On 7/17/07, Nick Cipollina <[EMAIL PROTECTED]> wrote:
On one hand, if the purpose of exposing this data is for internal consumption only, then some sort of proprietary format would be perfectly acceptable. In fact, we are using a sort of proprietary format for communication. The problem with this approach is that when you begin dealing with outside organizations, your proprietary way of communicating is no longer that clever. This is when using a standard protocol, such as SOAP, really has value. To me, this is part of the problem that we have in the MV world. We look at how things are being done elsewhere and say, "Pick does it better, we aren't going to do that." The problem with this approach is that everyone else is adopting these standards and using them. We are going to be left further behind if we don't start using some of the technologies available to us. On an unrelated note, we interviewed a .Net developer that worked for a company that also had a UniData shop in house. He was telling us about this custom interface they used in communcations. He didn't know anything about it's origins, except that you had variable length records delimited by "funny" looking characters. I asked him if the characters were ASCII 253, 254 and 255 characters, and he said in fact that he thought they were. The moral of the story, not really sure, I just thought it was kind of funny. Thanks, Nick Cipollina -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dawn Wolthuis Sent: Monday, July 16, 2007 11:22 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] UniData 7.1 vs. MS SQL 2005 performance I do understand the advantages to that approach, Nick. But that was also the thinking of those who prepared the current industry benchmarks by locking in on SQL. My concern was that if you specify technologies, you can make it difficult for solutions that are outside the box. --dawn On 7/16/07, Nick Cipollina <[EMAIL PROTECTED]> wrote: > If the consumer of this data is going to be external, then I would > definitely use web services. Using a standard format (SOAP) will make > it possible for anyone to consume the data. > > Thanks, > > Nick Cipollina > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dawn Wolthuis > Sent: Monday, July 16, 2007 4:58 PM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] UniData 7.1 vs. MS SQL 2005 performance > > Yes, agreed. I think if you start with user requirements for services, > then have folks design for those requirements according to each > environment, that would be a good start. I hesitate to say that it > must be "web services" only because that might imply use of SOAP or an > XML exchange that could prejudice the implementation, but otherwise > defining the requirements as services makes a lot of sense. Each > service implementation in different environments can then be judged > and compared by a variety of measures. <snip> ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/