DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Join us today at 1 PM EST: "3-Step Approach to Comprehensive Runtime Application Security"
Save your seat
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Deployment
  4. Developing a SOA-Based Integration Layer Framework

Developing a SOA-Based Integration Layer Framework

Marit Fränkel user avatar by
Marit Fränkel
·
Mar. 11, 13 · Interview
Like (0)
Save
Tweet
Share
5.30K Views

Join the DZone community and get the full member experience.

Join For Free
A few years ago I was asked by one of our customers to help them make better use of their integration layer. Ever since then me and my team have been working on a framework in support of that. This is the third in a series of blogs on the development of our framework, and discusses the challenges we had to meet.

In the previous blog of this series I mentioned the goals we had to reach. Succeeding in doing so of course meant we had to overcome a lot of challenges. In order to keep this blog from reaching the size of one of the books of the ‘Lords of the Rings’ trilogy, I’ll keep it limited to the five below, which together form a pretty good picture of what we had to deal with.

Challenges

picture taken from Flickr

1. Resistance in the organization
There is something an integration layer has in common with SOA, and one of the reasons why both of them fail so often: as soon as you’re getting the word out of what you want to do, people start to dig their heels in, based on what they think you’re doing (as opposed to what you actually are doing). Also, all of a sudden they need to follow certain rules to get their data from other systems, which to them is just static. Plus in their mind performance is always an issue (even if it isn’t, not to mention the fact that we’ve never had any problems in that area). The worst about this is having to always defend yourself. When two systems communicate with each other using the integration layer, and something goes wrong, it’s the fault of the integration layer by default (shoot the messenger!). Guilty until proven innocent, indeed.

The answer is of course to keep people informed at all times, and working very closely together with the project teams (even becoming part of such teams for a longer time when necessary, as per the Scrum methodology). It does help if there are architectural policies in place, like the one we currently have that prescribes the use of the integration layer when invoking services in other domains.

2.Keeping generic features generic
This is one that was especially present when developing the bulk of the framework. We were part of a big project trying to tie two systems together that were not really built for that kind of thing. As the deadline was getting closer, the pressure to make a few shortcuts in order to get specific requirements implemented was rising. Fortunately we had a project manager who was capable of keeping his eye on the big picture. Still, I do recall meetings with lots and lots of screaming.

3. Dealing with a lack of SOA knowledge
If there’s one thing I found out the past few years, it’s that lots of people have no clue what SOA is about, but still pretend they do (or even worse: are convinced they do). That made it particular hard to sell some of the more SOA-influenced decisions (like the usage of certain WS-* standards, and yes, they do work in our case, thankyouverymuch). Worst (or best, depending on how you look at it) example was when a software developer told me that SOAP and queues don’t mix, making a part of our framework defunct in his eyes. The only thing to do in such a case is of course educating people through presentations, workshops, written documentation and discussions.

4. Dealing with a lack of platform knowledge
In the meantime, not all was well on the implementation side. We had this appliance that we had to use, and that had lots of options we actually could benefit from, but not too many experts available. That meant that we really had to get our hands dirty, and also that we had to make a few rookie mistakes before we got things running. By then we had already managed to alienate some people, as in their eyes we could not deliver. Remember what I wrote about concept and implementation earlier on? This is where it hurt.

5. Working without a Canonical Data Model
This may seem like a strange one but think about it: all these different applications in these different domains, trying to communicate with each other, but speaking their own tongue. The integration layer in the middle, transforming messages to and fro. Contracts for the consumer and from the provider being just different enough to get you into a versioning hell if you’re not careful. Suddenly this ‘intrinsic interoperability’ goal of Service-oriented Computing all the cool kids are talking about starts to make a lot of sense.

Conclusion

As mentioned above, this is just the tip of the iceberg. In the end it’s all about ‘can you deliver?’ which fortunately we could. And up until that time, having an elephant skin did help.

That’s it for this time, next one will be about the building blocks of the framework.

Integration Framework

Published at DZone with permission of Marit Fränkel, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Continuous Development: Building the Thing Right, to Build the Right Thing
  • AIOps Being Powered by Robotic Data Automation
  • Top 5 Node.js REST API Frameworks
  • The 31 Flavors of Data Lineage and Why Vanilla Doesn’t Cut It

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: