Eventually i had a requirement or it’s out of my curiosity, to see or replicate how my SOAP message looked like when it is being sent to a remote web service.we can send soap messages programmatically, but sometimes it is handy to have a way of sending the raw SOAP messages to the web service directly especially with interoperability issues between different implementations of the SOAP specification.

I had remote web service publishing WSDL file, and i was forced not use to any JAX RPC implemented Client programming to send data or access the service.

I was using simple java file to create SOAP request message and to create a proper SOAP request i had to know how the request message looked like.So here came the tool, which helped me on generating the SOAP request message in correct formats for accessing the remote WSDL file.

You can send the same SOAP request to remote web service using the same tool and if everything runs smooth on the remote web service, it gets a proper SOAP Response.It has a view in the Eclipse IDE from which raw SOAP messages can be sent to a web service.It can be used in validating your WSDL, checking with soap request and response it can generate

The open source tool which i would suggest you, comes as an eclipse plugin developed by OKC.
More information on the tool is on Web Service Console Eclipse Plugin

Although developed based on a need to send raw SOAP messages, the plugin can also be used to call any XML based service over HTTP, or even non-XML based services.

The best tool i found was Exchanger XML Lite 3.2, which allows not only to generate test xml instance,but also you can use the tool for many other XML functionality

How to use :
1.Download Exchanger XML Lite 3.2
2. Select the XSD by File -> Open -> Some.XSD
3.Validate XSD by Schema -> Validate XML
4.Generate test xml by Schema -> Schema Instance Generation
5.Select the current document, the document root elements , the attributes elements and content.
6.Once you select all the above options, your test xml is generated.

Other tool in the list is Altova XmlSpy, which is not a open source tool, but can be utilized in the trail period of 30 days

It does it by just connecting to a single endpoint with the help of multiple proxy sockets generated in the system.

How to use :
1.Set the IP Address and Port Number of the system to connect to in the config file
i.e connect :199.63.87.100:9000
2.Set the IP Address and Start Port Number of the system where your relay can run, in the config file
i.e accept :199.63.87.101:4000
3.nbr in the config file specifies the number of sockets you want to create.
i.e. nbr= 10 (creates 10 sockets starting from 4000 t0 4010)
4.Now your System can send send messages or receive messages from 199.63.87.100:9000 through the proxy ports 199.63.87.101:4000 to 199.63.87.101:4010.
5.So your System now is connected to 10 Proxy systems.

Download Code
if above link does not work, please send a mail to sadiqece@gmail.com

Java – Without which i cannot imagine enterprise world, has been evolving and there have been add’s, looking to add, and already added lots and lots of features to the language itself and yet keeping the backward compatibility. That’s a hell of a work, I must say. It’s very difficult to maintain that, for sure. Sun has been doing lots of good job.

But what about the new java developers? What about the old java developers?

Old Java developers would be having to learn more and more about the language and how it works and how to use it and its features. I do not complain about learning new things, but, it’s the amount of knowledge that we; old java developers; need to learn. It’s so huge and getting bigger everyday. But the only thing that makes me able to continue is that I am building over what I already have learned. It’s accumulative. That’s what makes it, for me at least, a little bit easy. But I have seen some developers who does not read articles online daily and does not keep up with what’s new. Believe me, they are facing a tough time trying to catch up now.

And what about new ones? Imagine the amount of knowledge they need to learn. Imagine how much info, starting from OO concepts, variables and what they mean, and ending with….. mmmm… is there really an end? I can’t see it. I have been in the area for over than 5 years now, and since I started and there are always lots of things new to learn, and that’s exactly what keeps it interesting..

Few Java Updates for quick reference:

Java 4

Java 5
URL:http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html or http://www.sitepoint.com/print/introducing-java-5/
Java 6
URL: http://java.sun.com/developer/technicalArticles/J2SE/Desktop/javase6/beta2.html
Java 7
URL:http://tech.puredanger.com/java7

