One of the technical fashionable terms is NoSQL. That is not really the reason why I wanted to have a look at it, but still it is a good reason to at least have an understanding of what it is. The best way to do this is to try it out. Together with [...]]]>

One of the technical fashionable terms is NoSQL. That is not really the reason why I wanted to have a look at it, but still it is a good reason to at least have an understanding of what it is. The best way to do this is to try it out. Together with Allard I am creating a new sample for the Axon framework. This sample must support a lot of inserts and fast queries. This can be done using an sql database, but using a NoSQL database felt good as well. Therefore I started replacing the jpa implementation with a Mongodb implementation. This blog post is about the things I have learning while implementing Mongo. Be warned, I am not an expert, so if you spot improvement, please let me know.

Introduction

First a warning, I am not going to explain a lot about the basics of Mongo. Still I’ll write down why I was curious enough to try it out and I give some pointers to where you can find more information.

So why MongoDB. They claim to have the ideal combination of storing documents in a flexible manner and still be able to search them in ways you would do with a relational database. Storing documents instead of rows in tables feels more natural. I have been using Hippo now for a few years. They use JackRabbit for a datastore. They store everything in trees. Performance and scalability are not very easy to accomplish. Therefore I am very curious what storing documents in MongoDB will bring. The way MongoDB deals with searches is interesting. You can create queries that use nested properties of a document to query on. I’ll have some samples, especially for things like sorting and paging through your results.

As you should know from this blog, I am a java programmer. Therefore I need to connect to Mongo through a java API. Mongo supports a lot of different Drivers to connect to it. Of course a java driver is available as well. I’ll show you some things that were harder to find in the normal api documentation.

You probably know Mongo does not have real transactions. Well that is the whole intention. MongoDB does support other mechanisms to make sure data is consistent, however, by default it is more optimized for speed. I’ll go over some things like “Write Concern”, “Batch inserts”.

As a jpa/hibernate user you are probably familiar with object relation mappings (ORM). Well we do not need an ORM tool, but still we need to transform query results into objects and objects into documents. Ok you might not need to immediately, but believe me there will be a moment that you need to. Therefore I’ll have a go at them as well.

Scalability is another beast that MongoDB should support pretty well. Therefore I started experimenting with the technology using a few virtual machines. In the last part of this blog I’ll discuss some of my findings.

Basic stuff

Installation

There are a number of ways to install MongoDB. For most common operating systems packages are available. Later on when I have created a few VMWare images I’ll use this installation guide:

http://www.mongodb.org/display/DOCS/Ubuntu+and+Debian+packages

Most of the time I work with the binary download and start it up myself. Later on, this is also the most easy way to experiment with Replica sets. Just download the right package from the following location for your OS. Unpack and run the mongod script in the bin folder.

http://www.mongodb.org/downloads

First steps

Start up the mongodb instance and the client. When connected, execute the command show dbs, in my case this results in the following output:

admin
axonframework
axontrader
local

I am using a sample application created with the axon framework. The sample is the axon trader. All the axonframework related items are stored in the axonframework database. This database contains the following collections, obtained with the command: show collections. Before you can do that, you need to choose the right database to start working with. In my case I start with the axonframework database: use axonframework.


> show collections
domainevents
system.indexes

Of course I am not going to explain all commands here, the last one I want to mention explicitly is the help command, really useful: help.

Storing and searching

Mongo is used to store documents. Documents are stored in collections. Storing is done using insert() or save(). The structure of the document is not really important. The following commands create a new database, collection and insert a document, query for all blog documents and drops the complete table again:


use gridshore
db.blogs.insert({title:"my first blog", main:"And this is the content of my blog"})
db.blogs.find()
db.blogs.drop()

Now let us assume we have a lot of blogs and we want to search for all blogs with a tag “Mongo”. Creating such a document and searching for that document including the result is presented in the following lines.

