This is Part 4 of 7 in the Life in Porto Alegre series.
It’s been six months since I joined Dell, and I’m in the middle of one of the most exciting shifts in my engineering career. Our team is actively migrating logic from traditional Java codebases into orchestration tools like Oracle Service Bus (OSB). And I’m not just watching — I’ve been asked to champion this transformation.
A Java Engineer in Drag-and-Drop Land
Before this project, I wrote all my transformers, service clients, and parsers directly in Java. Everything was code: mappings, fault handling, data validation, sequencing — all wrapped in annotated classes and lots of unit tests. The full stack was under my fingertips, and I loved the control.
Now, I’m stepping into a space where orchestration and transformation are designed visually, and behavior is configured instead of coded. At first, it felt abstract, almost too high-level. But with the guidance of our tech lead Carlos Eduardo (Cadu), and after a good amount of reading and internal exploration, I’m starting to see the beauty.
What’s Different
Let’s break it down:
| Concept | Java Approach | BPEL / OSB Approach |
|---|---|---|
| Data Transformation | Custom POJO + Mapper libs | XSLT or drag-and-drop mapper |
| Service Invocation | Custom clients + error handling | Declarative proxy pipelines |
| Error Management | try/catch blocks | Fault handlers |
| Testing | JUnit/TestNG | Emulated flows + some integration mocks |
| Deployment | WAR/EAR with CI | Managed artifacts via WebLogic Console |
The biggest shift is moving from logic-as-code to logic-as-config. That’s powerful — but also requires a different mindset.
The Pros (So Far)
- Faster onboarding for team members unfamiliar with our codebase
- Reusable building blocks via OSB pipelines
- Centralized visibility into integrations and flows
- Less boilerplate for simple operations
- Encourages clearer separation of concerns
And the Cons (From My Perspective)
- Harder to debug and trace than stepping through Java
- Tooling can feel clunky or slow
- Complex logic sometimes feels forced into diagrams
- Lack of type safety compared to Java’s compiler
- Collaboration is harder when you can’t easily “diff” configs
But I’m still learning. I expect many of these impressions to evolve — some will become clearer, others might get resolved as I gain expertise.
Owning It, Enabling Others
This quarter, I’ve spent a good chunk of time enabling the rest of the team. Pairing, recording short tutorials, building small reference pipelines, documenting gotchas — it’s all part of this mission. And the best part? I feel pumped.
<!-- Example: OSB pipeline config -->
<service>
<pipeline>
<stage>
<request>
<replace var="body">
<xslt>transformCustomerRequest.xsl</xslt>
</replace>
</request>
</stage>
</pipeline>
</service>
// Java equivalent of transformation logic
Customer toCustomer(XmlCustomer input) {
Customer c = new Customer();
c.setId(input.getId());
c.setName(input.getFullName().toUpperCase());
return c;
}
Final Thought
Learning OSB has reminded me of a key truth: Tools change, but core software thinking doesn’t. Clear inputs and outputs. Explicit boundaries. Robust fallbacks. Good logs. These matter regardless of whether you’re writing code or orchestrating it visually.
I still love Java. But I’m embracing this new toolbox with open curiosity. And thanks to Cadu and the team, I’ve never felt more empowered to learn.
More updates soon — this transformation is just getting started.
Life in Porto Alegre Series:
- Part 1: New City, New Code, New Language
- Part 2: Total Focus, Pomodoro and Migration with Confidence
- Part 3: Release Weekend, Automation, and the Value of Real Leadership
- Part 4: Beyond Java: Learning OSB, ESB and BPEL in the Second Quarter at Dell (you are here)
- Next: Remote Work, Resilience, and the Power of Friendship (Part 5)
- Rescuing the Teacher in Me: Inspired by a Tech Lead Who Builds Others (Part 6)
- Gratitude and Transition: From Dell to RBS (Part 7)
Complete series: Life in Porto Alegre Series