Wiki Home

_ Exam 70-155 Study Group Log _1999/10/31

Namespace: VFP

Session Start: Sun Oct 31 10:05:26 1999

[10:06] *** NancyFolsom changes topic to 'CaseStudy1 and physical design'

[10:07] {Roi} Car: Date: 06/10/1999 10:47:49 - [Visual FoxPro in general] Install and configure VFP for developing distributed apps

[10:07] {NancyFolsom} Okay, we are scheduled to take the case study 1 from logical to physical design

[10:09] {NancyFolsom} One of the conceptual design parameters is that the client wants to access the functions via the Web.

[10:09] {NancyFolsom} What impact does that have on the physical design?

[10:10] {Evan Delay} We would have to run a server capable of running a webserver.

[10:10] {BarbaraPaltiel} We need to work out our libraries so that they can be called from the webserver (no visual components)

[10:10] {NancyFolsom} Good. I agree. Anybody else?

[10:11] {Evan Delay} Our physical design would need to be more 3-tier than monolithic.

[10:11] {CindyWinegarden} Be careful about retrieving too much data

[10:11] {Roi} Performance could decrease simply because we disconnecting ourselves from the data. dial-up opposed to fast lan / wan.

[10:11] {CarlKarsten} I think we kinda skipped the conceptual design of this part. Exactly what functionally are we trying to achieve? The whole app of a few management tasks?

[10:11] {NancyFolsom} Let's say the whole app, Carl.

[10:11] {BarbaraPaltiel} Performance always decreases when talking web vs direct links.

[10:12] {BarbaraPaltiel} Carl, the spec does say that there will be ONE data set linked to the outlying stores by web interface

[10:12] {NancyFolsom} Right so, if the criteria was speed, then what could we do to have both speed and web access?

[10:12] {CindyWinegarden} There may be problems with synchronization unless the boss just d/l's report data

[10:13] {Roi} Does COM vs. DCOM impact performance?

[10:13] {BarbaraPaltiel} No synchronization problems with only one data set.

[10:13] {NancyFolsom} What are some examples of some physical components we would need?

[10:13] {Evan Delay} Roi, I don't think you can use COM across the web.

[10:13] {NancyFolsom} Roi, probably just by virtue of it being "distributed"

[10:13] {Roi} DCOM is meant to push processing over to another server to increase performance.

[10:13] {TerryCarroll} Would this be a good example of a hybrid solution VFP front end in 3 tier design?

[10:14] {BarbaraPaltiel} Fast connection (in spec),

[10:14] {NancyFolsom} Terry, probably.

[10:14] {NancyFolsom} BP-yep.

[10:14] {BarbaraPaltiel} Evan, you can use COM with WestWind.

[10:14] {Roi} Evan: Terry: Yes. We could assum VFP for portions of the front-end.

[10:14] {CarlKarsten} The webserver could call dcom components if it got to busy. I don't think there is enough traffic here to warrant that.

[10:14] {NancyFolsom} But what about when the boss is on a road show, and maybe only has access thru dial=up?

[10:14] {Evan Delay} BP, Roi... I eat my words.

[10:15] {BarbaraPaltiel} Dialup meaning through Earthlink or other ISP?

[10:15] {NancyFolsom} Right.

[10:15] {NancyFolsom} Via modem so, maybe, 49K real speed max.

[10:16] {Roi} Carl: So we could say DCOM would increase scalablitly but not much in the way of performance.

[10:16] {BarryMerritt} I would assume 26.4k max speed

[10:16] {CarlKarsten} I think a VPN is worth considering to achieve the security we are looking for.

[10:16] {BarbaraPaltiel} It doesn't matter the back end if you use WW or similar. You only have to be concerned about browser specifics, ant they're minimal at the design end

[10:16] {NancyFolsom} Would it be a good idea to identify minimum functionality for the boss being on the road, and make sure that is handled in separate components.

[10:16] {Evan Delay} So for Physical Design we are just applying specific hardware and software to the logical design.

[10:16] {NancyFolsom} Barry, probably so.

[10:16] {Evan Delay} Our tables now must decided to be SQL server, VFP... etc...

[10:17] {BarbaraPaltiel} Nancy, yes - what he wants on the road is NOW a subset of the full program. That may change

[10:17] {NancyFolsom} Alright, let's start naming modules...

[10:17] {NancyFolsom} For example, Remote_login?

[10:18] {BarbaraPaltiel} I'd rather see a list of modules for remote, secondary store and primary store. Then we combine where appropriate.

[10:19] {NancyFolsom} Okay, let's take the primary store, and see if we can list the components we need.

[10:20] {BarbaraPaltiel} Let's start with the basic, full program: Login, user security levels, table maintenance (reindex, pack, etc.)

[10:20] {Evan Delay} I am not sure what we mean by "componment" in this case.

[10:20] {CarlKarsten} I think the print issue needs to be investigated. that requirement may drive quite a bit of the design.

[10:20] {NancyFolsom} Um, I think of it as a unit of work.

[10:20] {BarbaraPaltiel} Data entry for Books, authors, SKUs, invoice

[10:20] {NancyFolsom} Right, Print is a component.

[10:21] {NancyFolsom} Let's see: retail functions (sell, returns, etc)

[10:21] {BarbaraPaltiel} Carl, that's data OUTPUT. Could you make us a list of places needed?

[10:21] {NancyFolsom} Inventory functions: order books, receive books, ship books, b/o books.

[10:22] {BarryMerritt} AR functions

[10:22] {BarbaraPaltiel} I think we've backed ourselves around to the logical design which we didn't finish on Friday.

[10:22] {NancyFolsom} An aside: please don't feel too shy about joining in, even if you're not sure...We're def. all in this together.

[10:22] {CarlKarsten} II was referring to the "Exact-position printing", which I am not sure how to implement remotely.

