Journal Entries, Week #12

Quick jump to: alio, beowulf, jamesmcd, jkdot, jsegars, lipinski, localguy, othello, rjmorgan, ryanaip, thewang, tjice, wrprice, swong.

----- ALIO -------------------------------------------------------------------------------------------

Status:

· Things are going well. There is a new “wander”, “browse”, and decisionbuy behavior that are going to be functional as soon as items and people have some attributes assigned to them
How were the new behaviors tested in the full system if there were no required attributes assigned? Just hard code them in if the factories aren’t ready yet. Make sure you test with the full system!

· I’m currently working with the UI group to add attributes to the form that appears when adding an item to a store.

· By next Friday the people and item factories will be updated to include attribute additions to the Entities.

What seems to be working –

· The examples for the Pocket PC are looking good. Hopefully soon we will move beyond a proof of concept and start exchanging data between the server and Pocket PC (good luck TJ and Theo).

· Communication is extremely good. People are making their needs known and the other groups are doing good work to accommodate.

What seems to not be working –

· Having to use multiple computers to run the project is cumbersome. Though it is a little late it would be cool to be able to run everything using less computing power.

Looking ahead

· Lots to do but nothing that seems to be insurmountable, just time consuming. So lots and lots of coding parties!! Good luck to everyone and see you in the lab.

Nice journal.

----- BEOWULF -----------------------------------------------------------------------------------

Status of Milestone

Gains Made: The UI group is on track for MS5. An additional toolbar button was added to the client so they are now able to add products and choose the location where the products are placed in the room. SW: There was a bug in here as of Friday: The location where the item was placed was not the same as where the item actually ended up. It looked like a position translation issue—be sure to check that the feature works for all store positions! Work is ongoing with the model group to dynamically make the add item panel so that all the possible attributes are listed (and the factories will need to be tweaked most likely). People are now moving to the correct doors. The remote client view now appears to be working (thank to Jim and others) so the next important step is to get a mockup of the PPC gui and get it working.
Obstacles: Sometimes it seems like doing the simplest things in c# are difficult because I don’t get what I’m looking for out of the documentation. For example, java has the forums on sun’s website java.sun.com that offer solutions to thousands of common little problems. I think devhood is trying to do this for c# but it is nowhere near as complete as the java forums.
Proposed Solutions: Hopefully as c# matures ONE place will become the standard forum to post these kind of things. Also, I’ve never been really happy with the c# documentation what Microsoft supplies because its sometimes difficult to lookup what you want. If anyone is interested, I put together a set of the c# documentation that mimics the java api. A sample of it can be found here http://www.owlnet.rice.edu/~beowulf/csharp/ . It’s only a subset of the documentation (first 6 namespaces) though because the full version is about 200mb. I’m trying to get the people at devhood (and other places) to host the full version.

Analysis of Development

What’s Working: It looks like the pocket pc goal is doable at this point (which is impressive because last week the general sentiment was that it might not be a reasonable goal). Impressive progress and many late nights (Dr. Wong included!) have made this possible.
Whats Not Working: There are still a huge number of small things in the simulator that make it very far from being ready to let a real customer use. Most of the startup is very finicky and liable to crash at any moment. We the developers know the delicate process of getting everything running but it is definitely not robust and smart enough to recover from bad user input. Nethub still throws a lot of uncaught exceptions.
Proposed Changes: In some sense, this is not really a priority. If we are able to give the demo (without letting Dr. Nyguen touch anything) then we should be in good shape. But I can just imagine him trying to do different things and exceptions will inevitably get thrown. Its not glamorous work, but its important to validate all user input and catch all exceptions if we are trying to make this actually usable. On the other hand maybe we just want to get as much out of this as we can in terms of an academic exercise, and not making an actual product.

Nice journal.

----- JAMESMCD ---------------------------------------------------------------------------------

Status of Milesone:

Gains Made: Most of my milestone has been implemented already. After a significant restructuring of how people should be transported into space (thanks for showing me the light Will), doors now contain pointers to the space they connect. When a person interacts with a door they are added directly into the receiving space rather than going through a receiving door. This was done for simplicity and because adding them in through the door added very few benefits.
Obstacles encountered: Indecision about what is needed by other groups. A large portion of my tasking is making sure the proper methods exist that allows a WebService application to get the seralizable objects that the UI group will require to draw the Pocket PC application. However it has taken quite a while to formalize a plan of attack. In the mean time I could sketch out a solution, but implementing anything concrete would have been a waste of time. The majority of this problem arose from all of our unfamiliarity with the Pocket PC environment and not knowing what was possible. Thanks to Will’s research and Theo and Dr. Wong’s independent applications a lot of progress has been made in knowing where to go for a solution.
Never underestimate the value of good proof-of-concept and demo code..
Solutions Proposed: Go back in time in order to get familiar with Pocket PCs before the very end of the semester. Since that is obviously not possible I think we should minimize the functionality of the Pocket PC application. Things like the number of items in a store, cost, quantity, don’t necessarily need to be displayed. If it ends up not being any more difficult to do this once the system that allows the displaying of people moving inside the space is in place, then we should go for it. If it adds a whole level of complexity, then it should be abandoned.

Analysis of Development Process:

What’s Working: Interaction between groups. It the lines separating the various groups have started getting blurry. – Often this means re-doing the groupings to adapt to a changing programming landscape, which we don’t need to do because of the short time involved. This has worked very well the last week to get things done. Many of the tasks being done involve much closer connections between different groups, particularly between the UI and Model group. In order to get one bit of functionality for the model, stuff must happen in the view, and vice versa.
What’s not: Final definition of project scope. Even though we only have a couple weeks left, what we’re going to call a “finished product” is still undefined. What will the Pocket PCs do? How robust will the normal application be? It seems like we are just hacking away trying to add additional functionality with out knowing what our goal should be.
Solutions: Leaders sit down and define exactly what has to happen to make this product “finished.” What issues that already exist need to be taken care of and what don’t? What new functionality needs to be added, and what doesn’t? Then we know exactly what has to happen in the next 2 weeks.

Nice journal.

----- JKDOT ----------------------------------------------------------------------------------------

Milestone:

Continuous work with Brian and Jeff on refining the functionality of the GUI. More work on client/server interaction and general information updating in the model.

Gains Made:

This week, I mostly worked with Brain on giving the UI the ability to add products dynamically (in the actual application window). We then made the changes update in the view. The next step is to pass the new product information (price, stock, etc.) to the model. As a group, we decided that users could add items from a pre-defined list. Even though this is not specifically what the customer wanted, it will be more realistic because we can have behaviors defined for the products in the list. Since there is not much time left, we really didn’t think we could pull off functionality that allowed users to add any item they wished (would not be standardized).
This capability requires dynamic assembly loading. Standardization is not an issue as all products would conform to their abstract definitions.

Obstacles encountered:

While working in the client code, we encountered exceptions that were not caught or handled very well. This came up mainly when the Net Hub failed because the client closed. It was also tedious to open a new server each time we wanted to test something with the client (client couldn’t open and function because the connection between the two was not set up). I guess it was mostly in the AR code.

Solutions proposed:

Better error checking/handling would help a lot. Things are fine now, but there are a lot of steps to remember to do so that the application doesn’t crash inadvertently. Also,

Development Process:

What seems to be working:

Communication seems to be working.
Application – it seems closer to being complete than it did when it was in pieces
Group interaction

What doesn’t seem to be working:

There’s not very much time left and it’s a little scary that we won’t finish.
Final documentation – where is it?

Proposal for change:

With the time crunch and the looming deadline, it will be very hard to pull something off cleanly unless we start putting everything together and doing some final testing. We shouldn’t leave that for the last minute.

Nice journal.

----- JSEGARS -------------------------------------------------------------------------------------

Gains Made

I spent this week testing and refining some aspects of the GUI. The IMallAdapter implemented in the last milestone has now been tested much more extensively and appears to work as expected. Many GUI updating functions that were shared between the server and the client have been moved to external files, to reduce code repetition, and I’ve changed the controls to only update when they’re clicked on. This isn’t the end desired behavior, but it better than the annoying constant refresh we used to have.

Obstacles

The main obstacle I encountered this week was trying to figure out an intelligent way to update our controls, rather than doing it on every timer tick. Many Windows controls support data binding, but the ListViews that we were using extensively do not. I’ve found an article discussing how to implement this functionality in VB and I’m going to spend some time converting the code into C#.

Development Process

What's Working

It appears that PocketPC development is coming along much better than I expected. I had some doubts about whether I thought there was enough time to get things running on a new platform, but it looks like we’ll be able to get something running.

What's Not Working / Change

A couple journals ago, many people talked about the need to determine what would and would not be accomplished by the end of the project. While this probably went on informally within the groups, it might be nice for each group to get something up about what they plan to get done and what they don’t see being feasible. At this stage, one group can’t waste time working on something to complement functionality that another group won’t be able to deliver in the end.