“Software as services” or SAS, its acronym abbreviation, means delivering software over the Internet in the form of a complete service. You sign up for a service and you pay a monthly, quarterly or annual subscription fee. Or, increasingly, you pay nothing, because the service is advertising-supported and the vendor of the service gets paid through ad revenue.

Either way, in return you get the right to use the software. Many times there is no need to download any software on to your computer or install anything. If you want to use the software, you simply log on to a central website or some other Internet-enabled application. And, voila — you are using a new application. The point is that you have to do very little except use the service, and do not have to fuss with lengthy or complex technical tasks — all that is handled for you automatically.

Professionals who follow technology business models have been predicting the rise of software-as-service for some time now.

Important Elements Of SAS:

Both of SOA and Cloud Computing can be taken as seperate topics. But as they are Inter-related with SAS, below is brief description

1. Service-oriented architecture (SOA) Definition : A service-oriented architecture can be defined as a group of services, which communicate with each other. The process of communication involves either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed
2. Cloud computing comes into focus only when you think about what IT always needs: a way to increase capacity or add capabilities on the fly without investing in new infrastructure, training new personnel, or licensing new software. Cloud computing encompasses any subscription-based or pay-per-use service that, in real time over the Internet, extends IT’s existing capabilities.

1. Java – While many think of Oracle as a database company, the fact is that Oracle is deeply invested in Java and it’s Fusion Middleware stack is built on Java. Oracle CEO Larry Ellison in his post acquisition call has stated that “Java is the single most important software asset we have ever acquired.” So it’s highly unlikely that Oracle will put Java on the back burner and not invest in the growth of Java.
2. Solaris – Over the past couple of years, Oracle has had a major Linux push. Oracle Magazine has had penguins featured on its cover and Oracle Unbreakable Linux has been one of it’s top marketing lines. Post acquisition, Oracle has stated that it will be as committed as ever to Linux. Oracle says “The Sun Solaris operating system is the leading platform for the Oracle database. With the acquisition of Sun, Oracle can optimize the Oracle database for some of the unique, high-end features of Solaris.” So Solaris will do ok, but I think Oracle is too far down the Linux path to now make Solaris its preferred OS.
3. MySQL – The acquisition FAQ in reply to the question “What does Oracle plan to do with MySQL?” says “MySQL will be an addition to Oracle’s existing suite of database products, which already includes Oracle Database 11g, TimesTen, Berkeley DB open source database, and the open source transactional storage engine, InnoDB.” Unlike answers about Sun’s hardware business, in case of MySQL, Oracle does not talk of being committed the growth of MySQL or long term focus on MySQL, etc. The future of MySQL at Oracle doesn’t look very bright. However if the MySQL licence doesn’t make it financially impossible, a MySQL fork could emerge and gain some traction. MySQL has been forked before but the forks never got much developer attention.
4. IDE – Until a few years back, JDeveloper was a great alternative IDE to Netbeans and Eclipse based IDEs. However lately JDeveloper seems to have become a tool that works best for Oracle products and delivers solutions that Oracle app customers want. It seems like it no longer wants to compete in the Java IDE space. So JDeveloper hasn’t introduced much of scripting language support although most other IDEs have been rushing to provide scripting language and framework support. Oracle already has two Java development tools on hand in JDeveloper and Workshop (formerly BEA Workshop) and adding NetBeans to the equation is going to further complicate things for Oracle. I would think that JDeveloper will consciously move further away from the hardcore Java crowd and be customized for traditional Oracle Apps and Oracle Developer developers, while NetBeans and Workshop will focus on the geeky Java enthusiasts. For NetBeans lovers, I guess Sun being acquired by Oracle is better than it being acquired by IBM.
5. JavaME – Java on mobile devices has been doing quite well and I would expect Oracle to put as much into JavaME as Sun.
6. JavaFX – Oracle doesn’t have a competing GUI & graphics technology, however Oracle also doesn’t seem to be very interested in that space. I would expect Oracle to continue to support JavaFX for the time being but truly process JavaFX maybe a year from now, when it would have come to terms with the Sun acquisition.
7. Sun Hardware – There’s already speculation about Oracle selling off Sun’s hardware business to Fujitsu. This does look likely.
8. OpenSource – Oracle is primarily a builder of proprietary products and even the products that Oracle gives away for free, like JDeveloper and the Express DB are not open source. So although the Sun teams will bring an open source culture with them, Oracle is unlikely to become a big supporter of open source.
9. Image – Oracle is a mega company with many brilliant people working for it. However Oracle doesn’t have a geeky culture or image, and unlike many other companies in the Java space, Oracle isn’t one to come with cool open source products that seem to have no immediate buyers. For example, Oracle is unlikely to invest the amount of time and effort that Sun put into building a new GUI technology from scratch, JavaFX. Oracle products mostly solve problems for its paying customers. The focus is on being solid and reliable and not on being cool. Boring but effective.