[10:23] {NancyFolsom} BP-Yes, since we're being necessarily cursory in this, I imagine we'll go back and add info to Conceptual and Logical...

[10:23] {Evan Delay} Carl, PDF.

[10:23] {Bonnie} Carl: would that need a remote implementation?

[10:23] {NancyFolsom} ...but of course, that's pretty much how real dev. works, anyway.

[10:23] {Roi} Carl: I think there are ways to handle that thorugh either a browser or a VFP / VB frontend.

[10:23] {BarbaraPaltiel} Bonnie, yes. POS is required at the other stores, and that means exact position printing on invoices, etc.

[10:24] {Bonnie} BP: OK, I was thinking for the boss on the road. Sorry, back on track now {g}

[10:24] {CindyWinegarden} But each store will have the same printer.

[10:24] {NancyFolsom} Before we get to the details of each component, do you think we have the general ones listed?

[10:24] {Roi} Since the Logical design hasn't been completed. Perhaps we could just pick one aspect of it to work on.

[10:25] {NancyFolsom} We have login, security, retail, inventory, printing, reports

[10:25] {NancyFolsom} What else?

[10:25] {NancyFolsom} Probably synchronization.

[10:25] {TerryCarroll} Data connection

[10:25] {NancyFolsom} Yes,

[10:25] {BarryMerritt} It seems to me that you may not want to limit this to just a web based interface especially the remote stores.

[10:25] {BarbaraPaltiel} Why synchronization? I thought that was being eliminated deliberately

[10:25] {Roi} Nancy: Sychronization?

[10:26] {MikeAntonovich} All data is local

[10:26] {NancyFolsom} Yes, what if the main database in the main store is down?

[10:26] {NancyFolsom} The remote locations can't stop selling books.

[10:26] {BarbaraPaltiel} That's hardware - hot swap drives, etc.

[10:26] {Roi} Then it's down. That's an IT problem.

[10:26] {NancyFolsom} Barry, we aren't.

[10:27] {NancyFolsom} Barbara, I disagree, the software at the remote store *has* to be able to function if the main store is off-line.

[10:27] {BarryMerritt} It would be better to have servers in all the stores and sync the data.

[10:27] {BarbaraPaltiel} I see what you're saying, NF, but you need to talk to the owner about his plans for separate offline work.

[10:27] {CarlKarsten} All stores have to function... nothing special about remote stores.

[10:27] {BarryMerritt} Disk space is cheap. Bandwidth isn't

[10:27] {BarbaraPaltiel} Barry, that's what they're doing (badly) now.

[10:27] {NancyFolsom} Well, let's go with what we've got though.

[10:27] {Evan Delay} This is interesting. There seems to be a lot of debate in this transition from logical to physical design. It seems that with conceptual and logical design you agree on the "truth" but with physical design the field is really open.

[10:28] {NancyFolsom} Plus, you don't want a store to have to depend on a connection that might get bogged down.

[10:28] {MikeAntonovich} Store owner wants to to get rid of expense and complexity of maintinaing servers at other locations.

[10:28] {TerryCarroll} If Data is local and Sychronization is still used of what use is a web based design?

[10:28] {NancyFolsom} For ex. one spec is that the receipt must print immediately, correct?

[10:28] {Roi} Nancy: Barry: The owner has specifically requested Central Database. No data syncing and no data at remote locations. They have that now and it's problematic.

[10:28] {BarryMerritt} WAN links go down every once in a while

[10:28] {NancyFolsom} Terry, that's def. part of the issue.

[10:28] {CarlKarsten} Take the money, use a pen, give the customer a recipt.

[10:28] {NancyFolsom} What about using data replication?

[10:29] {BarryMerritt} They're using a mix of unix and dos now. Of course there are problems.

[10:29] {CarlKarsten} Sync up the data later.

[10:29] {Roi} I go to stores all the time and the computer is down. It's a fact of life in the 90's. Again it is an IT problem. Not a software problem.

[10:29] {NancyFolsom} Oh, goodie, we can use this to see how to set up an MTS thingie.

[10:29] {NancyFolsom} Roi, nope, won't wash.

[10:29] {NancyFolsom} C'mon we're better than those other folks who make modern life hell.

[10:29] {BarryMerritt} I design for downtime as well.

[10:30] {Roi} Why not. 2 servers. One dies, the other is brought on-line.

[10:30] {CarlKarsten} redundant microwave link

[10:30] {CindyWinegarden} Carl has an importan point - define ways to handle situations you can't cover (too expenisve) like use a pen.

[10:30] {NancyFolsom} No, you don't have to go to hardware solutions.

[10:30] {MikeAntonovich} Roi: Mirrored servers?

[10:30] {NancyFolsom} That's hardware, valid, but give me SOFTWARE solutions.

[10:30] {Evan Delay} Cindy, Roi... I like this. This is downtime planning, disaster recovery...

[10:30] {Roi} Mike: Something anything. I dont' care what.

[10:31] {Evan Delay} Of course this debate is always tempered by COST.

[10:31] {BarryMerritt} There are existing POS systems out there now such as Counterpoint that use multi site sync on a daily basis.

[10:31] {NancyFolsom} I wonder if the exam will have any questions based on cost?

[10:31] {NancyFolsom} I doubt it, for some reason.

[10:31] {CarlKarsten} I think the sample did

[10:31] {CindyWinegarden} I don't think a collectible store can afford 2 of everything for 24x7 uptime the way LandsEnd or LLBean can

[10:31] {Bonnie} Good question Nancy ... it's a real world issue

[10:31] {NancyFolsom} Barry, how would we do this?

[10:31] {BarbaraPaltiel} How about replicated data for all remote transactions (repl. on the remote end). Then batch updates if the link goes down

[10:32] {Roi} The conceptual design speaks of the owner NOT wanting to sync data.

[10:32] {NancyFolsom} Carl-interesting (about cost $)

[10:32] {NancyFolsom} Barbara-sounds good.

