Modelling restful properties


I’ve recently been playing with Liberty and JAX-RS and in an effort to remember some of what I’ve discovered, I’m going to try and keep a few notes and post them here, probably along with a few questions. If anyone else finds them useful, or knows the answers, that’s a bonus!!

To start with Creating an efficient REST API with HTTP provides a nice overview of REST APIs and JAX-RS basics has a great simple sample application to get going with… and break!

JAXRSServiceModel_Main

Armed with the basics I thought it would be interesting to model the sample application to compare the working code with what Rational Software Architect (RSA) would generate for me. Obviously that’s not the most complex model in the world but it was good to have a few examples to follow:

(Those articles made much more sense when I’d tracked down all the likely looking JAXRS, REST and UML features in the RSA installer!)

Before generating any code, it was quite nice to get some basic API documentation out of the model. Not as fancy as using Swagger UI but certainly better than no documentation!

systemproperties-apidoc

It’s only a start but that’s all for part 1. Hopefully there’ll be more posts at some point when I get further, probably along these lines:

  • Creating an OSGi Web project and generating some code
  • Using a REST client to check it works, including a puzzling Wink problem
  • Adding some debug
  • Expanding the sample with some awkward long running processing
  • Deploying to Bluemix
  • Anything else I encounter along the way!

If you know of any good articles/books/fancy new media that would help, please leave recommendations below. If there are better ways to design REST services (Swagger looks interesting but I haven’t had a chance to investigate), please share them. And any other tips, comments, or questions of your own are also very welcome!

 

Advertisement

Conference User Model


I hope to get round to blogging about the actual Code Generation conference at some point but this is about another Code Generation conference app. I’ve been playing with a user model based on an example at the conference and, since I mentioned the user interface generator to a few people, I thought it might be useful to share a few diagrams from the model here. If you were at the conference, and/or have looked at the Code Generation 2011 Android app, you’ll probably recognise these basic entities:

(At this point I had to stop myself going a bit mad with user objects for venues, rooms, capacities, etc. etc. etc.!)

Instead of focusing on the look and feel of a user interface, user modelling allows you to create a specification of a system from the user’s point of view. So, for example, a conference delegate might have a goal of attending a conference, which would consist of a number of tasks, like registering for the conference. The diagram below shows part of the model, with a simple task to view the available sessions:

By default, the <<select>> and <<view>> keywords on the associations between the View sessions task and Session object will generate the following activity diagram:

The user interface generator handles on screen presentation of the user objects for each of the <<ui_change>> actions in the activity diagram, while the <<command>> actions represent code that must be written to fetch data from some system. This could be code to call MDM Server transactions and, since the user interface generator is provided with MDM Server, this code can also be generated to create a basic sample data maintenance user interface. There’s no technical reason to prevent the commands getting data using any web services, or direct from a database, or anywhere really. To test drive a UI, there’s an option to generate all the code necessary for a simple file based data store for example.

Having generated enough of the user interface to view sessions, I wanted to add a way to favourite sessions like the Android app. The next diagram shows a customised activity diagram to do this:

You can see that after the UI change to view a selected session, there is now a decision with two options; there’s a Favourite flow in addition to the previous Done flow, which appears as another button in the UI. I could change the model again to make it possible to mark multiple sessions as favourites at the same time, which would require changing the cardinality of the task to user object relationship, as well as another decision node in the activity diagram. The last diagram from the model shows a more complex activity diagram that has a similar extra decision node, but for a task to manage conference tracks:

If you’re interested in finding out more about user modelling and the user interface generator, there’s an article on developerWorks. and some related blog posts. I’ve also blogged here about user modelling in the past.

Any questions or comments would be very welcome indeed.

Code Generation 2011


I’ve been having a closer look at the Code Generation event programme since my booking was confirmed. I can’t quite decide between a few of the sessions, but at the moment I think I’m most likely to choose these:

Day 1

Day 2

That could change though, so I’d be interested to hear any recommendations. Unfortunately I won’t be there for the full conference, so don’t mention day 3!

Now I just need to organise somewhere to stay, and work out the chances of being able to park in Cambridge!

Master Information Hub: Customising a Maintenance UI


This is the third in a series of posts introducing Master Information Hub (MIH) development using the MIH Workbench. If you want to follow along with the example, you’ll need to take a look at the previous posts:

  1. Master Information Hub: Getting Started
  2. Master Information Hub: Social Bookmark Services

This post is just a few hints to get you started customising a maintenance UI generated for an MIH addition.

UML Diagrams

The user model generated in the previous post does not contain any diagrams. You can navigate and manipulate the model directly in the Project Explorer view but it is useful to have diagrams to show different aspects of the user model which you’re interested in, or when making modifications. There are a couple of quick ways to get UML diagrams depending on what you need them for.

