Kodigo

The document provided by Matthew Green w/c presents a Serviced Based Architecture in Powerbuilder is the basis for all Kodigo services. Here is a shortlist of the features of this Architecture:

• Services are stateless.
• Services appear as singletons, meaning only one instance of a particular service will ever be created, whether  there is 1 or 100 requestors.
• Services are automatically destroyed (if #Pooled = false, more on this later)  when there are no more requestors

Usage example:

ServiceManager services
StringService svcString

services.LoadService(svcString, "StringService")

string lsRet
lsRet = svcString.Format(ls, {"0", "1"})

Now let's walk through the above code

ServiceManager services

The class ServiceManager acts as the broker for service creation. It is also responsible for tracking usage count and service destruction. In essence, this class represents most of the features of SBA.

StringService svcString

The sample service StringService is inherited from ServiceBase. All service functions should be stateless, meaning they do only one thing and be done with it. State should be held by the requestor.

services.LoadService(svcString, "StringService")

This call basically tells ServiceManager to create a service called StringService (w/c is the classname of the service) and place the instance on variable svcString. Let's take a look at the figure below on what the ServiceManager is doing to create the service.

1. Requestor calls ServiceManager.LoadService()
2. ServiceManager searches instance cache for matching service. If found, increments usage counter and returns service instance to requestor.
3. ServiceManager searches shared cache for matching service. If found, adds the service to the instance cache, increments usage counter and returns service instance to requestor. If not found, creates the service in the shared cache, adds service to the instance cache, increments usage counter and returns service instance to requestor.
4. Requestor receives service class.

Now you may be asking, what is the point of having an instance cache when the shared cache will do fine? Well, the main reason is how usage counter is decremented and services eventually destroyed. We'll go deeper into that subject later, for now, let's look at the definition of ServieManager in PB in order to uderstand the instance cache design.

First of all, ServiceManager is an autoinstantiated nonvisualobject. This means that PB will create the nvo as soon as it is declared. PB will also destroy the nvo as soon as the variable goes out of scope. Where you declare ServiceManager is critical on how effective SBA will be. For now, it is important to always declare it as a local variable. Later on I will discuss other options for declaring ServiceManager, depending on the service and situation.

When a ServiceManager variable goes out of scope, PB will automatically destroy the object. In ServiceManager's destructor event, it will unload all services found in its instance cache. So when there are two ServiceManagers in memory, and they have loaded the same service

<TODO> 

Hi Yeyi !!!

Superb Explanation. Any person can understand this.

Thankx for this wonderful work. May Almighty GOD Bless You

Regards
Premji

Thanks Premji, the article is not yet done. Come back from time to time to see if it is updated. I will also try to come up with more articles every week. 

If the ServiceManager is a local, how can it manage all the services? I think it would be useful to create a simple example app. Just the bare minimum objects to illustrate the concept. Perhaps a datawindow service that handles row selection.

Good Idea, I will try to whip up something and post the link on this thread.

If ServiceManager is declared as a local variable (in an event or function), Is not there always a single requestor (if the service is not "pooled")? How can I share a service instance if it is always created and destroyed in the scope of a function or event?

Thanks (and sorry for my english)

Hi kiboko,

If your function only requests for a simple service, then yes, it may be the only requestor. But if the service calls other services, this is where things get interesting. You will also notice that I also pass along ServiceManager to other services that will use another srevice By Reference. That is another topic altogether

One good example of this is the sizing(now layout) service. If you have a window containing serveral composite userobjects that have their own child controls, during the course of the size operation, only 1 layout service is active and as soon as the mouse is released (mouse up) the layout service is destroyed. Another good example is DatawindowService, it calls a lot of it's own functions that call a lot of StringService.

The whole idea is that there should be no services running when the application is idle. Except for pooled services.

I will try to come up with a sample as Roland recommended. Thanks for taking interest in the topic! 

Ok.I understand. So, the key is "there should be no services running when the application is idle".

But why sharing service instances only between services?
For example in DataWindowService, it would be more logical to share the instance of the service among all datawindow controls defining ServiceManager as a shared variable in the DataWindowControl object. When the first datawindow is created, the service is created and when the last datawindow is destroyed, the service is destroyed. I maintain the instance service in memory, but I don't have to create and destroy it in each function or event I need it. The same could apply to services that use other services. For example in DatawindowService, why not defining a ServiceManager instance variable that I can use in all my functions that call anothers services. In this manner I don't have to pass along ServiceManager in my functions. In an extreme case, we might think that all the instances of a class use the same services, so they could share a ServiceManager.The possibility that an instance of my class has already loaded a service in the instance cache of the ServiceManager is very high.

Thanks!

Paco. 

Paco, 

It's good to know that you have grasped the concept well. That is why depending on the requirement, you may choose to declare ServiceManager on a different scope aside from local. But a ServiceManager (w/c is autoinstantiated) can not be unloaded if it is declared as a shared variable in, for example, a datawindow. You would have to manually call ServiceManager.UnloadService manually on datawindow destruct rather than relying on ServiceManager to clean up on itself when destroyed, w/c will not happen since it is an autoinstantiated shared variable. But granted it is still very doable. You actually have a good idea there, LayoutService is a good candidate... 

An instance level ServiceManager is also feasible, especially for highly used services. But the likelyhood of many high volume services being used by a single requestor is quite low (I may be wrong depending on the requirement). An alternative would be setting the service #Pooled=true to have the service in memory until the application goes out of scope, similar to a global variable.

I guess what it boils down to is that you have the option of controlling the lifetime for your service depending on where you declare it or how you configure your service (#pooled). But once you understand the options, you can easily implement it.

This is why I would recommend local declaration for ServiceManager for inital users (even those creating their own service) so they don't have to bother about service retention. Once the requirement is properly scoped, you can then move to a more appropriate model by moving declaration or configuring a service.

I appreciate the thoughts you have shared, I am interested in hearing more