[10:32] {Bonnie} Barbara: I like that idea

[10:32] {NancyFolsom} What if the local data is local inventory?

[10:32] {BarbaraPaltiel} All you need is a store ID that goes into each record/table

[10:32] {CarlKarsten} The owner doesn't want the problems with syncing data

[10:32] {NancyFolsom} Then what if a customer wants to order a book from the main store's inventory?

[10:33] {CarlKarsten} Pick up the phone

[10:33] {TerryCarroll} Let face it the main server going down is the achillies hill of a client server solution.

[10:33] {NancyFolsom} You guys are giving up way before it's time to. Brainstorming is coming up with solutions, not second guessing them immediately.

[10:33] {BarbaraPaltiel} If the main server is down, the home store is dead anyway.. Even the phone won't give you an answer. Take the customer's phone number and CALL HIM BACK

[10:33] {BarryMerritt} Synchronizind the data is the best solution. It distributes the workload to several servers, It wouldn't shut down the whole system if the main store was down.

[10:34] {Roi} Right Terry. It happens. Ours has gone down. Our WAN has gone done. I broken a lan cable and brought the whole down myself ;)

[10:34] {NancyFolsom} Besides, we're supposed to be learning things like MTS, right?

[10:34] {MikeAntonovich} Mirror two servers, preferrably in different buildings, but local to the store owner.

[10:34] {CarlKarsten} It is also worth considering "the store comes to a halt until the problems are resolved". in one way, very cost effective.

[10:34] {NancyFolsom} Yes, we've got that on the table.

[10:34] {NancyFolsom} How would you set up/design physcial components to minimize synchronization needs?

[10:35] {BarryMerritt} I would convince the client to do a more distributed scheme using SQL servers.

[10:35] {NancyFolsom} For example, could the business rules say: if I lose my connection to the main store, this is what I do?

[10:35] {Evan Delay} Two redundant lines from remote stores.

[10:35] {NancyFolsom} hardware.

[10:36] {NancyFolsom} software...VFP...context of the exam.

[10:36] {Evan Delay} Nancy... I guess the business rules should encompass that.

[10:36] {Bonnie} I think you need to lay out the pros and cons of several methods and see what the owner wants to do, how he wants to handle it ... yeah, business rules.

[10:36] {BarryMerritt} I'm telling you, redundant WAN links cost $. Its not worth it in a real world situation.

[10:36] {CarlKarsten} How about a fall back system that is local to the store, and if it is used then you get a synchronization headache later?

[10:36] {CindyWinegarden} I like Barbara's idea of keeping a local copy of everything for backup

[10:37] {NancyFolsom} Carl, yeah, I think that's similar to what BP and I are saying.

[10:37] {Roi} Barry: Good point $2000 a month for a T1.

[10:37] {NancyFolsom} HARDWARE!

[10:37] {CarlKarsten} Nancy: physcial

[10:38] {CindyWinegarden} And Barbara's idea is software so we can see the difference between hardware and software solutions.

[10:38] {NancyFolsom} The first item: assess the potential impact of the LD on perf. maintainablity, extensibility, and availability.

[10:38] {NancyFolsom} The exam is NOT gonna test us on T1 links.

[10:38] {BarryMerritt} You always should plan for some offline processing. Its necessary.

[10:39] {NancyFolsom} I think we're seeing how the logical design and physical design are interrelated.

[10:39] {TerryCarroll} MS wants us to focus on n-tier client server solutions. Hardware integrity is an other issue.

[10:39] {NancyFolsom} THey might ask a question saying which solution is better to assure availiability...

[10:40] {TerryCarroll} There is no doubt that availiablity is a trade off for data and business rule centralization

[10:41] {BarryMerritt} We should assume that the data is distributed and there will be some synchronization between the servers. Also VFP 6 has offline views.

[10:41] {CarlKarsten} I think that "distributed application" is refering to "splitting the app up across local machines"

[10:42] {Roi} Availablitly. The system will be used heavily during the day. It has to be available then. There seems to be plenty of time in odd hours for maintence / downtime/ etc. Problem: he wants to put kiosks in malls across the country. That means the DAY just got longer.

[10:42] {BarbaraPaltiel} Carl, no it can be split around the world if required.

[10:42] {NancyFolsom} Roi, good point.

[10:43] {CarlKarsten} It could, but thats not really the gist of the "D" in DCOM.

[10:43] {Evan Delay} One impact of our logical design might be really poor performance.

[10:44] {Evan Delay} We might have to make compromises to make it speed enough.

[10:44] {TerryCarroll} How is the issue of availibity handled in a typical Remote SQL impelmentation?

[10:44] {Roi} Yes Evan. Centralizing the data will have a mjor impact on performance.

[10:44] {Roi} Terry: What do you mean.

[10:45] {JCrescencioFlores} Carl: you mean DCOM as technology?

[10:45] {NancyFolsom} So, then decentralizing local data will help some.

[10:45] {Evan Delay} Another point, increasing the availablity of the app might decrease maintainabiliy

[10:45] {Roi} Nancy: But the owner doesn't it want it decentralized?

[10:46] {TerryCarroll} Roi SQL is a widely used product what happens in the sever goes down? Every been in a bank when the sever goes down?

[10:46] {NancyFolsom} Roi, right. If this was a real project we'd go to the owner and say: if it's completely centralized...this is what you have to do to ensure availability.

[10:46] {CarlKarsten} JC DCOM as in Distributed C.O.M.

[10:46] {JCrescencioFlores} Terry: mirror servers?

[10:47] {NancyFolsom} JCrescencio-I'm trying to keep the discussion off of hardware, and more on exam-related issues.

[10:47] {JCrescencioFlores} Carl: I don't follow what you mentioned about only local machines.

[10:47] {BarryMerritt} Any compenent of the hardware could fail on a central system. Its not the best scenario