> db.blogs.insert({title:"my first blog", main:"And this is the content of my blog",tags:["Java", "Mongo"]})
> db.blogs.find({tags:"Mongo"})
{ "_id" : ObjectId("4c95fa6830d8854d0fdece13"), "title" : "my first blog", "main" : "And this is the content of my blog", "tags" : [ "Java", "Mongo" ] }

Let us move on. Since I am mainly a java programmer, I need a java api. The next section is about the Java Driver

Java driver

From the mongodb website you can download the java driver, it is also available in the maven repository. After that it all starts with the class com.mongodb.Mongo. This class contains a number of constructors like the default constructor, a constructor with a host and port for the service to connect to, and a few others. One of them is used later on when I start talking about the Replication Sets. Your application should use a single Mongo instance. This instance uses a connection pool internally to provide connections. To obtain a connection, you provide the name of the database. Than you have a DB connection, using this connection you can obtain references to collections. Using the collection you obtain all items using the find method. The following code block shows them all in order.

Mongo mongoDb = new Mongo();
DB db = mongoDb.getDB("axonframework");
DBCollection domainevents = db.getCollection("domainevents");
DBCursor db = Cursordomainevents.find();

That is the most basic query, there are other things you can do. Provide an instance of DBObject to filter the results. The DBObject is also used to sort the results. A special BasicDBObjectBuilder is available to create new DBObjects. The following code block shows them in action.

DBObject mongoEntry = BasicDBObjectBuilder.start()
        .add("aggregateIdentifier",identifier.toString())
        .add("type", type)
        .get();
DBCursor dbCursor = mongo.domainEvents().find(mongoEntry).sort(new BasicDBObject("sequenceNumber",-1));

That is all about looking for data, of course we also need to insert data. The most basic case is almost to easy to show, still I want to, and just because I am the author of this blog, I can . In the next code sample aDomainEvent is an instance of DBObject.

mongoDb.getDB("axonframework").getCollection("domainevents").insert(aDomainEvent);

Batch inserts

In some situations you want to insert multiple documents at once. The java driver has a facility for that as well. You can use the batch insert like shown in the following code block.

List<DBObject> entries = new ArrayList<DBObject>();
while (events.hasNext()) {
    DomainEvent event = events.next();
    DomainEventEntry entry = new DomainEventEntry(type, event, eventSerializer);
    DBObject mongoEntry = BasicDBObjectBuilder.start()
            .add("aggregateIdentifier", entry.getAggregateIdentifier().toString())
            .add("sequenceNumber", entry.getSequenceNumber())
            .add("timeStamp", entry.getTimeStamp().toString())
            .add("type", entry.getType())
            .add("serializedEvent", entry.getSerializedEvent())
            .get();
    entries.add(mongoEntry);
}
mongo.domainEvents().insert(entries.toArray(new DBObject[entries.size()]),WriteConcern.SAFE);

If you look closely at the last line, you see we pass an array of DBObject instances to the insert method. Did you see the last parameter? You can also pass a write concern, what that is? Check the next section.

Write concern

By default Mongo sends data to the store and if it is received it is ok. Sometimes you want more than that. It might be very important that content is stored in one node or maybe even in multiple nodes. By providing a WriteConcern you can specify how much safeness you want. NORMAL is the default, just pass it and leave it like that. SAFE only waits for the master by using the getLastError. REPLICAS_SAFE does the same but also waits for the slaves. Be careful when using REPLICAS_SAFE in a test environment without slaves, it will wait and wait.

Object mapping

If you are using object that contain a not to complicated structure, it is not to hard to create a custom mapper for the object to document and document to object. If you do this regularly and the work becomes repetitive you might want to have something easier. You could implement the DBObject interface yourself, that way mongo will create an instance of that object from the document in the datastore. With some basic implementations this might be an interesting way to create your mapping. Personally I do not think this is the way to go, it is to intrusive. Other mapping frameworks are available as well. Personally I think Morphia has the best papers for now. But it only support annotations, which is harder to use when you have library code. With the axon sample I wanted to checkout this approach. But it turns out to be a topic in itself. Therefore I decided no to do it right now. Documentation for the framework is being rewritten at the moment. Therefore I’ll come back to it in another post in the future.

