How to enable cookies in Linux Curl

Curl is an excellent tool to debug HTTP-related software. What curl does is transferring data from given URL.

Unfortunately by default curl doesn't store cookie values.

To enable cookies support in curl use -b (read cookie data file) and -c (write cookies data to file) options:

$ curl http://localhost/myApp -c cookieFile -b -c cookieFile
Cookie value: 1
$ curl http://localhost/myApp -c cookieFile -b -c cookieFile
Cookie value: 2

Business delegation of message translation in Apache Camel

In previous posts I wrote about separating business rules from message transformation in middleware systems. I also explained why changes affecting business rules involved in message transformation suck.

To make my further considerations more concrete let's discuss possible model of delegation of business rules based on Apache Camel.
Apache Camel project provides org.apache.camel.Processor interface which can be implemented in order to provide message consumer or translator functionality. What we want to design is the implementation of the Camel Processor which delegates business transformations to the specialized interface responsible for message translation.

Interface specialized in business message transformation is named BusinessTransformation. Its responsibility is to transform single business fact. Transformed fact cannot be a null value. Business fact returned by the transformation can be a different instance than one passed to the BusinessTransformation object. Transformation can return null value, which indicates that input fact has been consumed and processing of the message is finished.

Class named BusinessTransformer aggregates instance of BusinessTransformation and implements Camel’s org.apache.camel.Processor interface. It delegates transformation of the message to the external business component represented by the BusinessTransformation instance. BusinessTrasformer should be immutable and doesn’t change over its lifetime.

In next posts I'll show concrete use case in which BusinessTransformer can be used. And provide some cool Recycled-based implementation of the problem.

How to sniff network traffic from another machine connected to the switch

Assume that there are two machines (A and B) connected to the switch. You want to sniff the network traffic between them with another box (Sniffing machine C) connected to the same switch. NIC of sniffing machine C (even when set to promiscuous mode) cannot see messages exchanged between A and B, because switch creates virtual connection based on the MAC addresses of these machines.

Assuming that you have privileges to configure switch, you can create port mirroring between switch port involved in the traffic (1 or 2) and sniffing port (3). 

Port mirroring allows you to copy network traffic from one port of the switch to another. For example you create port mapping from port 1 (Machine A) to port 3 (Machine C). Now you listen on machine C using promiscuous mode and you can see traffic between A and B boxes.

On Linksys/Cisco routers you can configure port mirroring by entering web setup of the box and navigating to the Admin -> Port Mirroring section.

Please note that some switches allow you to mirror more than single port to the monitoring one. Make sure that bandwidth of the single port can handle entire traffic from all ports mirrored to it. Otherwise your switch can go wild or refuse to handle any packages at all.

Propagation of business changes in transformation components

Few days ago I started to write about separating business logic from message translation in middleware systems. Today I share some further thoughts concerning this issue. Particularly how message translation model usually looks like and what can we redesign it in order to make it more elegant.

Gregor Hohpe in his famous EIP book described message translation as a component of messaging infrastructure that is responsible for performing modifications on the incoming message.



Message translator can enrich, as well as reduce, the content of the message. In extreme cases translator can even replace incoming message entirely with the new content. While EIP book lists and describes possible transformations that can be executed against the incoming message (wrapping in envelope, enriching, filtering, normalizing an so forth), it does not discuss the possibility of delegation of the translation logic to the external business component.

Business requirements tend to change frequently during the software system development. Moreover, even when application is already built and deployed, it is still very likely that business rules are going to change. In general integration architects can safely assume that business requirements are going to evolve and being modified during the lifetime of the system.

If system architect decides to include business logic in the transformation components, then all changes to the business rules affect also translation modules (and therefore messaging infrastructure).

Implications of such approach are (just to mention few of them):
• Violation of Separation Of Concerns principle between messaging and business layers of the system.
• Low reusability of the both middleware and business components of the system.
• Worse maintainability of both business rules and the transformation components.
• Problems with distribution of the tasks within the team (since analysts have to work on the same component as the integration architects and engineers).
• Unnecessary redeployment of the messaging infrastructure on changes of the business rules.

What we would like to achieve is transformation model where business changes affect only business components of the system. In our perfect model message transformation should depend on business logic, but still be unaware of the business rules details. Therefore internal changes within the business components would not affect the messaging infrastructure.

In next posts I'll cover the latter model in more details (including Apache Camel and JBoss Drools solution) and present some experience of mine in the area of the discussed issue.

Motivation to separate business rules from the message enriching

Transformation of the messages is one of the key functionalities provided by the middleware systems. There is a lot of existing and production-ready solutions which can be applied to the majority of the business problems. The most of the serious business issues require quite complex messaging solutions. And when integration infrastructure begins to grow, maintainability of the message routing structure becomes an issue.

One of the main factors affecting the complexity of the middleware solution, is the necessity of including business rules in the messages routing structure. Business requirements use to change and such changes propagate to the entire structure of the integration architecture. Floating requirements in the software system always generate costs, but changes in the messaging infrastructure are one of the most expensive ones.

What integration architect can do to minimize the costs following changing business requirements, is to apply the Separation Of Concerns principle between business logic and the messaging infrastructure.

The area of messaging that heavily depends on business logic is message transformation. Operation that changes message (i.e. perform enriching, filtering, normalization, etc.) usually performs such task with close cooperation with the business components of the system. Message transformation would be then an excellent target of optimization by applying Separation of Concerns principle.

In next posts I'll focus on the message enriching operations performed on the messaging infrastructure. I'll write about patterns that can be applied to this kind of transformations. And of course provide possible implementation created in Java language backed by the Apache Camel and JBoss Drools frameworks.

Stay tuned.