If you’re just exploring the generated user model, Browse Diagrams can be handy. Right click on part of the model in the Project Explorer and choose, Visualize > Explore in Browse Diagram. For example, the diagram for Maintain Bookmark task looks like this:

Alternatively, when you want complete control over what to include in the diagram, or for editing the model, you can create a new Freeform Diagram. For the first modification to the user model I’m going to create a new freeform diagram called SocialBookmarkServices Domain. Right click on the model in Project Explorer and choose Add Diagram > Freeform Diagram. You can drag any model elements you’re interested in on to the new diagram from the project explorer, and you can add related elements automatically. For example, I added the following three user tasks:

…which leads neatly on to creating a domain for these user tasks.

SocialBookmarkServices Domain

The default user model does not include any domains, so when you initially log in you always have to switch to the goal view. One of Iain Duncan’s MDM Workbench blog posts explains how you can modify a generated user interface to only display the goal navigation method. To avoid making any code changes to the generated user interface, I’m going to create a new User Domain, so you can use both navigation methods instead. This approach would probably be more useful if your maintenance UI covers multiple modules.

Click on User Domain in the User Model section of the model palette, as shown below, and add it to the diagram.

Then use the Dynamic Connection to associate tasks to the new domain. You should have a diagram that looks something like this:

Use the Generate User Interface transformation configuration to regenerate the user interface; open the Generate User Interface.tc file and press the Run button on the Main tab. You can also use the context menu option to run the transformation, which is under Transform when you right click on the Generate User Interface.tc file.

Republish the web application and log in to see the new domain. You’ll notice that there are only two user tasks under the SocialBookmarkServices domain. This is because the addBookmark task appears in the user model as a non navigable supporting task for the Query Data goal. We’ll fix that in the next section.

Create Data Goal

To get the addBookmark task to appear in the domain navigation you could just set the isNavigable property to True on the supporting task stereotype. Instead, I’m going to go further and create a new User Goal for adding data.

Create a new Add Data Goal freeform diagram. Use the palette to create a new User Goal called Add Data Goal. Drag the Default Role user role and the addBookmark user task on to the diagram. Then simply associate both of these to the new goal using the Dynamic Connection, as shown here:

Regenerate and republish the web application and you should now see all three tasks in the domain navigation, plus a new goal in the goal navigation. Those task names don’t look all that friendly though but we change improve them very easily.

Task Names

The default task names are based on names from the module model, which may be obscure for someone using the maintenance UI. The task names aren’t actually too bad for the bookmark example but I would still prefer something a little less internal looking. The names on the UI are fully translatable using properties files in the UI’s help project, which makes it very easy to give them sensible names without needing to modify the generated user model.

Take a look in the generated ExampleHubUIHelp project. I needed to edit the orgModel_en_GB.properties file which was in the resources\i18n\ folder. Just edit the appropriate properties to modify what appears on the user interface, for example:

UserTask.AddBookmark.name=Add Bookmark

UserTask.GetBookmark.name=Get Bookmark

UserTask.UpdateBookmark.name=Update Bookmark

After republishing the web application, this what all the modifications look like:

These are just a few ideas to get you started. If you change anything in the generated user model, make sure you remove the generated stereotype, otherwise your change may be lost if you regenerate the user model.

The maintenance UI looks slightly better after the modifications above, but it would be a bit easier to use if the SocialBookmarkServices model had some transactions that worked without knowing the primary key of all the bookmarks. Changing that will require some custom code in the MIH module as well as user model modifications, which should be enough for another post!

Updated: Added link to Adding related elements to a UML diagram post on developerWorks. (25 June 2010)

Master Information Hub: Social Bookmark Services


This is the second in a series of posts introducing Master Information Hub (MIH) development using the MIH Workbench. This time you’ll see how quick and easy it is to extend MIH and create a maintenance UI for your new domain, with no coding required. If you want to try this exercise yourself, make sure you have set up the development environment first. The sample I’ll be building is based on social bookmarking, but you could build any data model you like.

Create a Social Bookmark Services module

To begin, create a new Hub Module Project to work on your data model. Open the File menu and choose New > Project…, then look for InfoSphere Master Information Hub > Hub Module Project.

Give the project a suitable name, and enter the Java package name and service namespace you want to use. If this is the first module project in the workspace, you will also need to give the application a name and enter the database schema name. For example:

You should now have a new project containing an empty module model, which will be opened in the module editor. Switch to the SocialBookmarkServices editor’s Model page; this is where you will enter the data model for the new module. To start with, add a new entity and add a few simple attributes as follows.