Replication

Mongo supports two mechanisms for replication, Master-Slave and Replica Sets. With respect to scalability another thing called sharding is also very interesting. Sharding is about separating content over multiple Sets. So if you have a very large data set that can be separated like in online shops put the user information in one shard and the product data in another. That is all I am going to say about sharding for now. I’ll focus on replication for now. The documentation can be found at the following link. I strongly advise looking at the video mentioned on the page.

http://www.mongodb.org/display/DOCS/Replication

Master-Slave

The Master slave configuration is well known from other data sources. With Mongo the Master-slave configuration has been proved in production. Configuration is not hard and well documented. A few things I want to mention are:

• slavedelay, you can intentionally put a delay between a master and a slave. This is nice to use as a runtime backup. If you by accident to something stupid, you have an easy way to get things back.
• db.printReplicationInfo(), returns information about the replication from the master perspective
• db.printSlaveReplicationInfo(), returns information about the replication from the slave perspective

Another thing that I definitely want to mention is the oplog. This is a log that is used by the slaves to stay up-to-date. I like the idea that the log is actually stored in the database itself. Be sure to make it big enough or else a longer downtime of your slave will be a big problem.

The biggest thing with Master-slave is that a security mechanism exists. You can configure security constraints based on collections of data. This is not (yet) available for Replica Sets. Other than that, Replica Sets are the way to go for Mongo 1.6 +.

Replica Sets

Some references are: http://www.slideshare.net/mongodb/mongodb-replica-sets, http://www.mongodb.org/display/DOCS/Replica+Set+Tutorial

First start up three nodes for the Replica Set. The following commands start up three nodes

mongod --replSet axon --port 27017 --dbpath /data/r0 --rest
mongod --replSet axon --port 27018 --dbpath /data/r1 --rest
mongod --replSet axon --port 27019 --dbpath /data/r2 --rest

Nodes do not enter the replica set on their own. You have to explicitly add them to the set. You also have to initialize a replica set the first time you use it. The following lines show you just how to do this

> cfg={_id:"axon",members : [{_id:0,host:"localhost:27017"},{_id:1,host:"localhost:27018"},{_id:2,host:"localhost:27019"}]}
> rs.initiate(cfg);
{
	"info" : "Config now saved locally.  Should come online in about a minute.",
	"ok" : 1
}

Be sure to check out what happens when you add a node to the set. The following lines show the log of one of the slaves when the master goes down. After that the node that was the master is restarted

Sun Sep 19 13:14:46 [rs_sync] replSet syncThread: 10278 dbclient error communicating with server
Sun Sep 19 13:14:46 [conn4] end connection 127.0.0.1:59341
Sun Sep 19 13:14:47 [ReplSetHealthPollTask] replSet info localhost:27019 is now down (or slow to respond)
Sun Sep 19 13:14:47 [rs Manager] replSet info electSelf 0
Sun Sep 19 13:14:47 [rs Manager] replSet PRIMARY
Sun Sep 19 13:14:57 [initandlisten] connection accepted from 127.0.0.1:59478 #6
Sun Sep 19 13:16:03 [initandlisten] connection accepted from 127.0.0.1:59565 #7
Sun Sep 19 13:16:03 [ReplSetHealthPollTask] replSet info localhost:27019 is now up
Sun Sep 19 13:16:05 [initandlisten] connection accepted from 127.0.0.1:59567 #8

From the client you want to connect to the master, to find out which node in the set is the master, you can connect to one of the nodes and run the command db.isMaster(), the result is a document containing enough about the replica set to check for the node to connect to.

> db.isMaster()
{
	"setName" : "axon",
	"ismaster" : false,
	"secondary" : true,
	"hosts" : [
		"localhost:27019",
		"localhost:27018",
		"localhost:27017"
	],
	"primary" : "localhost:27018",
	"ok" : 1
}

As you can see my set contains 3 nodes and the primary node is on port 27018. You should always connect to the master node using the shell, or else you get messages like this:

Sun Sep 19 12:25:40 uncaught exception: error: { "$err" : "not master", "code" : 10107 }

In my case I had to start the shell using mongo localhost:27018. With java things are less complicated, the driver selects the primary node by itself. The following xml block shows some example configuration for the Mongo instance using the spring configuration.

    <bean id="mongoDb" class="com.mongodb.Mongo">
        <constructor-arg index="0">
            <list value-type="com.mongodb.ServerAddress">
                <bean class="com.mongodb.ServerAddress">
                    <constructor-arg index="0" value="localhost"/>
                    <constructor-arg index="1" value="27017"/>
                </bean>
                <bean class="com.mongodb.ServerAddress">
                    <constructor-arg index="0" value="localhost"/>
                    <constructor-arg index="1" value="27018"/>
                </bean>
                <bean class="com.mongodb.ServerAddress">
                    <constructor-arg index="0" value="localhost"/>
                    <constructor-arg index="1" value="27019"/>
                </bean>
            </list>
        </constructor-arg>
    </bean>

Not to hard is it? Of course this is only very basic usage. There is more to learn in this area, a lot more. One way to learn is to experiment, use the command rs.help() to learn about the commands you have available for the Replication Set. The last thing I want to mention is the web client that you can enable. Pass –rest to the startup command and you can browse to the following url: http://localhost:28019/ and for the status of the replication set: http://localhost:28019/_replSet, This is by default available using the port for the mongodb instance added with 1000. The following screen dump shows the client in action:

That is enough for now, I’ll keep on working with Mongo. Stay tuned for more blog posts about Mongo.

If you want to learn more about Mongo I can recommend the book that is currently being written at manning:

http://manning.com/banker/

Not a lot of chapters available at the time of writing, but I like what I have seen so far.

Test fixtures are now part of the axon-test module. These fixtures allow you to [...]]]> Today, I released version 0.6 of the Axon Framework. 0.6 has many new features and is another step towards full production readiness. There is still some work to do, but first, let’s take a look at what has changed…

Test fixtures are now part of the axon-test module. These fixtures allow you to test your command handling logic based on events and commands. You define these tests in a given-when-then style: given these past events, when I execute this command, I expect these events to occur.

The CommandBus interface now allows for asynchronous command dispatching. Instead of using a return value, a Callback can be given to the command bus if you wish to be notified of the result of command execution.

The repositories make use of a UnitOfWork instance, which keeps track of changed aggregates and generated events. Instead of saving each aggregate separately, the UnitOfWork can be committed, causing changed aggregates to be stored, and events to be dispatched. With the new SimpleUnitOfWorkInterceptor or the SpringTransactionalInterceptor, it is no longer necessary to call repository.save(). In fact, you are discouraged from doing so.

Repositories are now capable of detecting conflicting modifications. When loading an aggregate, you may pass in the expected version of the aggregate. An exception is raised if that version does not match the actual version.

Event sourcing repositories allow for a more advanced way of detecting conflicts. Sometimes, not all concurrent modification are in conflict with each other. One user may very well change the shipping address of an order, while another user is adding items. Other modifications, however, are clearly conflicting, such as one user marking an order as shipped, and another one adding a product. For this purpose, you can register a ConflictResolver with the repository. This conflict resolver can, based on unseen and newly applied events, decide whether the changes made by the second user are accepted.

Axon now provides a mechanism to trigger snapshot creation based on the number of events needed to load to reconstitute an aggregate. When the number of events exceeds a given threshold, a snapshot is created and stored in the Event Store.

The SimpleCommandBus and SimpleEventBus now expose statistics over JMX. Although currently quite limited, the statistics will be improved in the coming versions.

All of these features help making applications with CQRS-based architectures even easier. But we’re not there yet. The coming months, we will try to make it even easier with features like Event versioning, support for aggregates with multiple entities, and whatever comes to mind in Axon’s growing community.

For more information about the Axon Framework, see www.axonframework.org.

