I challenge the Java Hackers, read on….
As you probably all know by now, I have joined ISIS Papyrus a while ago and last week i was reading the Papyrus Objects Developer Guide again and suddenly lightning hit me and the question raised can this actually be done in Java and if so, how and how easy?
Be aware, reading further could put you in a depression but on the otherhand the real Hacker will find it a challenge. Are you the Hacker?
From the ISIS Papyrus Objects manual for Developers: Classes are the definitions of objects and their behavior designed by the Developer. Classes are required to define general properties of objects derived from these classes, namely attributes, methods, states, and child/parent reference definitions. All classes reside exclusively in the Repository. The object tree in the Repository reflects the inheritance chain. As child objects of a class reflect an inheritance relationship it inherits all properties (methods, attributes, states, state transitions, and parent/child relationships).
Big deal and obvious you may think. But did you noticed the fact that we talk here also about states, state transitions and parent/child relationships.
Papyrus has full support for those concepts without any line of programming. Besides this there is full support for Security (role, policy, privilege), Version control (you can even view the versions and each instance knows to what version it belongs). But more on that maybe later.
I would like to see and explained Java Implementations that cover the UML implementation of State Machine, Parent/Child and Constraints (OCL) as this is all standard in Papyrus Objects and does not require programming at all.
Hackers, show me a simple application simulating for example a traffic light with some attributes and methods that have been constrained as well the state transition itself. You would be a super hacker if you also implement security.
Need inspiration for your Java Hack? Read some parts of our ISIS Objects Manual for Developers and start Hacking. I am waiting for your solutions and i am sure other Hackers will comment on them so that at the end the best solution will be available to be compared to Papyrus Objects. SUCCESS
In Papyrus Objects, authorization is established through Roles, Privileges, and Policies that give Users the authorization appropriate for their tasks. This structure allows the Security Administrator to precisely control access to objects, whatever the User’s needs are.
The Role/Policy concept used in Papyrus Objects is modelled after the CORBA standard of Role Based Access Control (RBAC). Since users are not assigned permissions directly, but only acquire them through their Role (or Roles), management of individual user rights becomes a matter of simply assigning the appropriate Role(s) to the user, which simplifies common operations such as adding a user, or changing a user’s department. The Policy controls the visibility and thus complex filtering for presentation into frames is not necessary if the Policies are well set.
Access to objects (and usually also their visibility) is granted by policies, i.e. the user must be using a Role that is referenced by any of the Policies defined on the object, to access it.
Access to attributes and methods of objects is granted by Privileges, i.e. the user must be using a Role with the required privilege. In addition this Role must also be referenced by any of the Policies defined on the object.
A state machine consists of states and their state transitions, which define the life cycle of an object. Conditions can be defined, thus certain actions can only be applied to an object if it is currently in an appropriate state (e.g. Task in state “Completed” cannot be processed). The fields of the state machine in Papyrus Objects are similar to UML (Unified Modeling Language). The “state machine view” is a frame of the Class Editor and displays the whole state machine in a flow chart. It can be used as a graphical editor similar to the UML Case tools. The state machine lists the states that an instance can have, and the Transitions between those states. Therefore it defines the object’s behavior:
- What kind of information (event) is sent to other objects.
- Which methods are available within the current state.
- Which event sent by a program triggers a state transit
The state change of an object can be:
- user driven
- driven by events
- driven by messages
A State Change has Entry, Exit, and Do Events (actions).
Via child and parent references the relationship between parent and child objects can be defined. A child reference can be used to define which type of object may be added to the object via a parent reference it is possible to defined to which type of object the object may be added.
Constraint fields are used to define whether access to or modifications on a part of an object is granted. This way it is possible to define conditions which decide that a state transition for instance may not be executed under certain circumstances or an attribute cannot be changed in a certain state. If the expression in a constraint field evaluates to TRUE (or the field is left blank) the respective part of the object may be accessed or modified. If a constraints field evaluates to a number, then any number other than zero is true, and zero is false.
The following sections of a class / template definition contain constraint fields:
- Object start (Constraints)
- State (Send Modification Event if)
- State Transitions (Change trigger, Guard)
- Attribute (Constraints, View constraints, and Edit constraints)
- Method (Pre constraints and Post constraints)
- Child and Parent References (Constraints, View constraints, and Edit constraints)
To define which group of users should be able to call a method or view / edit an attribute, select the related Privilege(s) in the field “Privileges” of the method or “View Privileges” or “Edit Privileges” of the attribute. ISIS provides the following predefined Privileges, which are defined in the Privileges object below the Storage folder “Storage / System Collection”:
$_Developer … Create / modify classes and templates
$_Administrator … Create / Modify templates
$_Security Administrator … Manages access rights
$_User … End user, cannot create / modify classes and templates, not all methods available.
$_Guest … End user with very limited rights for viewing.
$_Licence Administrator … Administrates product authorizations
$_System Administrator … General administration (e.g. creation of Client Nodes, import of transfer files, etc.)
$_Supervisor … System supervisor for the select of objects, which should generate an audit trail (with System Supervisor Role) or privileged end user for release tasks.
One thought on “Call for Action for the Java Hackers”
You’re looking for a program, implemented in Java, that is a state machine implementation with the concepts of an inheritance hierarchy and authorization built in? So why should I bother hacking my brains out when the type of program you seek is downloadable for free at http://java.sun.com? The Java Virtual Machine, included in every JRE and JDK, is what you’re looking for.
On a more serious note, Freddie, what exactly are you trying to prove? You keep going on ad infinitum about ISIS Papyrus and all its miracles and not having touched Java for such a long time, but what are you really trying to prove here? That Java is a programming language and not an application platform? I don’t think there’s a person in the world who will disagree with that. But at the same time have the decency to acknowledge that you’re comparing apples to wheelbarrows here. I’m not saying that your comparisons are off — I’m saying that there’s no sense in attempting them.
That said, you want to know whether it is possible to write something like ISIS Papyrus in the Java programming language? Yes. I don’t even have to think about that one. The Java programming language has expressive power equal to that of a Turing Machine, which is also the case for the programming language(s) that went into building ISIS Papyrus and (more importantly) for the processor languages of the processors that RUN Papyrus.
You want to know whether it is possible to implement a state machine in Java? Or an object hierarchy? Or security of any kind, role-based or other? Yes. There are existing examples of all of those and some of them in combination as well (Documentum for instance). There are also systems around that DON’T have those concepts overtly implemented; here’s a shocker for you Freddie, not every system needs them.
Here’s a more important question for you though: so what? None of this is surprising, since all of it is as old as the dawn of time. State machines? Please, there have been state machines since graph theory was invented. Inheritance hierarchies? Have been around since the idea of classification itself.
So what are you trying to prove Freddie? What’s the point?
Comments are closed.