Nice journal.

----- LIPINSKI -------------------------------------------------------------------------------------

Milestone:

· Configuring the model and GUI to run in separate processes, communicating through the NetHub. (E.g., write controllers for them.) (100%)

· Make the factories run as an application used to launch stores. (50%)

· Figure out which new adapters are needed for the PocketPC and implement them (work the AR group on this). (80%)

· Implement MallClientAdapter if there’s time, but the PocketPC functionality is the priority. (0%)

Gains Made: Ryan and I did a lot of work on Wednesday. We retooled the factories and integrated them with the wizards. We also redid the interfaces to allow complete separation, as Theo requested. We still have to work on IEntityAdapter, because we’re not sure if that is completely up to what Theo suggested, but we will have that done shortly as well.

Obstacles Encountered:

· We ran into testing issues with the wizard setup, because we haven’t added a way for the mall to add people to itself.

Solutions Proposed:

We started making the mall autonomous in adding people to itself. It won’t help for specific testing, but it will be the functionality we require.
Don’t throw away the manual “Add Person” button. Just add an “Auto Add” capability.

Development Process

What’s Working: Finally shedding the test UI.

What’s not Working: TJ, I only see him in the lab 23 out of every 24 hours. He’s obviously not committing enough time to the project. Lack of pizza meetings, or general morale lifting events.
Come to class today (4/14/03)!

To Change: As the project is coming to a close there isn’t much I can say about the process, at least nothing that can possibly have any effect on the project. This week went really smoothly. It was beneficial to get people together and actually do coding. Then we could ask someone for advice, or what such and such did. It was a lot easier then just trying to code something, and realizing I have no clue what the UI is doing at that point. It was nice to grab TJ and yell at him. Maybe try and organized programming parties, with pizza etc. where we can all get together and actually program, not just talk like in class.

Nice journal.

----- LOCALGUY ---------------------------------------------------------------------------------

Milestone:

Gains Made:

I finished what little work was left undone on closing the various structures associated with Net Hub.
The AR group met several times and discussed possible ways of accessing the model via a pocketPC. After several failed solutions Theo found a really nice way of setting up a web service on an HTTP channel using remoting. This simplifies the process since it takes IIS out of the web service loop. J We informed the model group that we needed a list of all the functions that the UI group needs for the pocketPC.

Obstacles Encountered:

Our task to find away to connect pocket PC’s to the model was very complicated since the pocketPC’s cannot use remoting. It was hard to conceptualize what we needed to do to get the results that we wanted. Luckily, Theo came through and we think we have a pretty good solution to the problem.

Solutions Proposed:

Now that we know what needs to be done, we really need a few people from each group to get together and start implementing Theo’s solution.
Who is actually going to do this tasking? At the moment, the AR group has no posted taskings!

Development Process:

What seems to be working?

It seems like there is a good amount of communication between groups which is great because communication is becoming very key as the project nears an end. It’s great the we have .NET in symonds since we really need it to test our final product.

What seems to not be working?

Everyone seems to be losing motivation for the project as the school year winds down and preparation for finals begins. It’s also really nice outside.

Proposals for change:

It almost seems like the entire group needs a break from the project, so that we can return to it later with more enthusiasm. Since we cannot take a break and we’re not going to work on the project after this semester we just have to keep working when we can until we get to a stopping point.

How long does a break need to be? Perhaps just an hour frolicking in the sun is enough. Don’t underestimate the importance of such breaks.

Nice journal.

----- OTHELLO -----------------------------------------------------------------------------------

· Milestone Status:

o Gains: My milestone for the next couple of weeks is kind of general, to help the UI group and Model group work with the Web Services framework layer that we are going to support.

In the attempt to figure out how to implement a Web Services host, I researched and fooled around with Remoting via HTML/XML-SOAP. It turned out to be amazingly simple, once I figured it out. That’s the problem with most Microsoft frameworks that I’m feeling – it’s easy to reproduce once you figure it out, but it’s not very intuitive to finding out with nothing to start.

I’ve coded up a test server that’s a Windows GUI app, available in binaries, or the entire solution directory, in zip format. The binary .exe is at:

http://www.owlnet.rice.edu/~othello/comp410/binaries/RemotingWebService.exe

It requires the following DLL file, at:

http://www.owlnet.rice.edu/~othello/comp410/binaries/TextHolder.dll