[10:47] {NancyFolsom} Let me put it this way, if we totally finish solutions w/i the scope of the exam then we can talk about hardware.

[10:47] {CindyWinegarden} Do we need to convince the owner that total centralization with mirrored servers is too expensive and that he needs to decentralize enven though he doesn't want to

[10:47] {NancyFolsom} Evan, how so?

[10:48] {NancyFolsom} Yes, let's pretend we have, so we can move on with this. :)

[10:48] {Evan Delay} Nancy if the app is distributed to each store, then fewer variable to knock out the connection to the database. Harder to maintain though.

[10:48] {NancyFolsom} Okay, what would you do to counteract that?

[10:49] {CarlKarsten} JC: DCOM is meant to distribute the load across multiple machines, not to achieve connectivity to remote locations.

[10:49] {NancyFolsom} Note: data can be distributed (local data local, rollup data centralized)...

[10:49] {Evan Delay} I have no solution but I my point is that there is no physical design. Everything is a trade off.

[10:49] {NancyFolsom} Evan, we could design like a distributed LAN app...

[10:49] {Evan Delay} I mean "no perfect physical design"

[10:49] {NancyFolsom} On start up, it goes out to the host to see if there is an update availablity.

[10:49] {NancyFolsom} If not, then it runs what it has.

[10:50] {NancyFolsom} So, we need an update application component, too.

[10:50] {JCrescencioFlores} Carl: I understand. But then you have protocols to do DCOM over.

[10:50] {BarryMerritt} Thats the best solution Nancy, Its what MS has in mind

[10:51] {NancyFolsom} So, then we have local data local and perhaps sychronized on an opportunistic basis, with regular rollup transmissions to the main office?

[10:51] {NancyFolsom} Plus a local app that checks for updates...

[10:51] {NancyFolsom} Should be pretty darned fast locally.

[10:52] {CarlKarsten} How are we going to do this via a web browser?

[10:52] {BarbaraPaltiel} But didn't the spec want instant updates at the central location for managers/owner?

[10:52] {NancyFolsom} Barbara-That's what I mean by opportunistic.

[10:52] {NancyFolsom} If the opportunity is there, fine, if not, well, changes would have to queue.

[10:52] {TerryCarroll} Carl good point what do we tell the owner regarding a web solution?

[10:53] {NancyFolsom} Terry, we haven't said anything against a web solution yet, have we?

[10:53] {NancyFolsom} So far, we are naming essential components, but we haven't really said anyting about UI, yet.

[10:53] {CarlKarsten} Are we putting a web server in each store?

[10:53] {NancyFolsom} In fact, I don't know where *that* comes into Physical Design at all.

[10:54] {NancyFolsom} Do we need to?

[10:54] {Roi} Um.. Web browser is implementation. It's not really part of the physical design. We need to determine what and how many tiers, and what goes where. Correct?

[10:54] {TerryCarroll} Nancy No I jsut don't see how local data would would give us much leverage in a web based application?

[10:54] {NancyFolsom} Why would we just do that in the main store.

[10:54] {BarryMerritt} Wouldn't offline views be part of this scenario as well ?

[10:54] {NancyFolsom} Terry, the point is that as local transactions are made, couldn't we send updates to the main database?

[10:55] {NancyFolsom} local transaction is fast, home office is updated, if the WAN is down, no problem.

[10:55] {BarbaraPaltiel} Terry, it does give us leverage because the data wouldn't have to travel over phone lines.

[10:55] {JCrescencioFlores} Disconnected ADO recordsets?

[10:55] {TerryCarroll} Nancy yes that would work!

[10:55] {NancyFolsom} Roi, yes I agree.

[10:55] {CarlKarsten} Where do thes tracactions get queued?

[10:56] {NancyFolsom} Well, son {s} that's the 65,000 dollar (mts) question.

[10:56] {BarbaraPaltiel} Sounds like a separate app to me - with a timer that sweeps for new info every n seconds/minutes

[10:56] {JCrescencioFlores} A coworker (Bob Tracy, UT member) built such a solution with MSMQ.

[10:56] {TerryCarroll} Carl Isn't there a MS queuing tool.

[10:56] {Roi} This looks like it's gonna have to be a 3-tier app. The UI is going to run locally at each desktop. The Business objects are going to need to be implented as COM or DCOM (probably COM) to give flexiblity to any front-end. The Data tier will most likely be SQL but could be VFP tables and exists on a central server at the Main Store.

[10:56] {CarlKarsten} Are we putting a mts server in each store?

[10:56] {JCrescencioFlores} It doesn't matter wether the server or WAN are up or not.

[10:57] {CarlKarsten} Roi, good

[10:57] {NancyFolsom} I think MSMQ is a good point, JCF

[10:57] {NancyFolsom} Roi, yes.

[10:57] {Bonnie} JC: MSMQ sounds good to me too

[10:58] {NancyFolsom} MSMQ is a topic in the Dev. Env. sections which we are discussing Tues.

[10:58] {Roi} Problem: Performance. It's going to get a lttle slower (but not much if implemented correctly).

[10:58] {CarlKarsten} JC, so what does the client and remote store need in the way of mts components?

[10:58] {MikeAntonovich} Roi: you could then use VFP forms directly, ASP pages across the web or active documents to access the middle tier (when we get to the physical design of the interface)

[10:59] {Roi} Maintainalbiblty: By placing the business objects in COM servers, it should be pretty mainteance friendly.

[10:59] {NancyFolsom} we're about to start our second hour. I think we can probably start discussing what properties and methods we'll need in the components. Let's take login first.

[10:59] {NancyFolsom} Or do we need to stay here for a bit?

[10:59] {JCrescencioFlores} Carl: The client only needs to know where to get the COM objects, the server runs MTS host.

[11:00] {Roi} Mike: You could yes. You could use any front-end. this app could be mixture of different ones in the end.

[11:00] {NancyFolsom} JCF: so the outlying stores/kiosks will not need MTS servers?