Overall, I think Sun being acquired by Oracle is good news, as a struggling Sun would not be good for Java and for the Java based software industry. Oracle has the muscle to invest in the growth of various Sun technologies and ensure that they perform to their potential. A new owner should also bring new ideas & excitement to Java.

But how did the software get that bad? Presumably no one set out to make it like that? The answer is that the software is suffering from Software Erosion – the constant decay of the internal structure of a software system that occurs in all phases of software development and maintenance

At the architectural level, Software Erosion is seen in the divergence of the software architecture as-implemented from the software architecture as-intended. Note that when talking about the architecture as-intended I’m not speaking here about the initial planned architecture of the software system. Software architectures should evolve over time – this is to be expected as new requirements emerge – so the intended architecture is what your current conception of the architecture is. With software erosion what we’re talking about are unintended modifications or temporary violations of the software architecture.

The problem with software erosion is that its effects accumulate over time to result in a significant decrease in the ability of a system to meet its stakeholder requirements. Unless you take steps to actively pinpoint and stop software erosion it will gradually creep up on you and make changing the software further significantly harder and less predictable. In the worst case it could lead to the cancellation of the project or, for particularly significant projects, the closure of the business.

Types of Software Erosion

To begin to tackle software erosion you need an understanding of how it typically shows itself. Common types of software erosion include:

• Architectural Rule violations e.g. where strict layering between subsystems is bypassed.
• Cyclic dependencies – for example A calls B calls C calls D calls A. This type of dependency can be valid but when it’s unintended can lead to very complex, opaque code that is hard to understand and hard to test in isolation.
• Dead code – code that once supported part of the software, is now no longer used, but is still cluttering the code base.
• Code clones – identical or near-identical code fragments scattered across the system. A bug fix or change in one clone instance is likely to have to be propagated to the other clone instances.
• Metric outliers e.g. very deep class hierarchies, huge packages, very complex code etc.

A well-known example of software erosion was highlighted in a reverse-engineering experiment on two separate versions of ANT some years ago. ANT V1.4.1 (11 October 2001) and ANT V1.6.1 (12 February 2004) were reverse-engineered and the results were compared.

At the time ANT was built in three layers, from the top-down these were taskdefs, ant, utils. In the earlier version these layers were well separated and the ant layer was monolithic but small. In the later version the ant layer was still monolithic but had now become very large – making it harder to understand and work with. More problematically a new upward dependency from the lower-level ant layer to the top-level taskdefslayer had been introduced.

These types of erosion problems lead to code that is hard to understand, hard to modify and hard to test. But how do you know whether you’re suffering from software erosion?

Are you suffering from Software Erosion?

Perhaps the first thing to observe is that most projects will suffer from software erosion at some stage unless there is a conscious effort to pinpoint and stop such erosion. Even projects that are relatively short-lived can suffer from it. One example I have heard about involved a software project that had to be scrapped after only 6 months because it had already eroded badly.

There are some common things you can look out for when deciding how badly your software is suffering from software erosion:

• The time, effort and risk in implementing new functionality increase – productivity and quality decrease and complexity increases. These are very common side effects when software erosion is present.
• No one has responsibility for the architecture and knowledge of the architecture is held by a decreasing number of people.
• No one on the team can tell you (or agree on) what the intended or implemented architectures are. If you don’t have an understanding of either of these then it’s very likely that software erosion has occurred and will continue to occur.
• The team hasn’t had a stable core membership throughout the software’s life. If someone leaves the team then that person’s knowledge of the architecture and software leaves with him or her. New people take time to get up to speed on the project, so mistakes are made and the software erodes further. If new people are unlucky enough to be introduced into a team where no one knows what the architecture is or should be, then the software will erode even faster as they make changes to it.
• Little or no refactoring is sanctioned. Refactoring is the way to rollback software erosion once it has been pinpointed. Refactorings that remove architecture violations, eliminate code cycles, prune dead code, consolidate code clones and do away with metric outliers are particularly beneficial, because, by fighting software erosion, they clear the way for other refactorings, for bug fixes and for new features in the software.
• There’s pressure to rewrite the software. When software has eroded badly it becomes really hard for developers to work with that software. Every change and bug fix takes significantly longer in practice than it should in theory. The code becomes brittle and so even the simplest change can have unexpected knock-on effects which lead to costly rework. I’ll say more on rewriting later.

At a detailed level, software erosion results in problems such as code living in the wrong place, layering violations (as seen above in the ANT example), complex cycles insufficient decomposition, big packages etc.

Costs of Software Erosion

It can be hard to measure the cost of software erosion and convey this cost to non-technical people who often have to sanction work to stop software erosion. Even though software erosion causes reduced productivity, reduced quality and increased time-to-market, no one specific point of erosion causes these effects in isolation, rather it is the effect of multiple points of erosion that combine and reinforce each other to cause them.

However, a study by the US Air Force Software Technology Support Centre (STSC) attempted to put some rough measure on the costs of software erosion. The researchers took two versions of a mature software system (50k LOC) and asked two different teams to perform the same maintenance task (adding approx. 3k of code) on their respective version. Version 1 was an existing system suffering software erosion. Version 2 was the same system but with the architecture restructured to remove erosion.

The results were staggeringly different. Team 1, working on Version 1, needed over twice as long as team 2 to complete this relatively short task. Furthermore, Team 1’s results contained more than eight times the number of errors than the work submitted by team 2, working on version2. Erosion in a small system such as this still had the potential to lead to significant problems when the software was maintained.

Causes of Erosion

By now you should have some clues as to how software erosion comes about. It does not arise purely spontaneously. Software Erosion comes about through change.

Pressure for change comes from a variety of sources. The need to add new features to a product to help persuade people to buy it, changes to the environment within which the software is deployed e.g. to support different networking or GUI standards and technical changes, such as the desire to adopt new coding standards all have an impact on the software. Where the initial vision for the software doesn’t allow for change, such erosion effects will be seen very quickly.

Software Erosion is also known as software decay or code rot and by similar terms. However, these don’t adequately capture the notion that it is forces external to the software that are ultimately the cause of problems within the software. Erosion is not something that just happens to the code without someone actively making such changes. This is why I feel that notion of software erosion more adequately describes this gradual wearing down of the ability to work effectively with the software.

The needs of the business can also contribute to software erosion. Even though deliberately eroding your software causes bigger problems down the line it may be in the best interest of the business to do this for some short-term gain. The problems build up quickly however if the business does this repeatedly without spending time to refactor the eroded code. Every developer is familiar with the ‘quick-fix’ that becomes a permanent feature.

Real-World Examples of Software Erosion

How bad is this problem in practice? In 2007-08 I decided to investigate this question by running a number of workshops at different software events in the UK and by engaging in some discussions with some software practitioners further afield.

At every workshop I ran participants spoke about many different examples of systems suffering software erosion:

• Software with a large number of cyclic dependencies that ended up as brittle spaghetti code.
• Systems where business logic (with associated SQL) was captured in the software’s presentation layer – making it hard to replace this layer.
• A software system where the threading architecture eroded so badly over time that the system became unmaintainable and had to be scrapped.
• A single class used as a dumping ground for everything that didn’t have a better home.
• A ‘cancerous wart’ of a software system with ever increasing coupling between modules, packages etc.
• Lots of code clones (copies and near-identical copies).
• Uncontrolled code use – programmers grabbing code, classes and even variables from other parts of the software without any control on what could and couldn’t be used – once again led to significant erosion.
• Several examples of drive-by programming – team-membership constantly changing, programmers not understanding the architecture and so making mistakes when they coded and then moving onto their next project. One example of drive-by-architecting with similar consequences.
• Problems with obsolete software and hardware technology; a lack of skills in these obsolete technologies leading to further decay.
• Sales-driven evolution – where there was no clear roadmap or scope for the software system and so the implemented software architecture inevitably diverged rapidly from the intended architecture.
• Merged companies with different cultures and different principles having to collaborate on a software system leading to decay.

In every workshop all but a few people either were working on projects that had eroded quite badly or had worked on such projects in the past.

Case Study – Outsourcing of a 1MLOC C/C++ system

I outline below a real-world case study in order to get you thinking further about software erosion. My recommendation is to spend 10-15 minutes (either on your own or with a colleague who is also reading this article) thinking about the questions before proceeding to the discussion.

Case Study Project History

A company developed a software system over a number of years. Six years ago the software was transferred to a company-owned outsourcing centre in India where it has been developed since that time. At the time of the transfer the organisation believed that the architecture of the system as intended was well documented and matched what was implemented.

The software is critical and cannot be thrown away easily.

Over time more staff were added to the project to maintain a steady flow of new features. The company has a similar product that is maintained and evolved by 5 developers whereas the Indian department now has 50 developers.

The company recently compared the amount of work done by these two teams and assessed that they delivered roughly the same amount of work.

Present Situation

Acting on this difference in productivity the company compared the architecture from 6 years ago (as the outsourcing took place) against the architecture of the current code and found that many parts of the system have dependencies that are not intended.

The intended architecture was documented, so in theory all involved personnel could have compared actual to as-intended architecture. The initial architecture was probably appropriate for the current system (so it’s a good architecture that has gone bad).

The company now intends to bring part of the software back under control in Germany while leaving part under control in India.

Questions

Think about whether it is credible that software erosion led to this significant decrease in productivity? What do you think of the company’s proposed solution?

Discussion

The software has been developed over a number of years; the team and their development processes; tools and technologies may have changed during this time. Given we can probably reason that the software has probably been modified a lot before it was handed over and so conclude that it’s likely that the architecture at the time of handover may have eroded.

There was a major personnel change 6 years ago when the project was handed over. The two different organisations will have different cultures, knowledge & skills. It is not clear that these differences will be lessened just because both organisations are part of the same multi-national. This could lead to further erosion.

We also have to consider the reasons for the switch and the way the switch took place. Did the organisation cut costs on the project when the software was handed over? Was there a backlog of work on the project that it was felt the new team could tackle sooner or better? How was the handover done? Did they redeploy the existing team elsewhere or did they fire them? Were people from the old team made available to help people from the new team get up to speed? How much time was the new team given to learn about the software before having to start modifying it? If there was no effective handover and insufficient time allowed for the new team to learn the architecture and the code base then erosion is more likely to have occurred.

We’re told that the ‘Software is critical and cannot be thrown away’. We’re also told that there’s been a steady flow of new features Both of these indicate that changes have and will take place implying that erosion could be present. This is confirmed by the assessment that there are a lot of unintended dependencies in the architecture as-implemented.

My belief is that it is credible that architectural decay contributed to the team’s problems but that it cannot be untangled from other issues.

• There have been lots of changes over the years.
• At the time of handover it wasn’t clear how closely the architecture as is matched the architecture as intended.
• There were lots of staff changes – how well was the handover managed? – this was initially a comprehension task that needed management and technical support.

Stopping Software Erosion