Also, a number of test clients are available in the same binaries directory. There’s a Remoting test client (console app), that also requires the TextHolder.dll file, and there’s a Web Services test client, that doesn’t require the DLL, since it uses a WSDL generated proxy class. All of the aforementioned binaries / solutions are developed in VS .NET 2002.

More interestingly, I’ve also coded up a Pocket PC client, using VS .NET 2003 (“Everett”) Final Beta, and made the CAB files available online at:

http://www.owlnet.rice.edu/~othello/comp410/pocketpc-cabs/

The CAB file for the Pocket PCs distributed to the Comp410 class (well, everyone except for Will :-P) is at the following URL:

http://www.owlnet.rice.edu/~othello/comp410/pocketpc-cabs/PocketClient_PPC.ARM.CAB

I tested this out pretty extensively on my machine, and also using a client from my machine while hosting on Exciton (the reason why it’s interesting is that my apartment machines are on a NAT firewall so that we don’t have to pay extra for our hi-speed internet access). A screenshot for the server GUI while running on Exciton follows.

You run it by opening the app, picking a port, and hitting the “Start” button, simple as that. If all goes well, it disables the port entry field and start button, which is a sign that you are now serving up live. If nothing happens, there’s something invalid (your port is not a valid unsigned 16-bit integer, you don’t have permissions to start on that port, or its being used). After the server starts, the text box labeled “Exposed Text:” is now “live” on the net, and can be accessed via Web Services (or Remoting, if the client uses HTTP/XML-SOAP).

Here’s how it looks like from the Pocket PC side:

The most noticeable thing at first is the lag when you first make the call to the Web Service. This might be a one-time web service initialization cost, or maybe the cost of JIT-compiling the Web Service proxy class, or loading the dynamic libraries necessary to execute the .NET Compact Framework Web Service library calls. (SW: Yes to all of these.) It’s a considerable lag, possibly 1-2 seconds even for this simple GUI.

The Pocket PC GUI is the most sophisticated client out of the all the provided clients, since this was the case that we were concerned about. However, once the first call goes through, successive calls after that are much faster. The GUI also has a configurable polling timer, so you can set how fast you want to take a snapshot of the textbox. The time necessary to pass this is dependent on the RTT (network Round Trip Time) between the client and the server, and also on the amount of data being transmitted (which is dependant upon the amount of contents in the text box).

This is a rewrite of the client I mentioned earlier in class today, to add the polling feature Dr. Wong suggested, and to also incorporate the input panel that Will mentioned, since prior to this afternoon I didn’t know how to actually populate text fields on a Pocket PC GUI. :-P

All of this is done bypassing IIS and the ASP.NET architecture. ASP.NET is mainly a means of hosting a Web Service in IIS, and with a HTML centric mentality (HTML, not HTTP or SOAP, which are both used in all forms of Web Services, such as Remoting or ASP.NET). The demos from the first week of class, and most other online demos try to use ASP.NET, but I think they’re considerably harder to deploy, and require the users to have IIS running (and configurable), aside from the .NET framework.

In addition to the Web Services / Remoting interactions that I’ve been researching, I’ve been in correspondence with Ryan / TJ / Jim about adapting their code to cooperate with Web Services. I hope it works, but I’m not 100% positive. We’ll have to test it soon.
And test thoroughly!

o Obstacles: Microsoft again, makes it hard to search through their materials and books, and find pertinent data. I had to glean the process for doing this from sections on both ASP.NET and Remoting Web Services; there isn’t really a tutorial on how to hook both of them together, which is exactly what we need.

o Proposed solution: I think we could make a contribution to the .NET community (when we have time, after classes end) by writing a tutorial on DevHood and linking or mirroring it on Exciton. That way not just future Comp410 classes can learn from the experience.
SW: There’s a lot from this class you could write articles on!

· Development Process:

What’s working: Microsoft Press books are better than nothing, and I’m finally getting used to which parts of the .NET SDK Documentation are “relevant” to coding, and I’ve finally gotten used to the VS designer interface. I’ve been reading up a lot on C# constructs.

o What’s not working: I feel like I’m carrying a disproportionate load. I didn’t really ask for it, and I tried to enlist some help today in class, but to no avail. I don’t think that everyone else is just sitting around, but I often feel like I take on a task just as a proof of concept (especially when it defies other peer opinions), and then end up spending an inordinate amount of effort showing why I was right.
Perhaps some load-balancing/resource reallocation is in order?

o Proposals for change: Maybe I should suggest the wrong pathways, and then not do a cursory follow-through, knowing that it’ll fail, so that I can’t spend too much effort on it. Just kidding. I’m not sure exactly what to do, I mean, there are only 2 more weeks of class, though I do need to make sure that I don’t fail my CAAM355 class (and hence not end up graduating).