[11:00] {MikeAntonovich} Roi: Exactly my point.

[11:00] {JCrescencioFlores} Nanbcy: No. Are we talking with or without MSMQ?

[11:01] {Evan Delay} Roi, of course that would lower maintainability

[11:01] {NancyFolsom} JCF: I think we'll get to MSMQ on Tuesday. I sure know I need to read up on it.

[11:01] {Roi} Mike: Yes. I think that improves the extensibilty as well.

[11:01] {NancyFolsom} Okay then, let's take the login and security components: properties and methods?

[11:01] {Roi} Evan: Not in the middle tier. Just in the front-end right?

[11:02] {Evan Delay} Roi, yup

[11:02] {BarryMerritt} Nancy the n-tier design of this scenario is a pretty big topic. We have at least 3 UIs already.

[11:02] {Evan Delay} login.username

[11:02] {NancyFolsom} Barry, I agree. And each may have a subset.

[11:02] {Evan Delay} login.securityclass

[11:02] {MikeAntonovich} A middle tier com object should validate the login, not the front end

[11:02] {Roi} What do they mean by COMPONENTS?

[11:02] {BarbaraPaltiel} Encryption for passwords - part of security class?

[11:02] {CarlKarsten} Check the "security check box" in Visual Fox Express :)

[11:03] {NancyFolsom} Do we need more than one login class, depending on whether we are loging in the remote database or via web?

[11:03] {JCrescencioFlores} Carl: I'll show up on Tuesday, and will get with Bob about MSMQ.

[11:03] {NancyFolsom} Carl-LOL

[11:03] {NancyFolsom} BP-I think so.

[11:03] {NancyFolsom} Roi-Units of Work.

[11:03] {CarlKarsten} more than one: no. no need to make it more complicated.

[11:03] {Evan Delay} Encryption sounds necesary. For login passwords and other data.

[11:04] {MikeAntonovich} Nancy: you should be able to get by with a single login class if it sits on the middle tier.

[11:04] {NancyFolsom} Carl, so loginning in and security will be the same no matter from where it's happening.

[11:04] {CarlKarsten} Nancy, yes.

[11:04] {BarryMerritt} First we neet to look at where the password user info is stored

[11:04] {Roi} Nancy: Design VisualFoxPro "units of work" to access data from a Database.

[11:04] {NancyFolsom} Okay. (I tend to be a splitter)

[11:04] {NancyFolsom} And how do you add new users?

[11:04] {NancyFolsom} Or remove users?

[11:04] {NancyFolsom} Or change security settings?

[11:05] {Evan Delay} login.adduser("edelay")

[11:05] {CindyWinegarden} Module that only the boss has permissions for}

[11:05] {NancyFolsom} I wonder...what if each store is a franchise, and each has it's own password routine.

[11:05] {MikeAntonovich} Maintenance options are 'forms' available from the local (owner) site.

[11:05] {NancyFolsom} For example, one of the stores is unix based...They may need a different *something-or-other* than the Windows stores.

[11:05] {NancyFolsom} Can we make use of the OS userpassword/names?

[11:05] {CarlKarsten} about an hour ago, you said the whole app would be web enabled... so that means none of it will not be.

[11:06] {CarlKarsten} OS usernames:no. web tv.

[11:06] {CindyWinegarden} We could use the OS.

[11:06] {NancyFolsom} Carl? huh?

[11:06] {Roi} Nancy: There's a Unix system?

[11:06] {NancyFolsom} Carl: that "huh" is for both your last two statements {s}

[11:06] {NancyFolsom} Roi, yes.

[11:06] {BarbaraPaltiel} Don't forget kiosk access - no login here or maybe a customer info login

[11:06] {BarryMerritt} NT security would be ok in this instance if set up right in the groups

[11:06] {Evan Delay} Two routes (maybe more). Application level security, OS security or combine them.

[11:07] {Evan Delay} Backend database security (SQL Server)

[11:07] {Roi} Nancy: sorry I found it.

[11:07] {BarryMerritt} combined for ease of use and maintenance

[11:07] {Bonnie} Barbara: there'd still be login from a kiosk .. why wouldn't there be?

[11:07] {NancyFolsom} Roi, no _I'm_ sorry...that there is a unix store! ;-)

[11:08] {CindyWinegarden} The users won't like logging in 4 places, but what if Joe Clerk is loggend in and Joe Boss needs to input PW to override price?

[11:08] {NancyFolsom} Barbara-good point.

[11:08] {NancyFolsom} Bonnie-I think the kiosk will be used by customers, right?

[11:08] {NancyFolsom} Customers ordering their own books, maybe? That's what I assumed but the use of the word.

[11:08] {CarlKarsten} I would think that some functions of the app could be "central office" functions, that would not be available remotely. But if all functionally is available everywhere, even on the road, then we can't assume that the web browser is secure.

[11:09] {Bonnie} Nancy ... ok, sorry I misinterpreted ..

[11:09] {BarryMerritt} NT security would work at the Kiosks as well

