MG: February 2008 Archives

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.
 

Different technologies map differently onto and relate differently to large scale architectural requirements in net-centric systems.  Two important features of technologies that might be useful are (1) how obvious their usefulness to such systems is and (2) how easy it is to illustrate their place in such architectures. [fn. 1]

Mobile object technology (MOT) in general and Kolona MOT (KMOT) in particular can be shown to be clearly useful in meeting large scale architectural requirements but difficult to illustrate.  There is no plain illustration for the applicability of MOT to such architectures like there is, e.g., for an enterprise service bus: no sweeping graphic, no simple statement.  MOT, like JDBC and IoC/DI, needs to be addressed in detail in order to properly illustrate its usefulness.  The bugaboo of MOT is a lack of systemic understanding in the relevant technological communities of what MOT is and the use of MOT is. 

Further, the “evident” nature of MOT potential contributions in general or in relation to architectural requirements in particular cannot be realized without first elucidating and understanding the essential features of MOT.  There is certain knowledge of MOT that is required before these things are “evident”.  The fact that mobile objects move tells us virtually nothing.  Of course they do!  So what?  Without explicit and clear explanations of what MOT is, we are left to guess at applicability.  Consequently, even the “evident” nature of the positive impact of MOT relating in meeting large scale architectural and operational requirements is not clear until the essential high level values in MOT in general and KMOT in particular are well understood.  What is evident is evident only af-ter MOT and KMOT are well understood.  Without this base for understanding, MOT discussions are no more than idle conjectures.

------------------------------ footnotes

[Fn. 1]

“Not evident” in the graphic means not directly useful but that does not mean there is no use in the big picture.  Legacy CORBA or EAI functionality, for example, might plug into an ESB.  “Evident” means something that large scale architectures and systems should incorporate where indicated.  Enterprise Service Bus (ESB): decouples and distributes integration logic.  Extensible Markup Language (XML): provides for interoper-able exchanges between networked hosts.  Java Message Service (JMS): a specification for loosely coupled, event-based, synchronous and asynchronous messaging.  Inversion of Control (IoC): a lightweight dependency injection that assists in the efficiency and cost of development.  Java Database Connectivity (JDBC): a database abstraction that allows multiple implementations to serve an application.  MOT (MOT): an event-based, technology for moving functionality in order to convert remote messaging to local messag-ing.  Enterprise Application Integration (EAI): decouples network integration from applications and pro-vides centralized control of the integration.  Common Request Broker Architecture (CORBA): a standard that enables software components writing in multiple computer languages and running on multiple comput-ers to work together.  C++: a general purpose programming language built as an enhancement of the C lan-guage, adding classes, virtual functions, operator overloading, multiple inheritance, templates and exception handling.  Flash: a multimedia and application player.

Here is the reality: Kolona is as safe as Java and Java is as safe as it gets.  The logic is inescapable: Kolona is as safe as it gets.  This does not mean that there is any perfect security.  Security is always a question of a balance between the price for the security and the price to break the security.

 

Java security and, hence, Kolona security is based on the Java policy file.  Policy files in Java applications describe what objects can do what.  A particular Java process allows users to describe for themselves in their policy file what specific objects can do.  This is not related to whether or not the objects in question are mobile objects.  Mobile objects cannot sneak around users policy files.  The mobility does not require special measures.

Java is a practical language, not an academic language.  The language was meant to solve, not cause problems.  Java more specifically was meant to solve networking problems.  And, security is one of the network problems Java was and is meant to solve. 

Kolona from a security point of view should simply be seen as a set of Java classes.  There is nothing, nothing, I repeat, nothing about Kolona mobile objects that makes them more "iffy" security wise than other Java objects.  So, to understand Kolona security in this sense is to understand how security works with Java objects.  The policy file is the key.  If the user in the Java policy file does not allow a Java object to do what the object wants to do, the object cannot do it in that process. 

A caveat: "security" is concept covering a wide field and like "consumption" or "delinquency" includes matters which are incidentally but not logically or otherwise related.  There is, for example, the issue of cryptology in security.  Hamlet was a nuisance to Claudius, King of Norway, so Claudius sent him with Claudius's trusted agents, Rosencrantz and Guilderstern, bearing a note requesting that Hamlet be murdered on arrival in England.  When they arrived in England, the note was produced, saying that the trusted civil-servants should be dispatched and escaped in an unlikely plot twist involving pirates.  Hamlet the hacker had broken the code.  This, however, is not akin to the security issues that must be discussed with Kolona mobile objects.   The issue with objects is whether or not there is an invitation to the ball.

The Rhodopis story (generally known to us as Cinderella) is more apt.  The question in the case of Java classes security is whether or not the glass slipper fits.  There are no fairy godmothers with weird pumpkins to mutate objects into forms that do have invitations in Java.  But, Oh Joy, if there were, it would not matter.  If the policy file invites the object to do something, everything is going to be alright ever after.

We will discuss the details later and there are volumes in the literature.  But the bottom line is that Kolona mobile object technology is not a special case involving security.  Whatever networking solution one chooses, you can have less but not more security solutions than Kolona mobile object technology.  Kolona mobile objects are not executable files.  They are Java objects.