Month: March 2013

Fractal Governance

SOA landscapes today look very much like fractals. An organization may have several internal capabilities presented as reusable services that connect to each other. It may even connect to 3rd party and/or cloud based services. But if you drill down into each of these services, you’ll likely see a composite application that is made up of several finer grained services interconnected together. And as a math geek, I am naturally curious about all things related to fractals.

In fact the fractal pattern appears in almost anything that’s responsible for connecting things together: highway and road systems, power grids, the internet… the list goes on. In all of these systems, there exists a hierarchical system of management and governance to regulate its functionality. Each country, for example, have national standards and regulatory bodies that define how power is to be exchanged, managed, and consumed. At the regional levels, there are additional standards and regulatory bodies that deal with region-specific decisions such as how much power to generate, pricing, and what equipment is to be installed where. Similar structures are true for transportation and telecommunications. So why is it that most organizations see SOA governance as an all-encompassing enterprise wide responsibility?

The interaction requirements and lifecycle characteristics of enterprise level composite services or business processes are very different from those of a utility service. To paint the entire enterprise service landscape with an uniform set of standards and processes will either result in a high number of exceptions or a lowest common denominator scenario. To be effective, an organization’s SOA governance model must match its SOA deployment model. The governance model must exist not just at the top, but at a granularity that matches how the services are being deployed and managed. Service Portfolio Managers, then are not just another role within the governance model, but micro versions of governance domains themselves. Service Portfolio Managers must be allowed to define their own standards and processes that are appropriate for the specific services that they’re responsible for. The SOA governance model for the enterprise must consider what standards and processes are appropriate for all services, which are appropriate for only the ones being consumed across the enterprise, and which ones should be left up to the Portfolios to govern themselves.

  • Shan
  • Gu

Introduction to SOA Development

As a hacker, I get a huge rush out of solving problems. It’s like a game for me, with the goal being always to find bigger and better dragons to slay…

Unfortunately, we all know it’s not always the case in our line of work! Usually, it’s some interesting problem hidden among piles of scut work. You know… That repetitive stuff that, while simple and pays the bills, often makes you wonder if all the good problems have been solved. That goes double if your client happens to be a big enterprise.

If you work for a company or have a client that has (or needs) a large IT Infrastructure, you’ve probably heard of Service-Oriented Architecture (SOA) before. You might have attended a meeting where a consultant had recommended such a system, or even had read up on it yourself. You might have noticed that it involves a bunch of mundane tasks like writing xml transforms, and WSDLs. I’ve been lucky enough to have been given a brief introduction to Oracle SOA Suite, and the accompanying JDeveloper tool that takes care of the tedious stuff, and lets you focus on what matters: Writing awesome code to solve interesting problems and look like a hero in your clients’ eyes. Of course, Oracle/JDeveloper is only one of the many packages out there for quickly deploying SOA apps. Other examples include TIBCO , IBM Websphere, and OpenESB.

This post isn’t some elaborate HowTo or Tutorial, but a brief intro to SOA from a programmer’s perspective. To demonstrate how using the right tools, you can have rich, reusable services up and running in a very short amount of time! The potential for this stuff is huge, and like it or not, it’s here to stay. Might as well go whole hog!

Zero to Hero in 30 minutes or less.

The following is just a quick intro at what can be done using jDeveloper. Like I said before, this is just one way of skinning the SOA cat. There are tons of other tools out there, some of them are even open-source. I’ll be posting some more elaborate tutorials, demos and HowTos later on.

The Dreaded XML Transform

XML transforms is possibly some of most boring work out there. Most of the time, you’re mapping an input from a web service to an object you’re then going to pass on to a database layer or some other service. Using jDeveloper, you can skip writing XSDs, and XSLTs, and just draw a few quick diagrams.

XML-transform-SOA

Business Process Execution Language

BPEL is how more complex SOA processes can be implemented. Usually by means of long boring XML definitions. Again, jDeveloper abstracts these in simple to read diagrams, resembling flow charts:

BPEL-SOA-jdeveloper

Putting it all together

The transforms and BPEL modules you create using jDeveloper are then used by a composite. This is a high-level definition of what comes in from the outside, and where it gets routed. Every module is configurable and can route data in and/or out based on defined conditions (more on this in future posts)

introduction-SOA-development

In Closing

This is just a (very) brief intro on what using the right tools can do to make your mundane development tasks way easier and faster to complete. Your mileage may vary depending on which package/platform you use, but they all can shave hours or even days off your service development cycle. And after all, that’s what matters when you want to get back to hacking that brilliant solution to that interesting problem you haven’t had time to focus on!

  • André
  • Racicot