Part 2. The Use of Mobile Object Technology in Large Scale Architectures

The potential impact of mobile objects, like the potential impact of an ESB, on networked systems is more a matter of understanding than proof.  Once you understand MOT (mobile object technology) in general and KMOT (Kolona MOT) in particular you will be able to identify when their use would consti-tute best practices .  Where MOT is indicated, usually nothing other than MOT will pro-vide an adequate substitute due to the nature of the values MOT brings to the table and the nature of the problems that MOT solves.  

A.    MOT 101: What is the Essence of MOT?

Mobile objects move functionality.  Under usual circumstances the movement of func-tionality at one level or another (processing, business flow) is the main business of mo-bile objects although they can carry messages as well.

Standard networking involves the exchange of messages, cf. Figure 2.

 

The variety of solutions outside the MOT arena is found in how such messages are passed.  We will not go into this detail.

Network messaging, also, is contrasted with local message passing, cf. Figure 3.

 
Local messaging passing is faster than fast and not subject to the trials and tribulations of network messaging passing.  This is where MOT begins to make sense.  There are times when we should try to convert Figure 2 functionality into Figure 3 functionality.  The use of MOT seen at the most abstract level is when this circumstance is useful, cf. Figure 4.

This, however, is only part of the story.  What we have emphasized here is that function-ality, the act of messaging rather than the message is being moved rather than informa-tion.  This is important but does not differentiate MOT.  Objects, non-mobile objects, are often sent remotely and have functionality intended for local use.  The difference with mobile objects is that the movement is part of the mobile object functionality.  Mobile ob-jects are not moved so much as they request their own movement and in this sense are responsible for their own movement.  MOs usually request movement from a mobile ob-ject runtime environment (MORE).  Thus Figure 5, infra, shows the more complex back-ground MOT has in moving functionality as opposed to standard networking of objects containing functionality.  (While Figure 4 is simpler than Figure 5 the general picture in Figure 4 when expanded to include all its elements would be more complex.  The use of MORE simplifies and “standardizes” the use of mobile functionality by decoupling the mobility from the application on the target machine that will use the functionality.)



In Figure 5, the object requests movement to a remote site and upon arrival is notified of success allowing the object to initialize itself before its run method is called.  This is very different than the picture in Figure 4.  The availability of a mobile object runtime envi-ronment (MORE) is necessary to what makes a mobile object a mobile object.  Such en-vironments may allow mobile objects to request more than their movement.  For exam-ple, they might request to be stored for a given amount of time or until some event oc-curs.  The mere movement of a mobile object is a minimalist use of the mobile object.  Multi-stop trips are what make MOT so powerful. 

But, wait, we are not done.  How can the messaging relationship between the local object (Object B in Figure 5) and the mobile object (Object A in Figure 5) happen?  This is not magic.  What is the mechanism?  More is to be revealed.

B. MOT 201: MORE Management

On occasion the MOT must interface with existing applications.  How is this achieved?  The answer, first, is that the MORE must be embedded and, second, that the MORE must allow the existing application and the MO to communicate through a MO “associatable” plug-in (MOAP). 



The application registers a MOAP with the MORE and this allows the MO functionality to send and the application to receive messages from the MO functionality.  The MO reg-isters a MOAP with Kolona and the MO retrieves the MOAP via an Associatable-ServiceObject that extends the ServiceObject (SO) interface.  The application registers the references to application objects the MO functionality needs to message and the MO functionality registers the MO functionality objects the application needs to mes-sage.

C.  MOT 301 Decoupling MOT and Moving Business Logic Functionality

The question now arises as to how MOs bring functionality to a remote application.  If the functionality is already there, this is not such a feat and of little use.  If the functional-ity is not there, how is it “carried” by the mobile object?  How does it interact with the MORE, since it is new functionality?  How can a class loader load the classes if they are not here?  What if you want to change the functionality?  What do you do then?  These are all the sorts of questions intrinsic to MOT.  The maturity of the answers is coincident with the maturity of the MOT.  Does the MORE have to know about the specific MO?  Is there a way to have functionality that is intrinsic (related to mobility - MOFI) to the MO aspect of MOF separated from the functionality that is extrinsic (business logic - MOFE) separated?  The answer is “Yes!”.  KMOT makes the separation by having framework and application Java Archive (JAR) files loaded on the startup of Kolona (separate from the application) and MO JAR files loaded on the arrival of the MO.



The type of the MO, the implementation, can be contained either in the MOFI.jar or in the MOFE.jar. (MOFI.jar is placed in a Kolona directory prior to startup.  MOFE.jar is co-migrated with the MO.  MOFI functionality can always be included in MOFE.  “MOFI” and “MOFE” are not required names and are used here for convenience only.)  What a node (machine) in a network contains can differ along with what functionality is involved with a MO. 

    C.1.    Node Functionality

The node can contain various combinations of (1) MORE; (2) MOFI.jar; and (3) Applica-tion with MOAP.  Any of these combinations are possible, understanding that MORE is an absolute requirement.  No MORE?  No MO!  MOFI JARs can be any functionality one might want.  However, since MOFI functionality is presumably not functionality specifically associated the application (otherwise it would be in the application), MOFI would be functionality associated with MOT, such as a MO framework not unlike Struts is a framework in a multi-tiered. Web server.  (KMOT includes a framework called “Strategies” that abstracts and makes transparent to the application programmer MOT, allowing the programmer using KMOT to concern him or herself with business logic alone.)

    C.2.    MO Functionality

A KMO must have a MOFE.jar, but the JAR can be null.  The MOFE.jar can include the type (implementation) of the MO or that type can be included in a MOFI.jar.  Either the application, the MOFE JAR or the MOFI JAR must include the MO implementation class.  If one uses a mobile object framework, such as Strategies, then the MOFI JAR will contain all the MOs and SOs needed.  If not, then the MOFE JAR is likely to contain these entities.

D.    KMOT 202: Creating a Kolona MO (KMO)

How does all this get started?  Where did a MO come from?  Who wrote the “book of MO”?  There are MOs that are created initially by non-MO functionality and there are MOs created by MO functionality. 

MO plug-ins (MOPs), a Kolona object, and MOs themselves create KMOs.  Each will be considered separately.  All mobile objects are created with a createMobileObject method that takes String, Object array and (depending on the creator) File objects as parameters.  The String parameter is the name of the fully qualified type of the MobileObject implementation.  The Object array parameter is the set of objects used to initialize the MobileObject.  And the File parameter is the location of the MOFE.jar JAR file.  (This location can be null for MOP or Kolona, if no application level external classes are needed.)

    D.1.  MOP

The MOP class is accessed remotely.  Kolona MOPs (KMOPs) have access to MobileObjectRuntime, which can create MOs with a createMobileObject method.  

    D.2.  Kolona

Kolona is accessed locally by the application that embedded Kolona.  The Kolona class itself has a createMobileObject method. 

    D.3.  MO

The KMO is accessed internally.  An MO can clone itself or create a mobile object with its MobileObjectServices object (set by Kolona’s Spring container in Kolona with inversion of control, IoC, dependency injection, DI) a slightly different create-MobileObject method, viz. one that does not take a File parameter.

        D.3.1.  Cloning

If a MobileObject clones itself, no createMobileObject method is required: clone is called.

        D.3.2.  Creating New Type

If a MobileObject creates another type of MobileObject, that new type of Mo-bileObject must use the MOFE.jar that the creating MobileObject had.  Accord-ingly, such a KMO does not have a File parameter in the creation method.

Next, in Part 3, we will look at MOT in illustrative system wide scenarios.