What’s special about SwitchYard? It’s SCA.

Service Component Architecture (SCA) is the marriage of these two things. It essentially recognizes that some of your building blocks are going to be local, others are going to be external, all of them need to be as reusable as possible, and their internal/external exposure may change over time. In other words, it’s a SOA orchestration of services that is a fluid hybrid between the two worlds. Your code will periodically use a @Service tag to declare a service dependency. And some XML configuration file will help map out the ESB-specifics of (a) exposing necessary services or service compositions to the outside and (b) getting access to outside service dependencies that you’ll need.

Over the past several years I’ve become wildly enthusiastic about certain “trends” in software development that promote clean, agile, distributable code. The primary buzzwords I’m referring to are “SOA” (Service Oriented Architecture) and “Dependency Injection”. Heck, I’ll even throw “SOAP” into the mix, even though that’s a more specific protocol.

If I talk to other developers about these things, they look at me funny or they show disinterest or suspicion. I think some people think I’ve gone crazy over some trendy buzzwords (i.e. pointy-haired-manager syndrome) and am just trying to evangelize some lame trend that will come and go. Or there’s the classic “SOAP? Oh yeah, I tried to do something with that and got so confused and just hated it. *shiver*”

(By the way, SOAP may have some hard-to-parse standards, and the WSDL can be daunting and confusing, but it’s really simple: you are taking your XML request and wrapping it in a simple envelope that is often nothing more than a single parent <soap> tag! There are some provisions for allowing messaging meta-data to be added in a header section, but all that stuff is optional. Anyway, if you are one of those people who is afraid of SOAP, take a second look; it’s not all that bad.)

Dependency Injection and Service Oriented Architecture are interesting topics in that they really should be easier to explain. I’ve read so many books and articles, and authors have written a lot of insightful material, but I haven’t run into anyone who has been able to expose the inherent simplicity behind these things. Well, I might my hand at the task someday, but not in this blog posting. My purpose is a bit more specific… to share an insight about Service Component Architecture. Continue reading “What’s special about SwitchYard? It’s SCA.”

Maven and JPA Programming

It cannot be overstated just how helpful it is to have a lightweight persistence system in your testing configuration. The problem with JPA annotations like @PersistenceUnit for dependency injection is that a lot of your primary code can only be run from within a full-fledged J2EE application server.

I wanted to take a moment to rant a little about Maven and JPA programming. If you haven’t switched to the Maven way of things (It took me years to give into the dark side!) or you just started doing Maven-ized projects recently, you might still be getting the hang of things.

I won’t lie: it can be relatively hard to get used to. For example, take a look at the traditional directory structure for your project:

standard Maven directory layout

This may look a bit complex (like the first time you looked at a Unix directory structure!?) but in fact it’s a fantastic convention. For example, it’s so amazingly easy for me to create sample data files, drop them into src/test/resources/sampleData and then pull the data will a quick Unit Test using

InputStream sampleData = getClass().getResourcesAsStream("/sampleData/myFile");

and away you go! Continue reading “Maven and JPA Programming”