The main components of Logistics structure focuses on the following elements:

• Network,
• Communication,
• Planning and
• Integration.

This concerns both functional and financial but also technical aspects. Such high complex and dynamic evolving systems can only be represented and supported in structured and well defined technical environments. These systems are prerequisites to guarantee a flexible and extendable Logistics structures consisting of different parties, locations, rules and processes.

Technical Requirements of a Logistic Solution

A logical framework with an appropriate technical foundation has the ability to support the various requirements of Logistics processes efficiently. Such framework contains:

• Flexible UIs.
• A Service-Oriented Architecture with flexible, standardized components.
• A communication layer or module.
• An integration layer or module (technical and professional) where available standards can be implemented.
• A standardized and public interfaces of external sources.

Business Requirements of a Logistic Solution

To implement logistic processes not only technical requirements need to be fulfilled. Business experiences from logistics needs and projects are the quintessence for a successful logistic concept. It requires a balance and combination of individual functional requirements and standardized, technical implementation.

An example for this are our in-depth know how and experiences especially in the Railway area. From our experiences in many international projects we can use our expertise especially in two strategic areas. The areas are resource planning and communication in the process of logistic productions. Both areas have a significant influence of the efficiency of train operating companies.

Introduction

Many projects are initiated too fast, only focusing at some parts of its feasibility, and fail. An assumed (or real) pressure, generated due to time and budget reasons, forces to a fast and unprepared project kick off. This is the start of failure.

Our projects are not only technically prepared and executed but also with necessary methodologies and business know how.

This guarantees a successful, efficient and professional project realization.

Analysis and Specification

Basis of a project kick off is a clear overall understanding about project methodologies, its set up and execution where the customer is tightly involved. This makes the project transparent and controllable through every step.

The project methodology consists mainly of the following steps:

• A feasibility study: Based on the main processes, use cases and the overall technical architecture.
  Result: an initial project plan as basis for required resources and project deliverables. Only when the customer has approved the project plan the next step can be tackled.
• A specification phase: Based on the Use Cases the functional, non-functional and technical specifications are detailed. The test scenarios and test cases are defined in parallel.
  Result: the test documents will be the basis for the final acceptance test of the solution. This phase requires a tight and active involvement of the customer.

Has the customer approve this phase the development of the solution can be triggered.

Development and Approval of the Solution

This phase starts with a pilot. Here it the customer gets a hands-on of the user interfaces (as detailed as possible) and allows simultaneously to do first (“desktop”) tests of the key functionalities. After the validation of the pilot by the customer the project plan will be fixed and the development starts.

He brings more than 30 years of business experiences especially in the areas of Railway, Logistics and Merchandise Information Systems. He started his business in the retail industry as consultant and project manager developing Merchandise Information Systems and appropriate Logistics applications especially in the warehousing and transportation area. As a senior management consultant and program manager at CSC Germany and within spin offs of CSC he was mainly focused on logistic projects. Within this business area he built up relationships to near shore partners responsible for the technical part of the projects. Organizational structures and procedures has been created and installed to handle large-scale projects successfully. These projects have been successfully performed for international customers in the postal and railway area.

AlienSource and its team has more than 20 years experience and best contacts in the software, Railway and Logistics industries. The team has successfully executed projects implementing large-scale software solutions and products in several countries like Switzerland, Germany, Belgium and Sweden.

Within a logistics area, optimality is an obvious concern. But optimality in this context is often con-fused with pure mathematical optimality.

The real challenge of solving real-life industrial logistics problems is balancing the following criteria:

• Response-time,
• Robustness,
• User-friendliness,
• Maintainability and of course
• Mathematical optimality.

This is in fact a meta-optimization problem imposed to us by commercial/customer requirements.

Optimization taking hours to run are usually not acceptable, because in a dynamic logistics setting both reactive capabilities as well as a predictive capabilities are important. Small variations in the in-put data should not cause big variations in the outcome of the algorithm (aka no bull whip effect). Al-so the produced results should be clear and explainable at end-user level of understanding. The need for reconfiguration of the optimization algorithm every time something changes in the problem de-scription should be kept as minimal as possible. Since many of the mathematical optimization prob-lems within logistics are known to be NP-hard (not solved to proven optimality in polynomial com-plexity), optimality of the solution usually cannot be guaranteed.