Besides some changes to existing building blocks, such as the event bus, which is now much more powerful, the [...]]]> Today, I finalized the 0.5 release of the Axon Framework. There is quite a number of changes since the 0.4 version. The 0.5 version is a major step towards production readiness of the framework.

Besides some changes to existing building blocks, such as the event bus, which is now much more powerful, the 0.5 version also includes some new features.

Read on to find out more.

New features

• Code restructuring. The package structure has been changed to better reflect the different architectural components Axon Framework provides. It should be easier to find the one you’re looking for.
• Command Bus. The command bus is added to Axon. It provides you the ability to explicitly define commands and dispatch them to your command handlers. Furthermore, the command bus provides you the ability to process commands regardless of their type using interceptors. This is useful for, for example, logging, authorization and correlation of incoming commands.
• JPA Event Store. The easiest CQRS configuration is on using full-consistency. That means everything should run within a single transaction. Since transactions over multiple data sources involve a huge performance penalty, Axon provides a JPA Event Store. Its performance is not as good as the FileSystem version, but is does provide transaction support.
• Easy switching between full-consistency and eventual consistency. You can easily choose to process all commands and related events inside a single transaction, or to handle events asynchronously. Choosing for consistency or high-performance is just a matter of configuration. No coding required.
• Per-event listener configuration of asynchronous processing. It is now possible to decide on synchronous vs asynchronous event processing for each event handler individually, just by adding an annotation. If you configure a transaction manager for your event listeners, Axon will process the events in batches and manage the transactions around them.
• Support for rolling snapshots. All event stores will automatically pick up snapshot events. Snapshot events are an important performance booster when aggregates generate a lot of events. Instead of reading all passed events, the event store just needs to read the last snapshot event and the regular events created since the snapshot.
• Transactional Event Processing. Configuring transactions in asynchronous event processing is now a lot easier. 0.5 includes a SpringTransactionManager you can use in combination with Spring’s PlatformTransactionManager.
• Major documentation update. The documentation has been restructured to make it easier to find what you’re looking for.

Maven Central

Where the 0.4 version required configuration of a repository in your project’s pom.xml, the 0.5 version doesn’t. All required artifacts are available in the maven central repository.

Workshop and professional support

We believe that the 0.5 version of Axon Framework is a major step towards production readiness. Therefore, JTeam has decided to provide professional support for the Axon Framework and organize workshops to get you acquainted with the numerous features and choices involved with CQRS.

The first workshop is planned for Friday May 21st in Amsterdam, The Netherlands. For more information, visit http://www.jteam.nl/training/workshop/cqrs-axon-framework-training-workshop.html.

Getting started

Want to get started? Visit www.axonframework.org and download the reference guide. That should contain enough information to get you started. If you still have questions, drop me a message.

Command Query Responsibility Segregation (CQRS) is an architectural style that makes a clear distinction between commands, which tell an application to do something, and queries, which are requests for information from an application. This distinction comes from the fact that the requirements (and thus also the model) for the execution and validation of [...]]]>  

Command Query Responsibility Segregation (CQRS) is an architectural style that makes a clear distinction between commands, which tell an application to do something, and queries, which are requests for information from an application. This distinction comes from the fact that the requirements (and thus also the model) for the execution and validation of commands are significantly different than those for queries. Events play an important role in the synchronization of application state resulting from executed command.

Applying a CQRS style architecture involves the development of quite a lot of “plumbing” code: event dispatching, asynchronous event processing, transactions, etc. cqrs4j, an Apache 2 licensed open source framework, takes care of all the plumbing for you. Read on to find out how…

A brief introduction to CQRS

As I stated above, CQRS makes a distinction between the model that validates and executes commands and the model that is used for providing state information. This is quite significantly different than how most (web)app applications are build nowadays. In fact, the model used for commands (the box named “Domain” in the image below), does not expose any state, at all. You might wonder, but how do I know what to show in the front end? That comes directly from your data sources using a thin data layer. I’ll explain how the data gets there in a minute.

