Moving to GREEN for mine. . .
>My responses in purple.
>
>>Hi Roger,
>>
>>I'm going to take this opportunity to answer some of my own questions and ask some others. I found some documentation in the MSDN Library, though virtually all of it is marked in red with "this is preliminary documentation and subject to change".
>>
>>I'll use italics under the 'question' to answer the question (I posed) and try to use blue to indicate a follow-on question. Here goes. . .
>>
>>>Jim,
>>>
>>>I know what you mean; I've had the same problem wrapping my brain around the theory around distributed programming. In my case I think it's because of the way I came up through programming. Starting with dBase III+, then Clipper, then finally Fox but almost all on a DOS or Unix platform and all for small businesses.
>>>
>>>MS calls these 'notifications' so I think the publisher has to be designed so that it doesn't need to know if the subscriber was successful. Since MS says you can add and change subscribers without having to change the publisher that means the publisher can't get a response from the subscribers because the publisher doesn't know how many (if any) subscribers there are.
>>>
>>>Maybe the event log was a bad example; perhaps sending an e-mail or a pager alert to the administrator is a better example.
>>>
>>>Instead of the subscribers returning a value to the publisher via a method call or a function the subscribers could send a queued message to the publisher or another component.
>>>
>>>I've been thinking about this stuff for a client of mine. They are a regional food processor here in the northeast and are currently running an ancient DOS based system (not even Fox). Their executive offices and order entry department are in one location while the plant and shipping is in another. The publisher in the order entry department sends a message to a subscriber in the shipping department and maybe another subscriber that sends e-mail to the customer's sales person. The e-mail subscriber doesn't need to acknowledge the message but the shipping subscriber probably does. What message could the subscriber send? "No news is good news?" "Acknowledge every message?" If the subscriber sends a negative message what could cause it? Not enough product? A programming error? A programming error should also send a message to the development staff.
>>>
>>>
>>>
>>>>Roger,
>>>>
>>>>I can see dealing with failure on the publisher side. I think I have a few options there.
>>>>But it is the subscriber that troubles me. I don't see how I can tell that it completed (heck, I don't even (seem to) know that it was even run), let alone completed successfully. Writing to the event log will let a person see that there is trouble, but what about the application? Looks like I can only use this for application bits that are irrelevant to the main processes. Sort of like 'nice to haves' and 'hopefully most of the times it will run' kind of things. I really haven't done many (none, really) like that.
>>>>
>>>>I really think I must be missing something basic here.
>>>>
>>>>Jim
>>>>
>>>>>Hi Jim,
>>>>>
>>>>>I've just started to play with COM+ stuff as well but I think the answer to dealing with failure of the subscriber or publisher would be to write to the Win2k event log and return. As services they have no user interface and there may not even be an operator around to react.
>>>>>
>>>>>
>>>>>>I have read the subject section in the "VFP COM+ Services Samples" in the VFP7 documentation as well as in the "What's New in Visual FoxPro 7.0" book from Hentzenwerkes. Using the book's instructions I ran the related sample (from the VFP Samples included in the (VFP7) product material) and examined the code associated with it. [note: I confined the sample running/examination to the "publish/subscribe" part only]
>>>>>>
>>>>>>While the entire arrangement struck me as a bit strange (particularly a class of empty methods as the 'Event Class'), it is simple enough of a procedure. After looking through the code I think that I have a basic understanding of the mechanism for publisher/subscriber COM+ events.
>>>>>>
>>>>>>The sample does leave several questions in my mind that I hope can be answered here:
>>>>>>
>>>>>>I surmise (didn't see a definitive statement in either document) that there can be no RETURN value of any kind from a "subscriber" object. After all, there can be many subscribers to a single publisher and how would the 'publisher' handle multiple returns?
>>A:From "COM+ Events Architecture". . ."Event methods must be uniquely named and can contain only input parameters (no output or input/output parameters). The return value must be an HRESULT." and later "To support more than one subscriber notification for an event, methods can contain only input parameters and must return only success or failure HRESULTs."
>>I don't know what, precisely, HRESULT is (or 'success or failure HRESULTs' mentioned in the second quote), but I surmise that it is equivalent to .T. for success and .F. for failure. Hopefully someone will clarify. From this I surmise that any subscriber that returned 'failure' would be the one that was reported back. This would also mean that the publisher process WAITS until ALL subscriber processes have finished, as I infer things.
>HRESULT's are the standard means that COM components use to report success or failure. Generally 0 means success.
>
Thanks. Do you think that the suppositions I made from the quotes are correct? (it WAITs and any non-zero result would be the reported one?)
>>
>>>>>>1. Assuming this to be correct, what would be a practical use for these "events"?
>>>>>>---Even for the simple example provided, where the subscriber simply records the change to a .TXT log file, what value would the LOG file have if there was a problem writing a LOG record (like, say, the HD to contain it was full or the file had been changed to be read-only)???
>>>>>>The best that I can come up with would be to launch some other application (say Word or e-mail or IE or . . .) which the operator may or may not use as expected/directed.
>>>>>>
>>>>>>2. Does the publisher process wait for completion of (all) subscribers or does it proceed independently?
>>B:See A: above
>>
>>>>>>
>>>>>>3. What happens if one or more of the subscribers has a problem during processing?
>>C:See A: above
>>
>>>>>>
>>>>>>4. What happens if someone attempts to change one or more of the subscriber components?
>>>>>>--- Is the person attempting the change notified at all that it is a "subscriber"? If so, when?
>>>>>>--- Is any 'adjustment' to the COM+ "catalog" necessary and, if so, is it done automatically or is it a manual process?
>>D:I didn't come across the answer for this
>I see that there are two different kinds of subscribers persistent and transient. A quote:

"When an event is delivered to a persistent subscription, the COM+ event service creates a new object from a configured subscriber component and invokes the method associated with the event. The event service wakes up the subscriber application if it's not already running. You should note that, for a persistent subscription, an object is created and destroyed each time an event is fired."

>"The second type of subscription is a transient subscription. Once an application is running, the application can register itself with a specific event class to listen to events as they’re fired. In this case, the event service does not create and destroy an object for each event. The main difference between the two subscription types is that a transient subscriber must programmatically create a new subscription and register a callback in order to listen for events."

>(BTW I got this from an MSDN article called "COM+ Overview for Microsoft Visual Basic Programmers" by Ted Pattison of DevelopMentor)


>I also think it depends on why the subscriber is changing. If just the internal implementation is changing and the public interface is not then there should be no problem. If the public interface is changing then the component will probably need to be re-registered both with COM+ and the publishers.
>
Yea, but I was wondering about things like someone decided to move or remove a subscriber, using, say the Windows Explorer. Would something warn that there are dependencies out there?...or would changes (in the case of a move) be done automatically for the registered subscriber?...or would the person simply HAVE TO KNOW and take appropriate actions?
>>
>>>>>>
>>>>>>5. A COM+ application can consist of multiple COM components that are "administered as a unit and run in the same process". Would one do this to optimize the response when a known group of VFP COM servers would be expected to be used by a regular application or is there some other need for this?
>>E:Apparently so
>>
>>>>>>--- Can at least one of the subscribers be included in the COM+ application definition? Could they all?
>>E1:Can't tell, but I guess NOT.
>>
>>>>>>--- Can a subscriber be on a different server or must it reside with the publisher(s)?
>>E2:Here's a statement that I found: "Note This version of COM+ Events does not support a distributed event store. A subscriber must subscribe to an event on each computer from which it wants to receive notification. As an alternative, you can register the EventClass and subscriptions on a central computer and instantiate this EventClass from the remote computers on which you will publish events. Delivery of events is provided either by DCOM or queued components."
>>
>>>>>>
>>>>>>6. Are COM+ applications and COM+ events mutually exclusive to other COM+ features (like Queued Components) or can they be integrated together?
>>F:Here's another statement: "It connects to those subscribers (by direct creation, monikers, or queued components) and calls the method.", so I'd say that these are NOT mutually exclusive with other COM+ features. I did come across some restrictions applicable when Queued Components are used with them.
>>
Getting closer to understanding this thing! Thanks.
>>>>>>
>>>>>>Thanks for your patience and responses
>>>>>>
>>>>>>Jim Nelson