We tackle the above described challenge by the hybrid use of different optimization techniques com-ing from different schools of thought ranging from:

• Mathematical programming techniques to
• Greedy heuristic solving techniques to
• Constraint logic programming techniques and to
• Neighborhood search techniques.

Packaged in a solver, such algorithms is ideal for an intelligent and interactive support for planning tools. For this we have defined the term “Planning Assistance Support System (PASS)”.

Designing Solvers for a Planning Assistance Support System (PASS)

A Meta Optimization Problem

Balancing potentially conflicting objectives is the nature of any optimization problem. Hence one could say that the design of a good logistics solver is in fact an optimization problem on its own, alt-hough it plays at a meta level. The following concerns need to be balanced against each other when designing a solver for a logistics environment.

Response Time Concerns

In a logistics area we are typically facing a big variety in problem sizes. An optimization problem could range from a 100 activities to 100 000 activities (or even more), depending on the level of decision making (yearly, monthly, weekly or daily decision making) the optimization is focusing on. At the same time fast response times are required because of a high degree of interactivity between end-user and planning tool. Also response time requirements can vary from seconds until minutes until hours, depending on the level of decision making the opti-mization is focusing on. Daily decision making obviously has much more a reactive nature than a pre-dictive nature while yearly decision making has more a predictive than reactive nature.

Robustness Concerns

A logistics environment is by its very nature a dynamic environment. In contrast to a production en-vironment its activities do not take place in a closed world like a factory, but it takes place in the world outside. On the one hand a solver must be quick to respond to such dynamic changes (see re-sponse time concerns above), on the other hand one does not want the solver to produce very dif-ferent results when only a relatively small part of the input data has changed. In a pure mathematical optimization context this is exactly what would happen. This effect is commonly known as the bull whip effect (aka butterfly effect). Since pure mathematical solvers are solely focused on reaching an optimum they have no concern for previous results. Making sure that the solver “remembers” previ-ously generated solutions and tries to stick to them as closely as possible are very important con-cerns.

User-Friendliness Concerns

Because of a high degree of interactivity between end-user and planning tool it is also important that the solver produces clear results which are explainable and justifiable at end-user level of understand-ing of the logistics problem.

Even stronger we would like to give the (advanced) end-user also control over the nature and out-come of the produced results. This can be realized by letting the (advanced) end-user determine the balance between different cost objectives via a mechanism of relative weight control. These relative weight settings could be saved under different simulation scenarios. The (advanced) end-user could then produce different solver results: one per each scenario. Comparing those different solver results and choosing the most adequate one for the given situation we see as an important form of interac-tion between solver and end-user.

Maintenance Concerns

A logistics environment is also dynamic at an organizational level. Its organization is constantly in flux undergoing streamlining as well as expansion changes.

A solver with a black box (pure mathematical) model would have to be revisited each time a substan-tial reorganization takes place. The black box model does not have the ability to automatically adapt itself to such fundamental changes which would require a remodeling of the solver by the original de-signer. We try to aim for better forms of maintainability where in most cases the solver automatically adapts itself to the change or where the end-user is capable on his own to perform the necessary maintenance tasks without having to deeply dive into the engine of the solver, but by allowing him to maintain master data in a layer above the solver engine. This of course puts some strong require-ments towards the design of the solver.

Optimality Concerns

Last but not least (mathematical) optimality remains a valuable concern in a logistics environment. But one has to realize that most of its real-live optimization problems translate into so-called Non Poly-nomial mathematical optimization problems (NP in short), which means that there are no known al-gorithms that can reach a proven optimum in polynomial time complexity. In layman’s terms: the search space basically explodes from the vast amount of combinatorial possibilities such that an exact approach would take almost infinite time to reach a conclusion. Therefore it is very important to set yourself realistic goals of near optimality instead of proven optimality when designing a solver for a logistics environment.

Hybrid Algorithms

In order to be able to balance the different meta-objectives (described above), one is forced to make hybrid use of different kinds of optimization techniques. Each of the techniques in their pure form prescribes a too strict paradigm. Only through hybridization can one create enough flexibility for such a balancing act.

The following overview of techniques and concepts are the candidates we are considering for hybrid design of solvers:

• Mathematical programming techniques: This is the oldest and most mature category. For solv-ing optimization problems.
• Heuristic techniques: Both domain specific rules of thumb as well as generic heuristics belong to this category.
• Constraint logic programming techniques.´
• Neighborhood/local search techniques: These techniques are also called meta-heuristics. They have in common that they are metaphors of natural phenomenon of optimization.
• Multi-agent techniques: These are techniques of distributing a problem amongst multiple col-laborating agents. Such that each agent on its own has a simpler problem to solve than the global problem. Through the collaboration of the agents this is not just a simple problem sub-division but the overall global problem remains in sight.

Mathematical Programming Techniques

Mathematical programming looks at the problem as solving a set of equations (and inequalities) com-bined with an objective function to minimize or maximize. It is deterministic by nature and complete. Some examples of mathematical techniques are:

• Linear Programming
• Mixed Integer Linear Programming
• Lagrangian Relaxation
• Column Generation

Heuristic Techniques

Heuristic techniques get their inspiration from Operations Research, Artificial Intelligence, Common sense problem solving using domain specific rules of thumb. Heuristics try to address real-life indus-trial size problems by using deterministic and prescriptive techniques. They usually do not perform a complete search but try to cut corners by choosing parts of the search space which have a high like-lihood of containing good solutions. Some examples of techniques:

• The Greedy Traveling Salesman heuristics
• Expert Systems
• Sorting and Grouping
• A priori bottleneck identification

Constraint Logic Programming Techniques

Constraint logic programming techniques get their inspiration from logic programming, later devel-opments in AI, Graph theory. Constraints in this context are a descriptive generalization of an equa-tion (mathematical) and a rule (heuristic). The algorithms used are constructive (variable sequence and value sequence) using a priori consistency checking techniques (test and generate) and backtrack-ing (generate and test) techniques. Some examples of techniques:

• Variable and value ordering heuristics
• Arc Consistency checking
• Constraint Propagation
• Cut-Set methods

Neighborhood / Local Search Techniques

Neighborhood/local search techniques get their inspiration from the computational intelligence community, chaos theory, and natural phenomenon of self-organization. The algorithms feature a lo-cal repair metaphor with a strong random “trial and error” flavor. It is a non deterministic search with no specific constraint model support. In general no explicit memory of previously visited solutions is maintained. Some examples of techniques:

• Simulated annealing
• Tabu search
• Genetic algorithms
• Swarm
• Ant colony

Multi-Agent Techniques

Multi-agent techniques get their inspiration from the worldwide internet community. The key con-cept behind multi-agent techniques are to let distributed autonomous processes (agents) solve the problem through collaboration and/or competition and/or communication in a distributed model. It follows a distributed model with limited formal model support. It is a non deterministic search with no specific constraint model support. Some examples of techniques:

• Hierarchical: delegation, conflict resolution, etc.
• Tight collaboration: e.g. the 3-agent constraint satisfaction algorithm
• Self-organizing: broadcast, bid, optimal brokering
• Colony Optimization: Ant Colony, swarms or flocks

Kris Dockx holds a fellowship at the Katholieke Universiteit Leuven, Hogenheuvelcollege, Belgium. He brings 20 years of experience in supply chain optimization technology in various industries and is specialized in mathematical programming, constraint satisfaction, meta-heuristics and other local search optimization algorithms for planning, scheduling and campaigning applications.

He was the intellectual co-founder and key architect of the university spin off TFP Engineering, a Belgian supply chain software vendor for the process industry, which commercialized his PhD results. TFP Engineering was acquired by SAP in 1996.

At SKYVA International, a US-based supply chain software vendor for manufacturing, services and logistics, he was the key architect of the plan agent framework. SKYVA was acquired by ABB in 2001. Its agent framework used at a project for the customer BLS formed the basis for Qnamic. Qnamic is a swiss based software vendor in the area of intelligent resource management for railway applications. Kris Dockx is currently employed as product manager of optimization at OM Partners. OM Partners is a Belgium based software vendor for supply chain applications for mill products, semi-process, paper and corrugated board industry.

AlienSource and its team has more than 20 years experience and best contacts in the software, Railway and Logistics industries. The team has successfully executed projects implementing large-scale software solutions and products in several countries like Switzerland, Germany, Belgium and Sweden.

1. Alien: How do you aim future-oriented solutions?
   Our strategy is to explore and achieve concepts and solutions!
