Tom,

First:
I agree that we need to be looking at what is in the standard and seeing what works and doesn't work. Unfortunately, the standard is now being looked at with implementation in mind and there are going to be problems. I have already found something I don't like about at least GPOS and VSS and might apply to all services that don't inherit from Management. Mainly, there is no mechanism to know that there is a problem with these services. However, the Management Service is too cumbersome. It is a mistake to force all services to inherit from Management, especially since that would also require all services to inherit from AccessControl.

Although I think that Management is cumbersome, I am wary of just saying that Management is broken. Is the the behavior of moving from one state to a non-initial state in another nested state machines an invalid transition? The draft of the The Mission Spooler Service I have also does this. Maybe this was changed in a more recent version? I haven't come up with a good example as yet, but my gut is telling me that these transitions are needed (it's been known to be wrong before though ).
I would be curious to see a rework of a management type service that accomplishes the same behavior without those irregular transitions.

Second:
After revisiting the Transitions definition in AS5684, I agree that the Transition methods themselves don't need a Parameter List and just the message or internal event (i'll use the word trigger to mean either one) can be passed to the transition handling mechanism. The standard does it make it sound like like parameters are part of the transition method call but I think this is a mistake. The actions and guards executed by the transition are where the parameters would be required. This allows a single action or guard method to be defined and called with different results. In this context it is the transitions responsibility to populate the parameter object. From a definition standpoint I think that this is the only way JSIDL can make the desired actions and guards clear. The trigger could also be passed all the way down to the action or guard methods and have the action or guard worry about unpacking the trigger and deciding what to do but I feel like this is cumbersome and would be ambiguous in a definition or require a lot more explanation.

Third:
This is a way I am approaching the Component/Service problem. I look at a service and a component as essentially the same. A component essentially just ties the Service to the JAUS network. So if we can solve the State Machine inheritance problem then I think the multiple services per component problem is solved. A service consists of 4 things: input messages, output messages, internal events, and state machines. A component consists of exactly the same 4 things. In a component with 1 service: the component input messages = service input messages, the component state machine = service state machine. If two services are added to 1 component: component input messages = service1 input messages + service2 input messages, component state machine = service 1 state machine + service 2 state machine. See the attached diagram for an example. So how do we accomplish this? First we allow a state to have multiple nested state machines. The state machines should be independent of each other and they will be if they share the same parent. Then we allow a service to be passed a parent service. If no parent service is provided a complete service chain is constructed. If a parent is provided then the parent state machine is modified. Lets say a developer wants to build a component with 2 services. They need to construct 3 services: the last shared service in the chain, and the two services they wish to implement and pass the parent to both implemented services. It makes it a little more complicated to use but only if you want more complex functionality. Novice users don't even need to know that this functionality exists. The cpp file I attached shows how this would work. It was written and run using VS2008 if you wanna see what it looks like. I think this is similar to the way Qt works.


I'm not understanding how these "Supplemental or Enhancement Services" would work or what they look like. How are you attaching these supplemental services to a non-supplemental service? How are you dealing with the possibility of these services having states and reacting to triggers?

Although, the components can interact using some kind of IPC the fact that they have JAUS addresses means they are not hidden from other JAUS components. I have no problem with using IPC to share data between component within the same application (I like it since it generally allows for faster data transfer) but it doesn't solve the problem I have. I mentioned this in a previous post. If we go back to the VehicleState component example. Although I have a component to coordinate the GPOS and VSS components, what is preventing another component from circumventing the VehicleState component and directly talking to the GPOS or VSS component? In a dynamic configuration environment what is telling another component that it has to talk to the VehicleState component if it wants to talk to GPOS or VSS?

I took a look at your flowchart and built on it to account for default transitions and default state default transitions. Some of the stuff in your diagram was confusing just because they didn't have arrows. The flow is recursive and I use exceptions to return control back to the caller instead of having to check if there was a parent. I also built it using the same concept of a state containing a nested state machine. One of the keys of this working is that when a state machine is added to a state, the state is modified so it knows about all the supported triggers within the nested state machine. It also uses a different definition of a default state than is currently in the standard. The current definition is wrong and will be changed in the future. It doesn't handle the differences between the different types of transitions as yet.

As I was trying to walk through the flowchart and figure out if it worked, I came up with the idea that we should develop a test plan that examines the different possible scenarios for the transitions based on the nesting to walk through the algorithm and can be used to build the unit tests for when the code is actually being written. The test plan is just a sample of what I was thinking.

Nick,

Thanks for all this great work! Could you put a copy of the visio file on the documents repository?

To address your comments:

1. I agree management is too much for most services. I see error reporting / error management as a good case for supplemental services. Since we now have a good handle on multiple services per parent. Supplemental services could simply add their state machines to a parent. This would then add a bunch of transitions to the parent service.

Also, yes, I think the transitions defined for management in JSS core are invalid ones. I think we can design the system better, now that we have a good mechanism to do so. When we get into management design. We'll take a look at how to improve the state machine.

2. Agree and like it all.

3. I like this solution. The default constructors could create the service chain by default. Another constructor could pass the parent object to the child service.

I have added the State Machine Flowchart to the documentation repository under 2010 Design folder.

I also added an example file for the Service which allows a parent to be passed. It's under the nick folder as service-example.cpp. It was written using VS2008 but should compile under linux will little changes. I don't think its necessary to have two constructors. I just use a single constructor and pass a default value of NULL if a parent is not provided. I also provided protected methods for the service to modify itself. The methods are required in order to protect against the developer doing something invalid and to prevent data duplication.

Nick,

Thanks for uploading the file.

I'm not exactly sure why the protected methods are needed. I would imagine that conflicts could be detected as services were added to the component, and we can throw errors.

I'm curious if you think we have enough of a solution to move forward. Do you think we still have any Service design issues to resolve? I'd like to start working on new design topics, like messages, transport and discovery.