Right click on the SocialBookmarkServices folder and choose New > Entity. Call the entity Bookmark. Next, right click on the Bookmark entity and choose New > Attribute to add each of the following attributes, making sure that all of the attributes have the Persistent option checked and the Type set to String:

  • Title
  • URL
  • Notes (check the Nullable option for this attribute to make it optional)

You should end up with something that looks like this:

Click on the Validate Model action to make sure there are no problems with the model, and fix any problems that are reported. Once the model validates successfully, click the Generate Code action to generate the MIH module implementation. Now for the fiddly bit…

Deploy the new hub application

When the code generation has finished, you need to follow a few additional manual steps to include the new module in the MIH application. Complete the tasks described in the following information center topic:

Modifying InfoSphere Master Information Hub using Workbench tools
> Developing InfoSphere Master Information Hub extensions and additions
> Deploying additions and extensions

We will only be using web services for this example, not XML over RMI, so you only need to complete these tasks:

  • Modifying the InfoSphere Master Information Hub database
  • Assembling the required property files
  • Preparing for deployment

Note: when running in the test environment, the server will have the contents of the CustomerResources project on its classpath, but to deploy an application on a production server, the properties.jar and DWLSchema.jar files in the MIH EAR need to be manually updated with the contents of the CustomerResources project.

Now the extended MIH application is ready to publish and use. If you followed the instructions in step 4 of the getting started post, you can right click on your server in the Servers view and choose Publish.

Create a hub client

That’s the awkward bit over. Now that the MIH application is deployed and running, you are likely to want to connect to it and run transactions. One way to simplify this is by creating a hub web service client. This is the way the automatically generated maintenance UI will connect to the MIH application, so create one now. Open the File menu and choose New > Project…, then look for InfoSphere Master Information Hub > Hub Web Service Client Project. I’ve based the client project name on the hub base name, since you probably won’t want a different client for every module. Fill in the rest of the fields and click next. These are the settings I used:

On the next page, make sure you select the OperationalCodeTypeService as well as the web services for the module you just created, as shown:

Click finish and wait for code generation to complete. Now for the fun bit!

Create a hub maintenance UI

One of the new features in the latest workbench is the ability to automatically generate a basic maintenance user interface. This uses information from module models in the client project to create a UML user model for the User Interface Generator. Even the command beans are taken care of automatically when the user interface is generated, connecting to your MIH application using the web service client. As before, open the File menu and choose New > Project…. This time you need InfoSphere Master Information Hub > Hub User Interface Project. Again, I’ve based the project name on the hub base name. Enter a Java package name for the generated code, and pick the target runtime you’re using. Click finish and wait for code generation to complete.

That’s all there is to it; deploy the generated web application to the same server as the MIH application using RSA. If you followed the same example, and your test server is using the default ports, you can open the maintenance UI using the following address.

http://localhost:9080/ExampleHubUI/

Note: if your server is using a different port, you will need to update the service URLs used by the web service client. These are defined by the ejbModule/client.properties file in the web service client project.

The generated user interface should provide a simple starting point for maintaining data in a custom MIH application, and it’s a great tool for development and demo purposes. In future posts I hope to show some simple ways you might want to alter the generated user model to customise this maintenance UI.

Creating user interfaces another way


The paragraph about the user interface generator in my last post, or my other recent attempt to explain what it does, don’t really tell you very much. I hope this quick festive example provides a better idea about how user modeling and code generation can speed up user interface development.

First I needed to think of something Christmassy that might need a simple user interface. I apologise in advance, but I chose Christmas cracker jokes!! On the plus side, they’re really simple, and a basic create, read, update and delete interface makes perfect sense. So, I got started by creating a CRUD Joke UML diagram… and about five minutes later I stopped laughing to myself! Well, it’s funnier than most cracker jokes!

Anyway, the UML tools we provide for user modeling enable you to create a new user object with the default CRUD tasks in one go. Here’s what it looks like:

User model

Next, because the user modeling is focused on the roles and goals of users, I added a few other bits just for the demo:

Roles and goals

Perhaps a better role would have been, “Joke quality monitor”, with a goal of, “Maximise Christmas laughter”… or should that be minimise… well, you get the idea!

That’s pretty much it, I can then click the “Generate User Interface…” menu option, deploy the EAR it creates to an application server and fire up my web browser. It took longer to get this far through the blog post than it did to get a working user interface (admittedly I’m a very slow writer, but still, I think that’s pretty good).

Generated user interface

(Thanks to a very old BBC article for that joke!)

The activity diagram behind the modify task above looks like this:

Activity diagram

At some point you need to put real code in for the commands to interact with the back end system, whatever that might be, but to start with the tool will generate a default implementation so you can quickly prototype and test the UI.

So that’s all there is to creating cracking user interfaces.