Very nice journal.

----- RJMORGAN --------------------------------------------------------------------------------

· Status of the student's milestones

o Gains made

The AR group made significant progress in identifying a workable solution for Pocket PCs this week. I completed my tasking of creating an ASP.NET web service that runs in an IIS process and is capable of maintaining state across WebMethod invocations from .NET clients.
Even with a PPC client, which doesn’t support the cookies used to maintain session state? Be sure to test on your target platform!

o Obstacles encountered

I initially had problems creating an ASP.NET web service on my local machine running Windows Server 2003 RC1. I resolved access denied issues by running as Administrator, but I still was not able create the web service due to webpath-to-filesystem transIation issues (I suspect the filesystem path is being truncated).

Once I finally created a web service on exciton, I was unable to get the Application or Session state facilities to work across web method requests. Also I ran into problems using instance variables in classes.

o Solutions proposed

As for the first problem, I should install RC2 or confine my web service work to Exciton. As for the other problems, I may not have the WebMethod attributes configured correctly to allow me to utilize the ASP.NET Application and Session classes. I do not believe instance variables will ever work on the web service class since it is always reconstructed, but I found that the class’ static fields are persistent for at least eight hours.
The WebMethod needs to have EnableSession=true. Cookieless sessions need to be set in the web.config, but I can’t get this to work properly myself.

· Analysis of development process

o What seems to be working

The AR group met a few times this week to determine the feasibility of different solutions for the Pocket PC. Theo’s web service via remoting looks like the most viable option since it avoids IIS and it is relatively easy to set up.

o What seems to not be working

We had some early problems figuring out how our solution would tie in with the model and UI groups. It was not until we actually talked with members of the groups that we were able to relay what we can do, given what we expect them to do. It sounds silly, but we basically didn’t know how we would work together until we actually worked together.

There’s a very important lesson here, folks.

o Proposals for change

I’d like to suggest that we create a test team that attempts to use our product in as many scenarios as possible, so that we can hammer out any small issues that we may not have run into with our simple testing. If we’re going to “release” this product, we definitely need to make sure it works and identify limitations in the product manual.

ABSOLUTELY!!!

Nice journal.

----- RYANAIP ------------------------------------------------------------------------------------

Development Status

We’ve made a lot of progress this week, so I think that we’ll have little problem getting the milestone completed. (Which means that we might actually finish the project!) We refactored the adapter structure so that the basic functionality (the stuff we need for the PocketPC) was isolated in one place – look at the SpaceAdapter class.

We also created the necessary interfaces so that we can connect remote GUI’s to a store running on a separate computer, with all of the functionality exposed. Since we’re using NetHub and IConnections for the remote connections, we can’t currently get through firewalls. We need to explore how to get around this, which may involve using the same solution that we create for the PocketPC to get remote access to our spaces.

Process Analysis

Communications are more important than ever as we finish up. The lines between the different groups are blurring, and we need to get our inter-group communication up to the level that we’ve developed within each group. I think we’re doing well in this, but we need to be sure to keep moving.

Basically, what remains is to keep doing what we’re doing. We need to keep moving in little steps and keeping everyone informed when we make progress. Then no one will be left waiting for something that’s already complete.

Nice journal.

----- THEWANG ----------------------------------------------------------------------------------

Milestone status:

Gains made:

Created new attributes that are usable by any entities. They are located in the Model->Attributes->ComparableAttributes folder. Attributes have a preference value in the range [0.0f, 1.0f]. The value 0.5f is a neutral value for the particular attribute. Less means a deference, while more shows a preference. If you can’t find an attribute, try creating a deference for an already existing attribute. More will come soon, and there will probably be a GeneralAttribute that can be loaded at runtime (hmm, maybe it should have been done this way to start with.)
Started working on statistics for various events in the mall that will be grouped by demographic groups. It seems like a decent assumption that statistics can only be gathered by whatever demographics the customer gives us (instead of “imaginary” attributes we create), so as to simplify statistics gathering. It is also extensible in the case where Dr. Nguyen wants to add demographics dynamically.

Obstacles encountered:

After creating more attributes, perhaps it would have made more sense to allow for a GeneralAttribute that will have all types of attributes that don’t require extra storage fields. This will be fixed by the milestone, and hopefully sooner.
Looking at statistics, it seems like the factories (ethnicity and wealth) could be extracted to general factories. Also reading what the customer wanted from several months back, I think he wanted to dynamically modify demographics? Actually much of the statistics gathering was generally vague about how detailed he wanted it. So, here I am making a design decision and documenting it. J
Not really an obstacle, but I still need to use the ethnicity and wealth factories to generate attributes and preference levels for them.