2. Source: How do you deliver the best solution and highest quality?
   Our operations is to benefit from Open Source and proven solutions!

Watch in full size.
Download Quicktime to view this video.

Since this is only a teaser there is more to come! We keep you informed.

Tai Truong
CEO

You are not alone.

1. Today's IT infrastructure
2. Messaging as a best practice
3. Messaging key concepts
4. Using Enterprise Integration Patterns for Messaging
5. Next Blog: Spring Integration

I try to give a deeper explanation based on my experience since 2000 of doing integration for several customers. I am happy for further input and discussions. Please feel free to comment this Blog or contact me.

Today's IT infrastructure

Nowadays almost every enterprise is dealing with a heterogeneous system landscape. Its infrastructure is a conglomerate of applications:

• running on different platforms
• spread on different locations
• connected in a network

Within this landscape there are multiple applications exchanging data with another back and forth.
This integration of several applications are facing with the same challenges [EIP]:

• Networks are unreliable and slow
• Any application is different (by its programming language, operating platforms, and data format)
• Any application is changing on the long run

Messaging as a best practice

In an enterprise there are many applications integrating data from another. Ideally each integration scenario are implemented on the same centralized platform.
Integration where data are send to or received from another application can be seen as a communication of two or more applications.
There are 4 different integration styles of how communication can be achieved[EIP]:

1. File Transfer: an application exports data into a file which is then read by the target application(s).
2. Shared database: several applications are sharing the same database.
3. Remote Procedure Invocation: An application sends data directly to the target application(s).
4. Messaging: An application sends a message to a (queued) channel. Other applications listening to the channel can received the message. The communication is asynchronous since the message can be received at a later time.

Hohpe and Woolf points out why messaging is superior compared to the other approaches:
“The quick answer is that messaging is more immediate than File Transfer, better encapsulated than Shared Database, and more reliable than Remote Procedure Invocation.”, “Why Use Messaging?” on page xxxiii

Messaging (indirect communication) is the direct opposite of a remote procedure invocation where a sender and a receiver are connected through a queue. The responsibility of this message-oriented middleware is taken by a messaging system: it is responsible for receiving incoming messages from source applications, processing the messages through several channels and sending them to the target applications. Among this there are other responsibilities a messaging system is taking care of: system management, error logging and security.

Messaging key concepts

The messaging approach outlines two concepts where (1) applications are loosely coupled and (2) the messaging (communication) is asynchronously:

1. Loosely coupling: “Each [application] makes its requirements explicit and makes few assumptions about the other [application].”
2. Asynchronous communication: “Asynchronous communication is a mediated form of communication in which the sender and receiver are not concurrently engaged in communication.”

When talking about messaging I use the terms of Enterprise Integration Patterns as described below. At this point it is sufficient to know that messaging is an integration flow between several applications. Each integration flow is a process description using channels and endpoints. The first and latter endpoint are normally interfaces to an application.
Comparing the messaging approach with the other integration styles and in the context of a heterogeneous system landscape the advantages of loosely coupling and asynchronous communication are:
1. Loosely coupling

• There are legacy applications and their data format which cannot be directly influenced. In this case a messaging system can act as a mediator dealing with the given data and translates it into a common data format for further processing.
• On the long run applications in a system landscape are changing. This has an impact only on the application endpoint within the integration flow that needs to be changed in the messaging system. The remaining components of the integration flow keeps unchanged.
  A similar scenario is that an application might be replaced by or merged into another application. Here only the application endpoint needs to be changed or replaced.

2. Asynchronous communication

• Unlike a direct communication a messaging system follows a fire-and-forget principle: a sender can send a message and continue working without waiting for the processing of the receiver. The messaging system takes the responsibility for a reliable transmission. Even if the sender needs a reply (receiving another data) the messaging system can use a callback. Also in this case the sender does not have to wait for a response.
• In a system landscape applications might be for many reasons not available. A messaging system can queue messages and re-send them when an application is available.
• Another advantage of queuing messages is in case of high frequent data requests (like real-time scenarios) where the sender is flooded with lots of small message requests. A messaging system can control such an integration flow an aggregate all the messages into a single one.
• Since sender and receiver do not need to rely on each other their tasks on both sides are performed with a maximum. Just imagine both applications are running on servers with different CPUs. Each application can process on their best speed. There is no bottleneck to each other.