When a command comes in, it will load an aggregate from the repository and execute certain operations on it. As a result of these operations, the aggregate produces events, which are picked up for storage by the repository and for dispatching by the event bus. The event bus will dispatch each event to all (interested) event handlers. Some of these event handlers will perform actions on other (related) aggregates, some others will update the database tables they manage.

Having handlers update the data in the database means that your tables do not have to be normalized anymore. Instead, CQRS allows you to optimize your tables for the way you want to query them. This makes the data layer processing your queries really simple, and maintainable.

Furthermore, since all state changes are initiated by events, these events become a reliable source for an audit trail. By storing these events, you have an audit trail that you can use to replay the entire application history. Instead of just seeing “current application state” only, you can see all the changes that have led to the current state, providing valuable information trying to find bugs or deal with customer complaints.

The asynchronous and event driven nature of CQRS makes it extremely valuable for complex applications that have different views on the information in the application. Integration with third party systems that need to be notified of certain changes in your application –and vice versa–  is a lot easier if you use an event driven approach. And since event handling is done asynchronously, the application is more responsive and easier to scale.

But as you notice, there is quite a lot of processing and pushing around of events. When you have a customer breathing up your neck, you don’t want to be developing infrastructure code. You would want to be focusing on the business logic, which is quite complex by itself.

cqrs4j

cqrs4j is a Spring-oriented framework that provides the most important building blocks of a CQRS architecture. Creating an aggregate becomes really simple. You don’t have to worry about managing the storage and dispatching of (uncommitted) events. Event sourcing becomes as easy as wiring two beans in your application context.

Annotation support

cqrs4j comes with out-of-the-box annotation support. This makes is really easy to wire event handler methods. cqrs4j can automatically subscribe all your event handlers to the event bus and delegate all relevant events to the appropriate event handlers. Enabling annotation support is as easy as wiring a single bean in your application context.

Spring Integration support

Spring Integration is a framework that allows easy developments of a Messaging systems using the pipes-and-filters architecture. This fits nicely with most of the event dispatching process of CQRS. cqrs4j has support for Spring Integration, which allows you to publish all events as messages on a Spring Integration channel. Sending messages through JMS queues, via email, or through file system storage will only take a few lines of (XML) configuration.

Transaction support

If you update your database tables through incoming events, dealing with them one-by-one in a transaction can become time consuming and take up too much resources of your database. With cqrs4j, you can configure transactions just by setting the @Transactional annotation on your event handlers. You can also configure how many events should be handled in a single transaction.

cqrs4j project page

cqrs4j is an open source project, licensed under the Apache 2 license. Visit the project home page for the latest downloads, documentation and source code at code.google.com/p/cqrs4j.

We welcome your feedback

If you have any requests, remarks or other feedback, please let us know. You can report bugs and improvement requests on the issues page. You can also leave a message via the contact page or by leaving a comment.

Further reading

I have some more CQRS related blog articles coming up, but there are already quite a few around. Here is a few that helped me get started:

• Greg Young @ QCon: Unshackle your domain
• CQRS a la Greg Young
• CQRS – The Domain Events
• CQRS – Domain State
• DDDD – Why I love CQRS

What are we planning to do? We [...]]]> Today we release the website of a new User group for all Domain Driven Design enthusiasts. This user group is meant to facilitate all experienced DDD people to unity and share ideas/experiences. We also would like to help starters getting up to speed learning more about DDD

What are we planning to do? We are planning (bi-)monthly events. During these events people can share ideas in a presentation, discussions. We might have (international) guests coming in to talk about Domain Driven Design. Everything is focused around knowledge sharing. I suggest to check the website for more details.

The user group is connected to the domain driven design website hosted by Eric Evens and others.

If you are up to it, feel free to register for the kick-off event that is taking place the 8th of September. You can use the form on the website to register.

I hope all people get as enthusiastic as we are.

regards Jettro and Allard

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 [...]]]> 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

Authorization Concepts

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.

State Machine

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).

Child/Parent References

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.

Constraints

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)

Privileges

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.