Welcome Welcome to our blog about all kind of topics that are related to software development. We blog about:
SOA, BPM, EDA, ECM and all the other buzz words. Beware some post might not be so common as you think. We are not scared to go against main stream thoughts.
Technologies like java, maven, springframework, OSGi and front end technologies and frameworks like jQuery, DWR, Flex.
Finally to make this happen we need tools and of course a Mac (well some of us do). So we blog about that as well.
Linked in We now have a linked in group, join the group if you are a regular reader and want to see who else reads this blog.
 |
By Ben, on June 23rd, 2008
A while ago it happened to me again. I was working on a piece of code for which I had to extend a class and override a method; while doing so I ran straight into a brick wall in the form of that miserable throwback of the Java language, the final method. Let me tell you about it….
About a week and a half ago (from the time of writing), I had to adapt some code in the codebase of one of my projects. The code in question was business rule validation code that was being applied to a data set. It had worked fine in the past, but now the business wanted an exception made to the general rule. In other words, in certain circumstances the business rule validation should not take place. Being a well-mannered developer I work test-first, which meant creating a test to prove that certain code wasn’t being called. So how do you do that? Well, in my case it meant subclassing the class with business rules in my unit test and overriding the method in question to throw an exception if it was called. That, and overriding a setter that I needed to work slightly differently.
So that was the plan and that was what I did. I created my subclass with the overridden methods, created an instance of it and used a setter to inject my new object into the class that the unit test was testing. At least, that was the plan. Really, people, who makes a setter method final?
Continue reading The final problem
By freddie, on June 7th, 2008
Three months ago I left Accenture to start ISIS Papyrus Netherlands. These three months seems to me 3 weeks so fast they went. Although I miss sometimes the discussions with some of the people and the happiness of getting them on a nice job that fit their career I honestly have to say that [...]
By Ben, on June 2nd, 2008
Most IT development done nowadays involves development of some sort of message processing system (MPS). These MPSes can be simple and based on nothing more than message passing in the object oriented sense of the word, or they can be convoluted and even esoteric systems (ranging from SOA components included in an ESB to JMS-driven MDBs and so on). In all cases they are based around the paradigm of messaging — passing of messages from a client to an MPS and often having the MPS send a second message back in response. The MPS responds to an incoming message by doing some form of work based on the message’s contents, possibly delegating part of that work to third systems (in which case the MPS takes on an orchestrating role as well as a primary processing role). Almost any system currently being developed and maintained in the Enterprise software development sphere fits the paradigm; the business layer in the three-tier JEE model is already an example.
In this article I want to discuss some best practices when designing and developing these systems:
- Separating business logic from publishing frameworks
- Mocking backends
- Logging messages so that they will be reusable in testing and problem analysis
Probably none of these best practices will bowl you over. In fact, you’re probably underwhelmed by the list so far. So why am I going to waste an entire blog talking about these boring basics of development? Because, for some reason, most projects still seem to overlook any or all of the points mentioned above…..
Continue reading Three obvious development tips for creating message processing systems
By Allard, on June 1st, 2008
There seems to be a lot of misunderstanding about Web Service security. Using password authentication doesn’t prevent unauthorized users to access your data, while SSL / HTTPS doesn’t give you any information about who is trying to access your services. And did you ever think of signing you messages with a digital signature?
In my introductory post I’ve elaborated on what type of security we’d typically want on Web Services.
In part 1 , I’ve dealt with Username Token authentication, an easy to use way to provide an authentication mechanism for your web service.
In part 2 , I have described Transport Layer Security (TLS) -formerly known as Secure Socket Layer- and message encryption.
In this part, the last one in this series, I will explain how the the digital signature can provide some form of security in web services.
Continue reading Feeling secure with Web Services – Part 3 – Digital Signature
|
|
