Notice:

The Warehouse Management System Project is in the process of complete refactoring.

The changes include moving the RDB backend to the RDF datastore, addition of Drools Rules Engine for rule based Jini subscription criteria, new screen designs for both WinCE devices and the PC and the addition of Jabber support to allow for easy publication of events throughout the network. The Jabber functionality is replacing the current JXTA code and is a great improvement in terms of configuration and performance. At the moment we estimate the new WMS will be made available late in 2010 (Oct. Nov.).

WMS Overview and Jini Introduction

The WMS project was formed to provide basic warehousing functionality and to assist users in the collection, processing and integration of event data required by the Pharm2Phork system. The functionality is very basic and intended primarily for smaller users, as we were certian that larger users would have one in place already. We have included functionality to address the Inbound (Receiving, Putaway, Returns), Warehouse Management (Inventory Control, Replentishment , Slotting) and Outbound (Wave Planning, Picking, Pack and Ship) operations.

The system is built around JINI technology, specifically Java Spaces. Java Spaces provides a facility for the capture and retrieval of messages generated by events such as a bar code scan or tag read. As an entity (Order, Location etc.) moves through the various stages of its lifecycle, events create messages and these messages are sent to the 'Space'. The space allows other processes to subscribe and to be alterted when a message (based on subscription criteria) is available. The subscribing process then 'Takes' the message from the space for further processing, possibly rewriting it to the space with additional information which may alert another subscriber.

As an example, let us say that we have received an advance notification of an arrival of product. The notice generates a message in the space. When the load arrives, a process looking for receipts messages locates the specific message and reads its contents. The user then validates the receipt against the messages data and starts the process of storing the goods. Let us say that we received 24 pallets of an item. Upon receipt we might generate 24 messages of the type to be put away.

Each of these messages could then be retrieved by different people or processes and as they are stored their location is updated. At the end we have 24 inventory messages possibly showing a status of available. These messages could then be retrieved by a process looking for available inventory to say, book an order. When the order is booked, a message is placed into the space for the required number of product and possibly even the actual pallets that were to be used. In this case the fulfilment process would simply look for the items of that type in the space that were reserved for a particular order, generate picking messages with the location and product id. These messages are picked up by the picking process, location messages are updated as available, product messages are updated to in pick status and the goods are staged and shipped.

At the point the event takes place the message for the product and that of any location is updated to reflect the activity and new status. Several people could be involved in the picking, as each one would retrieve a message from the space, collect and stage that pallet in the defined staging area and complete the process, all in the absence of an underlying controlling process.

While on the surface this seems like business as usual, there are some major differences. Using spaces allows for collaborative processing of tasks with minimal marshalling requirements. Each person wishing to pick items for an order needs only to see if there are still items to be picked by looking for messages in the space. There either is a message or there is not. No ambiguity. There is also no main process required to keep track of what has been done. A quick search of the space shows the status of each message .The logical entities (pallets and locations) are virtualised in the system via messages in the space.

In fact, whole physical systems may be modelled in this way. Let us say we have a warehouse with 300 pallet locations. Each location is represented by a message which either has or does not have product stored within. The messages could have the space id, location, sub location etc. defined within their message body, as well as a reference to any products, and the status of the product such as reserved for a specific order or available.

In the above example if we were looking to store product we would look for messages representing locations without product, possibly searching within a specific area. We could then reserve these locations and possibly allocate individual pallets to the locations by updating their messages. Receipts staff would then retrieve these messages and put the goods away, again updating the location and product messages.

The real benefit here is simplicity. There are no complicated strategies for storage and retrieval to a database or to choreograph the overall process in any great detail. Processes look for messages which meet specific criteria, read these messages and then if they wish to proceed take the message from the space. That message is now gone, no longer available to be acted upon by any other process. When the activity has been completed or abandoned the message is updated and returned to the space for further processing by other processes looking for messages in that specific state.

The concept is simple, models the real world and promotes seamless cooperation between processes and users.In the next few pages we will outline the functionality and provide some concrete examples of real world use including integration with existing systems and sinking data to an internal database.