[11:09] {NancyFolsom} Cindy. Excellent point. :=(

[11:09] {Roi} I think the kiosk's are manned by a store personell. Like the Piercing pagoda.

[11:09] {NancyFolsom} Bonnie-You may have intepreted it right. I don't know the answer.

[11:09] {BarbaraPaltiel} Roi, not always. We have a lot of kiosks here that are unattended

[11:09] {NancyFolsom} Okay, so it's just another retail outlet.

[11:09] {Bonnie} Nancy, well, regardless, there's still need to be some kind of login from kiosks.

[11:10] {Roi} Carl: The boss does need a lot of functionality on the road. He want's it to be just like at his desk.

[11:10] {NancyFolsom} Barbara-how do those kiosks work?

[11:10] {NancyFolsom} Roi, yeah, that's gonna be an interesting challenge.

[11:10] {CindyWinegarden} Ooh - never seen an unattended kiosk. Wouldn't have thought of it.

[11:10] {BarbaraPaltiel} Keyboard and screen. You start with a menu and go from there. If no action after n seconds it goes back to the main menu

[11:10] {Roi} Barbara: Right, understood. It mentions samll stores or kiosks. I took that to mean manned.

[11:10] {CindyWinegarden} Barbara- like ordering online?

[11:10] {NancyFolsom} I like the idea of considering the kiosks as unattended since it will have an interesting impact on the physical design.

[11:11] {MikeAntonovich} If it is a web interface, the boss could 'login' to a different subweb than the kiosks do to give him more features.

[11:11] {NancyFolsom} Barbara-do you order products from them?

[11:11] {BarbaraPaltiel} Ciindy, yes. Although usually just information. Basically, though, it's an internet connection. Online purchasing.

[11:11] {Roi} I would think they would keep a small inventory at the kiosk. Hey, Where's David? He knows the answere.

[11:11] {NancyFolsom} Whoa! Way cool.

[11:11] {CarlKarsten} Some functions of the app could require a login, the rest is public.

[11:12] {MikeAntonovich} Web sites can handle that easily

[11:12] {Bonnie} Good point Carl

[11:12] {NancyFolsom} Well, what if it's a returning customer? It would be nice to keep that info.

[11:12] {Roi} Um. which topic are we on? I'm lost.

[11:13] {MikeAntonovich} Store customer info in a separate table in the database

[11:13] {CindyWinegarden} Unattended kiosks is really just like online ordering but there might be some local software.

[11:13] {Evan Delay} AFAIk Design the Properties and Methods of Components

[11:13] {Bonnie} We're getting side-tracked as usual Roi

[11:13] {CarlKarsten} Roi: Source Code Version Control

[11:13] {NancyFolsom} Well, we started to talk about propertys and methods of the login and security modules

[11:14] {NancyFolsom} Which brought us to a point in the physcial design we didn't consider

[11:14] {NancyFolsom} So, now we are addressing that.

[11:14] {Roi} Ok.

[11:14] {NancyFolsom} We can go ahead and ignore kiosks. And for now just consider the retail and home office stores.

[11:14] {NancyFolsom} So, back to the login and security components...

[11:14] {CindyWinegarden} Or a kiosk that's really just like a store.

[11:15] {NancyFolsom} We need a user entity, right?

[11:15] {NancyFolsom} With what properties? I assume this is what is meant...

[11:15] {Evan Delay} Yup

[11:15] {Evan Delay}

[11:15] {Evan Delay} user.securityclass

[11:15] {NancyFolsom} activeinactive

[11:15] {Roi} So you have a Login COM server. Any front end can access it.

[11:16] {Evan Delay} user.password

[11:16] {NancyFolsom} So the login class will COLLABORATE with the security class?

[11:16] {NancyFolsom} Roi, okay.

[11:16] {Roi} Evan: why propertys. Why not just methods.

[11:16] {CindyWinegarden} Maybe the user's pw translates into a group pw for the sQL server which the user won't know

[11:16] {Evan Delay} Roi, good question.

[11:16] {MikeAntonovich} On a web connection kiosk, the user is annonymous with no password and has limited rights so it still fits the property requirements.

[11:18] {Evan Delay} Does anyone have an answer to Roi's question?

[11:18] {Roi} The Logoin compontent can just have a Logon("UserName", "Password") method. The fornt-end grabs the that info passes it oLogon. oLogo returns .T. if it worked, .F. if it failed.

[11:18] {NancyFolsom} Why NOT properties?

[11:18] {BarbaraPaltiel} You'll need to access these properties later in the program.

[11:18] {NancyFolsom} BP, right.

[11:18] {JCrescencioFlores} stateless components..

[11:18] {NancyFolsom} When you go to a new module or component you'd just pass the USER object around.

[11:19] {Evan Delay} Ahhh.. this goes back to the stateful/stateless question.

[11:19] {BarbaraPaltiel} It can be part of an application object or separate - I personally prefer separate.

[11:19] {NancyFolsom} How so?

[11:19] {NancyFolsom} Yes, I prefer separate.

[11:19] {BarbaraPaltiel} Evan - good point. For stateless models I use a session object and a table.

[11:19] {NancyFolsom} That way you can login as a nother user with out going out of the program.

[11:21] {NancyFolsom} But using a user object doesn't need to depend on the underlying state of the user table

[11:21] {BarbaraPaltiel} Nancy, it does if you can't maintain the state.

[11:21] {Roi} I would think that the properties of COM servers should be used more internal working of the object. All actions that need acomplished should be through methods that return the value.

[11:22] {NancyFolsom} BP, how would I be depending on the state of the table?

[11:23] {NancyFolsom} Roi, yes, but that's a general rule of thumb for all class design.

[11:23] {NancyFolsom} But, good point.

[11:24] {BarbaraPaltiel} Nancy, I may be misinterpreting you. I meant that in a stateless format your user table isn't necessarily on the record you last used.

[11:24] {NancyFolsom} BP, right.

[11:24] {Roi} Ok, so we know how to make a oLogon.method. What would be a property of the Logon class. Anyone?

[11:24] {NancyFolsom} The user object would be stateless cuz we'd gather the data once then pass the object around.

[11:24] {Roi} Anyone?

[11:25] {NancyFolsom} Success/failure?

[11:25] {NancyFolsom} accesslevel?

[11:25] {NancyFolsom} groupid?

[11:25] {JCrescencioFlores} Roi: the connection string maybe?

[11:25] {Roi} How about. nAttempts.

[11:25] {NancyFolsom} active/inactive

[11:25] {Evan Delay} But that is stateful.

[11:25] {NancyFolsom} What is stateful?

[11:25] {Evan Delay} active/inactive

[11:25] {TerryCarroll} Roi StoreIdof User

[11:25] {Roi} The COM keeps track of the attempts to logon. It informs the UI that it has exceeded some value.

[11:26] {NancyFolsom} I meant active user of the system or an inactive (i.e. no-longer-employeed)

[11:26] {NancyFolsom} Roi, yes. It could have the rule for what to do if login is unsuccessful in x attempts, too.

[11:26] {Roi} Evan: True, but we discussed that as being irrelevant a couple meeting ago. I'm not sure why but....

[11:27] {Roi} Nancy: exaclty it enforces the business rule.

[11:27] {NancyFolsom} But, what I do is when a login is successful, I would flip the "active" flag in the user table.

[11:27] {CindyWinegarden} Here active means on-line or in system?

[11:27] {NancyFolsom} Yes, I think we don't need to worry quite as much about stateful/stateless as we were before.

[11:27] {NancyFolsom} Cindy, that was my poor choice of words, I was using it for both.

[11:28] {NancyFolsom} And I don't think the login class needs a property for whether the user is a current user of the systme or not.

[11:28] {CindyWinegarden} You may want to keep a last-login date for each user. also, when logs in , set current user to his id for tracking purposes

[11:29] {NancyFolsom} Okay, give some examples for the security component.

[11:29] {Roi} I think things like Accesslevel/active/inactive/storeid are more values that would be more values that the security class would look up and use to validate the logon.

[11:29] {NancyFolsom} What I am envisioning is that the login object returns (or is) a user object that the app can use.

[11:30] {NancyFolsom} That user object could be initialized with al lthe user preferences...

[11:30] {NancyFolsom} Last used window, for example.

[11:31] {Roi} Nancy: you mean in the UI?

[11:31] {CindyWinegarden} And the object has the current user which is written onto each record as who last modified it

[11:32] {NancyFolsom} Roi, or data.

[11:33] {NancyFolsom} For example, if a user comes in to the app (esp. the boss), it would be nice to put him back in the screen he last used on the last customer.

[11:33] {BarryMerritt} audit trails may be necessary in a POS system. Login Logout times should be recorded.

[11:33] {NancyFolsom} Okay.

[11:33] {NancyFolsom} But let's go to a different component now, we only have a half hour more.

[11:34] {NancyFolsom} How about the printing/reports component?

[11:35] {CarlKarsten} Here is my idea: printing is done "by the server", to a "printer on the wan". breaks the web enabled model though

[11:35] {MikeAntonovich} Properties would include report to print, range of values (dates, ISBNs etc.)

[11:35] {CindyWinegarden} Need different security to print paychecks that to print receipts

[11:35] {CarlKarsten} The workstation and the printer just happen to be near each other.

[11:36] {NancyFolsom} Keep going.

[11:36] {CarlKarsten} The print server could be running on the workstation, then there would be the physical connection between the two.

[11:37] {NancyFolsom} So, name me some methods, Carl.

[11:37] {CarlKarsten} this.print()

[11:37] {Roi} The info that is printed on a reciept. Where does it come from. Is it stored locally at the Front-end (somehow validated through the middle).

[11:37] {NancyFolsom} Do we need a class for PrintReceipts, PrintPaychecks, PrintReports?

[11:38] {NancyFolsom} Output classes, so we can swap types of output?

[11:38] {Evan Delay} ... or would this be part of the Receipts object?

[11:38] {NancyFolsom} So, we'd have an entity ('receipts') with a print() method?

[11:38] {BarbaraPaltiel} Evan, that's a judgment call. Personally I like to see all printing methods together

[11:39] {BarryMerritt} You would be printing to a locally assigned printer in most cases.

[11:39] {NancyFolsom} What if the print()method in the receipt object calls the printserver comp.?

[11:39] {CarlKarsten} How about "The Receipts object would contain a Print object"?

[11:39] {AlAllison} How about the objects all have a DoPrint() to customize at the instance level

[11:40] {NancyFolsom} Makes sense.

[11:40] {BarbaraPaltiel} That's good - DoPrint()

[11:40] {CindyWinegarden} Paychecks won't be printed at every location. Also, they will probably be printer on another printer

[11:40] {Roi} I would think you would have a oReport COM server. It would have some methods that allow it to grave some info from the back-end and pass it to the front-end. The front-end (UI) would be repsonible for the acutal printing (what printer, formatting, etc...)

[11:40] {BarbaraPaltiel} Cindy, that's a security issue as well as a printing issue.

[11:40] {NancyFolsom} so, another entity? "paycheck" with a print() method that calls the print server.

[11:41] {NancyFolsom} Yeah, BP, I see that too.

[11:41] {Roi} Remeber. the middle layer can't neccesarily print anything. All it does is move information between the front and back.

[11:42] {CarlKarsten} Roi, good point

[11:42] {BarryMerritt} I think the main office would be printing checks. It may not have anything to do with this APP

[11:42] {AlAllison} e.g. I have an oProcess object with a DoProcess(param) method, if it is your param, do it

[11:42] {NancyFolsom} Now, components can have pieces of more than one layer.

[11:43] {BarryMerritt} this is a POS system not a full accounting system.

[11:43] {MikeAntonovich} Barry, Checks and receipts must feature exact-position printing at all store locations

[11:43] {NancyFolsom} So, the printserver will have perhaps a coupld of ui classes, business rule classes, and some data classes.

[11:43] {BarbaraPaltiel} Wonder if David needs to connect this data to a 'real' accounting system?

[11:44] {NancyFolsom} Barbara...that's an interesting question.

[11:44] {NancyFolsom} He did hint that what he wrote up is only a small piece of what he has to do.

[11:44] {CindyWinegarden} Barbara - It definitely should have that capability

[11:44] {Roi} Nancy: Probably. The UI components will be responible for determining where, when and how to print.

[11:44] {NancyFolsom} Hm. No, I disagree.

[11:45] {BarbaraPaltiel} We're working on an app that will be connected to different Acct. systems, depending on user. Similar exports, called with an application object

[11:45] {BarryMerritt} you simply create a report based on your print form size. Receipts have certain size, checks have another, and so on.

[11:45] {NancyFolsom} The ui componnt decides how to show the user their choices.

[11:45] {BarbaraPaltiel} = application object PROPERTY

[11:45] {Bonnie} Roi: I'd think that would be the middle tier that would determine that

[11:45] {NancyFolsom} BP that sounds complex.

[11:46] {BarryMerritt} exact position printing as far as I can see it.

[11:46] {NancyFolsom} No, the UI layer is the presentation layer.

[11:46] {NancyFolsom} Presentation to the user.

[11:46] {NancyFolsom} What printer to print to... what report to print... that doesn't sound like ui features.

[11:46] {Roi} Strictly POS: The user decides only if the sale is complete. They don't have control over what prints or if it prints.

[11:47] {CarlKarsten} Nancy, my "print server" is an OS level thing. what do you mean by " the printserver will have perhaps a couple of ui classes"

[11:47] {BarryMerritt} Let the OS handle the printers.

[11:47] {Roi} Other parts of the app would proably include ability in the UI to pick a printer, or a range of dates, etc...

[11:48] {Roi} Carl: I think Nancy meant "Print Entity" ;)