Using Enterprise Integration Patterns for Messaging

There are many possibilities to implement messaging for integration. When dealing with messaging there is no better way than using the Enterprise Integration Patterns (EIP). The book “Enterprise Integration Patterns” from Gregor Hohpe and Bobby Woolf is the de facto book about messaging solutions for enterprise integration.
EIP breaks down an integration scenario into into several parts. Each part is a pattern describing a specific solution. A pattern is a prescription of what needs to be done to solve a limited variety of problems. In that sense an integration scenario using the EIP pattern as a language is a combination of patterns guiding a message (of one or more applications) from the beginning to the end of the integration flow (to other applications).
A very good starting point is Hohpe's Site www.enterpriseintegrationpatterns.com. For a detailed description I strongly recommend Hohpe's and Woolf's book.
EIP provides patterns for the following messaging concepts:

(Message) Endpoints	This is the interface for communication between an application and the messaging system. In Spring Integration for example every component in the messaging system connected to the channel is an endpoint (like Router, Splitter, Translator, Aggregator etc.).
Message Channels	Data are transported within the messaging system through channels. There are various kinds of channels like: Point-to-Point-Channel, Publish-Subscribe-Channel, Datatype Channel, Deadletter Channel, Channel Adapter, Message Bus etc.
Messages	A message consists of two parts containing a header and a body. The body is the actual data an endpoint is sending to or receiving from a channel. A body message carries meta data like message id, origin and destination. Messages within the integration flow can be split, aggregated, routed, changed or trashed by endpoints.
Pipes and Filters	This architecture describes a chain of processing steps (Filters) that are connected by channels (Pipes).
Message Routers	This special endpoint navigates a message to a certain channel. A simple example is a routing based on the message itself. Depending on whether it is a CSV or XML message it routes it either to a CSV or XML channel.
Message Translators	Within an integration flow a message can be converted or changed for further processing and delivering in an appropriate data format for a target application.

Next Blog: Spring Integration

In my next blog I will write my experiences I have made with Spring Integration (SI). It made quite a lot of changes from the milestone releases until the current version 1.0.
I will try to outline:

• how consequently the Enterprise Integration Patterns is implemented by using a message bus with various kinds of channels and endpoints.
• advantages of SI using the Spring Framework like AOP, Dependency Injection, Annotation- or XML-based configuration.

By using and evaluating other integration frameworks I enjoyed the ease of use which I didn't know better since using Spring and Spring Integration. I can implement and use my existing integration components with no need of using or deriving from any Spring class. SI encapsulates all the message processing. POJOs can be used directly to send to any channels. No wrapping in a Message class is needed. But more about that will follow in my next Blog.

Tai
P.S.: Please share your opinion and feel free to leave a comment below (emails are not published) or contact me.

1. There is my professional life: employeed since 1995 I dare my first entrepreneurship as a consultant for software development and logistic processes.

2. The Java world: IBM will (most likely) takeover of Sun and Oracle in return will (most likely) takeover of Red Hat. There you might forget that JEE6 and Spring 3.0 is upon us. [Those were the days when Solarmetric came along without BEA and BEA without Oracle ]

From a global and political point of view we are sailing in different waters as well. Last year Barack Obama made a swept into a historic victory. The message he sent has reached many people all over the world: Yes we can!

And yes, we are also facing a financial and economical crisis. Yes, we are good in moaning and complaining about things that went wrong and could be done better.

Though I am optimistic about my future and those close to me.

And here I am, for all my lore: healthy, standing on my own feet, with basic equipment and ready to build something new with my bare hands.

With this blog I will share my opinions about:

1. Open Source and its Community
2. Java
3. Transport and Logistics

Java what? Isn't that some unknown big island? Yes, right. That's why I will ONLY focus on:

- JEE (and its upcoming major release 6)
- Spring (and its upcoming major release 3)
- Clustering and HA solutions
- Integration (with the usual suspects EIP, ESB, EAI and JBI)
- ORM (like JDO and JPA)

And what's so interesting about Transport and Logistics? Well this is the business I am doing since the last 9 years – with a soft spot for:

- Resource Planning
- Process Modelling (like trains on drivers and locomotives)
- Optimization and its goals in the strategic, tactical and operative planning process

So long Tai