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
Last week, I talked about the ADF Faces Rich Client components included in ADF 11g, the rich capabilities they offer, and the fact that I still don’t think they use AJAX to its full potential. I mentioned some examples of how I’d like to see these components evolve in 12g.
Of course, with JDeveloper 11g still in technical previews, JDeveloper 12g is not on the horizon yet–I don’t know if it’s even in development–so from the perspective of a developer out in the field, any discussion of how these components might be enhanced for 12g is still pretty pie-in-the-sky. What can developers do in the mean time?
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?