|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Presently, service-oriented architecture (SOA) is the hot topic in software development across all technology platforms, especially Java Platform, Enterprise Edition (Java EE) and .Net. However, if we compare the hype surrounding SOAs to what we saw in the late 1990s with Enterprise JavaBeans (EJB) and servlets (in other words, the nascent Java EE platform), there is no comparison. In 1998, EJB rode the Internet wave and represented a fundamental shift away from the hegemony of CORBA and the standard client-server model as dictated by PowerBuilder, Oracle Forms, and others. SOA, in terms of new technology, is not that disruptive. SOA is an idea, concept, or set of best practices for building and exposing functionality in applications. By contrast, Java EE is a fully developed technology stack, designed to be all things to all people.
My primary concern with SOA is an endemic problem across the enterprise Java habitat: complexity. My secondary concern is that SOA is often positioned as a solution to be applied mindlessly across all layers of a Java EE application when this makes no sense. This article aims to distil SOA down to its basic elements and understand them. Once we've done that, we can then understand the more complex components of the SOA ecology. Finally, we can understand where SOA adds real value in a Java EE application and, equally, where it adds needless complexity.
The article is structured as follows: First, I provide my own definition of SOA as a standard reference point for the following sections. From there, we examine the primary software engineering problem I believe SOA intends to solve before moving on to objectively examine SOA itself. From this review, I then propose an SOA taxonomy based on complexity requirements. Finally, I propose default implementations of the three main SOA categories identified in the taxonomy section.
SOA has many definitions. Here is mine:
An SOA is a macro-level design pattern applied at an application's architectural level that:
That's it. What did I leave out? Quite a few topics, if the truth be told, including:
These topics are important, but they muddy the waters. My definition distils SOA down to its core precepts, without losing the essence of the concept itself.
Note my reference to design patterns in the definition. This is key, in my opinion. SOA is not a new technology; in fact, one of its most attractive propositions is that it can leverage existing technologies easily and lend them a new lease on life. To my mind, SOA is like a blueprint, a set of best practices, or perhaps even a specification on how the next generation of software applications should be designed and implemented.
Archived Discussions (Read only)