HT/VT Web Site
-
hpaulsen
- Member
- Posts: 113
- Joined: Fri Mar 09, 2007 12:53 pm
- Location: Barstow, CA
I considered web services for a product I have been working on, but after doing some research came to the same conclusions - the network overhead was too great, particularly for the small data packets I intended to use. There are alternatives. Even just compressing the xml data can help on network traffic, though it adds even more processing requirements. For my program, this was fine because much of it would be done on the customer's machine. There are always trade-offs, and what method you use really depends on your priorities. If security and ease-of-use is desires, web services may be ideal. If processing time and/or bandwidth are concerns, then I'd consider an alternative.
-
mkmurray
- Senior Member
- Posts: 3266
- Joined: Tue Jan 23, 2007 9:56 pm
- Location: Utah
I agree with HPaulsen. The decision to use WebServices should be weighed by your priorities. I think everyone would agree that WebServices entail some overhead; although, sometimes the overhead is introduced because of the gain you get in abstraction, usability, and security.
Large, complex systems ideally should be designed to be modular and flexible (remember, that's what we shoot for, and not always the reality for the current implementation at some random corporation). I personally think this implementation will not be a one-time deal, only used for a HT/VT reporting module. If designed right, this system could be molded into many different uses and possibly display or store the data in many different forms, flexible enough for whatever the Church's needs are.
One thing to consider too is where this HT/VT Reporting module is to be hosted. Is it apart of MLS? LUWS? Is it hosted centrally at the Church for all units? Is it more of a client that has to make remote calls to where the data is? It may be the case that the module is not being hosted right there beside the data. In that case, WebServices might be the only option.
Personally, I think as complex and large as the Church's systems are and also as large as their requirements are, the WebService approach may have a big advantage in the long run.
Large, complex systems ideally should be designed to be modular and flexible (remember, that's what we shoot for, and not always the reality for the current implementation at some random corporation). I personally think this implementation will not be a one-time deal, only used for a HT/VT reporting module. If designed right, this system could be molded into many different uses and possibly display or store the data in many different forms, flexible enough for whatever the Church's needs are.
One thing to consider too is where this HT/VT Reporting module is to be hosted. Is it apart of MLS? LUWS? Is it hosted centrally at the Church for all units? Is it more of a client that has to make remote calls to where the data is? It may be the case that the module is not being hosted right there beside the data. In that case, WebServices might be the only option.
Personally, I think as complex and large as the Church's systems are and also as large as their requirements are, the WebService approach may have a big advantage in the long run.
-
WelchTC
- Senior Member
- Posts: 2085
- Joined: Wed Sep 06, 2006 8:51 am
- Location: Kaysville, UT, USA
Web Services...
Web services are a must at the Church. You need to remember that not all data is stored in 1 big database but may be spread out across multiple systems. When talking about the HT/VT system, it will need to interface with the membership database(s) but could also integrate into other systems. Web services will make all of the integration into various systems transparent. Otherwise every developer on the team would have to know and understand each DB schema, rules, etc.
Web services also can provide much more security. Since membership data has to be kept extremely confidential, it is a must to provide as much security around this as possible.
Tom
Web services also can provide much more security. Since membership data has to be kept extremely confidential, it is a must to provide as much security around this as possible.
Tom
-
brado426
- Member
- Posts: 313
- Joined: Sun Feb 11, 2007 9:50 pm
- Location: Foothill Ranch, CA
Just to clarify, I wasn't trying to imply that I thought the Church was doing it the wrong way. I'm sure the Church has already done the research and selected the best method based on the pros and cons.
I just think we should be careful to be sure to state the pros and cons of using any technology here so that other technical people reading this can better make an educated judgement for themselves.
I was researching this because I was thinking about suggesting this method for my organization. However, after doing some additional research, I don't think it would work in our particular circumstance.
Brad O.
I just think we should be careful to be sure to state the pros and cons of using any technology here so that other technical people reading this can better make an educated judgement for themselves.
I was researching this because I was thinking about suggesting this method for my organization. However, after doing some additional research, I don't think it would work in our particular circumstance.
Brad O.
-
WelchTC
- Senior Member
- Posts: 2085
- Joined: Wed Sep 06, 2006 8:51 am
- Location: Kaysville, UT, USA
Thanks for the clarification.brado426 wrote:Just to clarify, I wasn't trying to imply that I thought the Church was doing it the wrong way. I'm sure the Church has already done the research and selected the best method based on the pros and cons.
I just think we should be careful to be sure to state the pros and cons of using any technology here so that other technical people reading this can better make an educated judgement for themselves.
I was researching this because I was thinking about suggesting this method for my organization. However, after doing some additional research, I don't think it would work in our particular circumstance.
Brad O.
Tom
-
bhofmann
- Member
- Posts: 272
- Joined: Tue Feb 06, 2007 9:47 am
- Location: Tulsa, OK
Most open source projects use open source tools that are available to everyone (like MySQL). I think this is why most open source projects are successful in a community environment.brado426 wrote:A community member working on an outsourced project for the church would need an adequate test environment at their home. Therefore, some instructions or possibly even tools would need to be made available to these community developers.
The thing that jumped out at me is when you mentioned that the church mostly uses Oracle for a back-end database. I have used Oracle at work for a couple development projects, but we mostly use MS SQL. I can get an MS SQL server set up easily because I have done it many times and Microsoft provides a free watered-down version to developers. Though I have done some development with Oracle, I have never set up an Oracle server... nor do I know whether a free version that matches the same version that the church uses is even available to run at home for development purposes.
Depending on the complexity of the project you might be able to export table schemas and sample data that can be executed in a variety of databases. Then developers can have a development environment with the database of their choice. Proper application architecture requires that data access be a separate layer anyway. Of course there are slight differences in SQL syntax between some databases...
Just thinking out loud.
-
WelchTC
- Senior Member
- Posts: 2085
- Joined: Wed Sep 06, 2006 8:51 am
- Location: Kaysville, UT, USA
which is where middleware software like Hybernate come in which abstracts the database from the application. And now we have come full circle.bhofmann wrote:Most open source projects use open source tools that are available to everyone (like MySQL). I think this is why most open source projects are successful in a community environment.
Depending on the complexity of the project you might be able to export table schemas and sample data that can be executed in a variety of databases. Then developers can have a development environment with the database of their choice. Proper application architecture requires that data access be a separate layer anyway. Of course there are slight differences in SQL syntax between some databases...
Just thinking out loud.
Tom
-
bhofmann
- Member
- Posts: 272
- Joined: Tue Feb 06, 2007 9:47 am
- Location: Tulsa, OK