[11:48] {BarryMerritt} Thats exactly it Roi, except you get the list of printers from the OS

[11:48] {TerryCarroll} Should we consider a 'query method' in reporting to call middle tier to get data to the UI layer fro pysical printing.

[11:49] {NancyFolsom} Yeah, Carl, I probably misnamed it. The Print component.

[11:49] {BarbaraPaltiel} Terry: Do we SEND the query when we first call our print entitity? Or does it ASK for query parameters. I think the former.

[11:50] {NancyFolsom} but one thing to keep in mind...a component isn't necessarily all from one layer.

[11:50] {BarryMerritt} You may query to a cursor and print the data in the cursor terry

[11:50] {NancyFolsom} Or would the reportThisReport instantiate the correct dataobject?

[11:50] {CarlKarsten} I think we need to split the UI tier into two parts: screen/keyboard Interface, and printer Interface.

[11:50] {NancyFolsom} Okay. Input and output.

[11:51] {NancyFolsom} Sorry, that shoulda been a "?

[11:51] {NancyFolsom} 9 minutes left. Do you want to recap? We will be leaving the phsyical design on Tuesday.

[11:52] {NancyFolsom} Actually we still have to briefly discuss classlibraries design.

[11:52] {Roi} Nancy: Is that true? I thought compnents should cross layers. Business is business, Ui is Ui. They just talk to each other.

