As promised, I’m posting of the presentation I’d been hoping to give at the OOW Unconference Methodology Symposium last week, expanded slightly for the more forgiving medium of a blog. As it turns out, it’s expanded substantially more than I thought, so I’m going to divide it into two parts. This week, I’ll talk about the basics of the methodology, its goals, and the two techniques it relies heavily upon. Next week, I’ll talk about the actual development process it specifies.
“Extreme Reusability” (the name is not mine, but rather Chris Muir’s; however, I decided I like it) is an idea for an ADF development methodology for mid-sized teams (generally around 4-20 developers) that I’ve been recently expanding on. Continue reading Extreme Reusability, Part I
Last week, I talked about ways to get many (though not all) of the benefits of service-oriented architecture (SOA) without the overhead of web service invocations by composing your applications out of smaller reusable applications. This week, I’m going to talk about a way to get a different subset of the benifits of SOA (without web services) in ADF 11g, using shared application module instances.
In my very first post on this blog, I talked about service-oriented architecture (SOA), and how, while I thought it was extremely appropriate for a certain range of cases, the overhead involved in web service invocation made it very inappropriate for an equally wide, if not wider, range of cases.
Today, I want to talk a bit about an ADF 11g alternative to SOA that still gives you many of its benefits without the web service invocation overhead: reusable applications. (Next week, I’ll talk about another SOA-in-spirit mechanism that ADF 11g provides: Shared application module instances.) Continue reading SOA Without the S, Part I: Reusable Applications
Web services are great. They allow for loose coupling between applications that use different technologies, are developed and hosted by different organizations, are asynchronous with one another, and so on…all for the low, low price of encoding the request, sending the request over HTTP, deserializing the parameters, serializing the result, sending the result over HTTP, and decoding the result. Well, OK, not that low a price. But what you get for it is pretty impressive.
Sevice-Oriented Architecture (SOA) is the idea of structuring entire applications around web services. Business service implementations are deployed entirely separately from one another and from view/controller implementations, and published as web services. Applications that need to retrieve, analyze, or change data contact the web services to do so. Lots of people love SOA. I’ve even met a fair number who love SOA so much that they think it’s the only reasonable architecture for enterprise applications.
Now, don’t get me wrong here. I’m not anti-SOA. Continue reading SOA What?