Stopping software erosion requires management commitment. If managers are only interested in the short-term viability of their software projects then it is hard for developers to get the time and make the effort to tackle the problem. This does not excuse developers from doing what they can to fight erosion but will inevitably make their struggle less effective.

If management commitment is present then the following outline pattern can be used to stop software erosion. How you implement the pattern depends on what tools you have available, what domain your project lies in, how mature the erosion problem is etc.

Stopping Software Erosion – a Pattern

1. Start out with a sustainable architecture. – All successful software systems evolve; make sure you have built in flexibility for future known changes. Assess your architecture using the most likely change scenarios – where is it flexible, where will it need to evolve? There are always tradeoffs here in the amount of time you can spend in architecture assessment and also in the ‘finished’ architecture.
2. When implementation starts regularly visualize the architecture as the software changes. Get a feel for how close your implemented architecture is to your architectural vision – maybe you need to change the latter.
3. Compare the architecture as-implemented to your architecture as-intended to see how they differ. With automated support this can be done as part of the software build. This step does rely on you at least having some vision of what your intended architecture is. If you don’t have this then you can gradually reverse engineer it from your architecture as-implemented. There are now many tools from very basic free ones through to very advanced commercial tools that can help with architecture visualization and checking.
4. Use cycle detection, clone detection, metrics analysis and dead code detection to pinpoint software erosion. Again there are several free and commercial tools that tackle some or these tasks.
5. Refactor the software to remove eroded code.

Stopping Software Erosion – Cultural Factors

As noted above, if top management doesn’t support the fight against software erosion then developers have their work cut out to stop erosion. With management support you can create a culture where stopping erosion is valued. This culture is likely to have characteristics such as – an emphasis on regular refactoring, clear assignment of responsibilities, sharing of architectural knowledge and work, frequent communication between the whole group.

In Designing Maintainability in Software Engineering: a Quantified Approach Tom Gilb describes one team’s ‘Green Week’ – one week set aside each month to focus on improving their software’s maintainability. This proved more successful for the team than their earlier one day a week approach and had the added benefit of making the development team feel empowered.

A few words on rewriting

Before I wrap up I’d like to say a few words about software rewrites. As I noted earlier, pressure from development teams to rewrite software commonly manifests itself when that software has eroded. In the worst case the development team uses the excuse of a possible future rewrite to delay refactoring work to the software. When this occurs, the software continues to erode until it reaches a state where working with it becomes very difficult. Even if a rewrite may once have been avoidable if action had been taken the result is that a rewrite becomes inevitable due to the negligence of the team.

As a developer, when faced with a decision about rewriting some software you should always ask yourself whether you are planning to rewrite it for the right reasons. Is it because you cannot make the software maintainable or is it to get rid of code you haven’t tried hard enough to refactor or code that someone other than you has written? Worst still, is it just to get some hot new technology onto your CV?

As a manager ask yourself whether you can afford a rewrite? Do you have the right people with the right skills available for the right length of time? Do you understand the risks of new tools and technologies? Do you understand what you have to build? Are you rewriting the software or building something brand new? Worst still, how long will it be before your competitors catch up? In the Doomsday scenario, can your organisation handle the total failure of the rewriting project?

If you’re about to risk an expensive and lengthy rewrite of your software, are you really sure that you’ve exhausted every approach to fighting software erosion in your current code base?

Summary

Any successful software system is likely to evolve. Unless preventative work is undertaken the software will erode. As the software erodes the cost and risk of further development rises. It’s rarely too early to start fighting software erosion. The costs of software erosion start to bite very quickly once it sets in.

There are lots of different things that can be done to stop software erosion – you (just) need to work out what the best value approach is for your particular project. If you are a manager then create a culture where fighting software erosion is encouraged and supported. If you don’t do this then no one will care about erosion. If you are an architect or developer then educate yourself about the different causes of erosion and the different approaches for fighting it. If you’re interested in finding out more, or sharing your ideas on stopping software erosion, then please get in touch.