[11:52] {BarryMerritt} The printer interface is not that complex. You have a local table with a list of printers. Whatever printer you have installed in the OS is what you choose from.

[11:52] {Roi} Opps. Components should NOT cross layers?

[11:53] {CarlKarsten} Does "physical design" include what software we are running? web browsers, mts, sql...

[11:53] {NancyFolsom} No, I don't think that's necessarily tru. A component might have UI layer class, a Business layer class, anad a data class.

[11:53] {Evan Delay} Cark, I say yes.

[11:53] {NancyFolsom} Carl, MTS, IIS, MSMQ are in the next section.

[11:53] {Evan Delay} Nancy, Roi let's start on UT thread on this.

[11:54] {Roi} Good Evan. I still not clear on what a component is.

[11:55] {NancyFolsom} You guys will want to look at the last bullet in the section.

[11:55] {Evan Delay} Design ClassLibraries?. Considerations include Inheritance, Encapsulation, Containership, Delegation, and Polymorphism.

[11:56] {Evan Delay} So what is this one about... group classes into class libaries..

[11:56] {Roi} Real Quick: Inheritance: VB doesn't have. All you need to know. { g }

[11:56] {MikeAntonovich} I'm familiary with all the other terms, but what is Delegation?

[11:57] {Evan Delay} Class libraries are just logical groupings of classes.

[11:57] {NancyFolsom} We would probably want to have a basic user class that is subclased into power users, god users, and weenie users.

[11:57] {CindyWinegarden} Delegation: the quit button calls the quit method of the app object

[11:57] {MikeAntonovich} Ok. Thanks!

[11:57] {CindyWinegarden} GOD users?

[11:57] {AlAllison} like DoProcess

[11:57] {BarbaraPaltiel} Or the quit method of the form it's dropped on THEN the qm of the app object

[11:57] {NancyFolsom} Cindy, that would be notification, I think.

[11:57] {Evan Delay} The book.doprint calls the print object.

[11:57] {BarbaraPaltiel} Cindy BOSS = GOD

[11:58] {Roi} Mike: Delegation is a 1 object calling another object to do something. Example: A Close button click event has thisform.Release().

[11:58] {CarlKarsten} Delegation: the UI makes the Biz layer do the real work.

[11:58] {Roi} Carl: Good explanation.

[11:58] {NancyFolsom} Though, usually, it's the BOSS you want to give the least power to!

[11:58] {CindyWinegarden} And I thought she meant Power, Good, and Weenie

[11:58] {BarryMerritt} We might want to address offline views. there may be a question on the test such as in what situation would we use an offline view.

[11:58] {NancyFolsom} Notification = an object tells it's container something has changed.

[11:59] {Evan Delay} Encapsulation... only manipulate an object via its public interface.

[11:59] {Evan Delay} True?

[11:59] {NancyFolsom} Yes,

[11:59] {NancyFolsom} Like Roi said earlier... the properties of an object aren't accessed directly... but via a public method

[12:00] {Evan Delay} Polymorphism..... all objects have a "refresh" method.

[12:01] {Evan Delay} Great dicussion today.

Contributors: CindyWinegarden, NancyFolsom

See also: Exam70-155StudyGroupSummaries

( Topic last updated: 1999.11.13 11:56:10 PM )