Solutions proposed:

Kinda already mentioned them. Generalize similar attributes, make statistics and demographics decently abstract, and modify the code where necessary.

Development Process:

What’s working:

The project is coming together decently, and it seems like much of what we’re working on can actually be displayed in the mall simulation.
Whatever we’re doing.

What’s not:

Just making sure we don’t do overlapping work. That’s not too much of a problem, but now we’ve got to make sure that we’re trying to do the same things. Even if things aren’t working, there’s not much time for change either…

Change:

Can we not have labs on Friday afternoon? Enough already!

Nice journal.

----- TJICE -----------------------------------------------------------------------------------------

· Milestone Status:

Gains: I cleaned up the wizards. I have made the feature for a person to add an item at a specific location ( basically pointing at a spot on the layout or dragging to a spot on the layout. ) I have tweaked some of the colors on the rendering side. Now in the client wizards, if multiple people are trying to pick spots for a simulation, taken spots are indicated and cannot be selected by the user. I have made a method in the ISpaceLayout interface that takes a point and returns whether or not it is within a space. I have worked with the Model Group on decision making in the AI. I have started on the GUI for the pocket pc implementation. I have made a proof of concept on saving and loading IMallLayouts in XML format.

o Obstacles: There weren’t as many obstacles to overcome this time. There was one pain though. I don’t like the Wizard that we are using. It was made by someone else ( I never like to use other people’s code if all of it’s functionality is not understood. ) It doesn’t have the best design in the world to say the least. Certain issues were a little tricky to overcome ( making sure that the layouts were marked as unelectable as people picked spots within the layout. )

Proposed solution: The best solution is to make a wizard from scratch because hacking was needed to solve the problem. But do to our time constraints that is just not feasible.
That’s what “new versions” are for. J

· Development Process:

o What’s working: The groups are continuing to talk which is good. I get a great deal of support from the likes of Jim, Ryan, and Bryan in the Model Group.

o What’s not working: It doesn’t seem like the workload is being well distributed within groups. There seems to be “miracle men” in each group that do a great deal of work in crunch time to make things work. These “miracle men” handle a lot of issues outside of the scopes of their milestones to actually make this project work. And at the end of this semester I didn’t see this as being fair to them.
Group leaders!!!!

o Proposals for change: My proposal for change would be to just ride out the rest of the semester. There are only a couple of more weeks to go and we need to get this product in a presentable fashion ( which it is not in right now. )
Don’t lose communication with your group leader – make sure they understand and respond to the “miracle men/women” issue!

Nice journal.

----- WRPRICE ------------------------------------------------------------------------------------

Milestone 5 Status: Ready & willing to help Model/UI groups hook PPC to Win32

Gains Made:

Much discussion regarding the interface between PocketPC device GUIs and our largely remoting-based model simulation.

Two design paths were proposed: one was to make remoting calls inside a webservice on IIS that would provide standard web methods to the client, but allow the client to initiate a connection to any space anywhere on the accessible network (i.e. a single PPC web service server, not web services on every machine running the model; the other was to use remoting to “emulate” (forgive the term) a web method without IIS – the simulation process would host the methods on each machine and WSDL would generate the PPC class to interface with the web method-enabled classes of the model.

Obstacles Encountered:

•Persistent state in web methods – while you have a “persistent” state as long as you hold a reference to the method-providing class, if you lose network connectivity or lose the reference, you lose all the state associated with your previous session and it would be difficult to implement any server-side solution (possible, but very inefficient); web methods are designed for a short lifetime.

•The model and current GUI use remoting for their connectivity, which already has one or two abstraction layers between remoting and the actual model/gui... and we might be adding more layers... too many and it might fall over?

•Haven't had a chance to update NetHub to send a “guiEvent” to a particular zone (aka: HubLink) based on user input to the (soon to be implemented?) system tray icon and an associated context menu.

Solutions Proposed:

•Theo provided the most elegant solution with an emulated web method (that's not really an emulation) that runs atop the regular Win32 remoting subsystem and the model application, instead of relying on IIS. This gives us persistent state (as long as the model is running) and easy connectivity to the PPC devices using simple, serializable data. All that's needed is a class implementation with simple functions that return serializable data types that contain the information needed by the GUI. We can m