|
|
| Service Oriented Enterprise |
|
|
Thursday, December 02, 2004 The Role of the Application Servers in SOA I've been using the term "service containers" to refer to the sandbox that services live in. However, in J2EE land, there isn't a 1:1 relationship between the 'software server' and the 'container'. You've got the 'servlet container', 'ejb container', etc. The Application Server is really an all-in-one - super-duper server. It slices, it dices, it does transactions, messages, web pages - you name it - it does it. App servers can host web services. They can also host platform specific services (RMI, EJB). The services provided can be governed via the container and can leverage additional functionality via components and class libraries (most of the J2EE API's). Just to restate - build services on top of components that are a combination of classes which sit inside of a governed container while making calls to libraries, some of which are runtime generators, perhaps being fed metadata from model-driven tooling. Agreed? Ok. Now we need to move into "specialized servers", like identity servers, orchestration servers, etc. Many of these servers were built from the ground up as stand-alone servers, while other implementations were built to sit on top of application servers (e.g., a bpel implementation that runs in JBoss). In the J2EE world, specialized servers are really just new API's governed by the JSR process to encourage yet another container or library to be added to the J2EE server. In some ways, J2EE has become a dumping ground for 'bright ideas'. Hence the movement to 'lightweight containers'. Now, let's ponder... Question #1: Would you describe the application server as a "Rapid Service Development" (RSD) environment? Question #2: To what extent should specialized services reside in generic containers? Question #3: Should the server be 'pre-glued' together (mandate the download all 55MB of libraries) or should it be more loosely coupled and segmented? Question #4: What are the necessary cross-cutting concerns that should be considered part of the server or container? Question #5: What functionality is not a cross-cutting concern, but rather a specialized function? Question #6: Would you consider the app server to be a "Contract First Container"? The application server has evolved to meet the needs of the masses. It was designed to be an all-purpose server. Can a developer build SOA based applications in it? Sure. It is more work than it needs to be? Absolutely. And the big question... Do I believe that Rapid Service Development to Contract-First Containers is the way of the future? Yes I do. Application servers will continue to be used when the architect chooses to use a platform specific component-based development model. Here, the focus is on 'building the application' (hence, "application server") versus building the services. There are some real challenges that app servers will face in the SOA environment. We can be sure that BEA and IBM will be morphing their offerings to make them more acceptable to the SOA crowd. However, I fear that they will leave all of the garbage behind as well. It's real simple - if your platform fails the loosely coupled test then so will your business applications that sit on top of them. Remember: "Rapid Service Development to Contract-First Containers". posted by jeff | 6:20 AM Tuesday, November 30, 2004 MS Patterns & Practices are Shallow The Microsoft Patterns & Practices group released a set of SOA principles. I was eager to see what the brains came up with but found myself beyond disappointed; I found myself actually in awe of their incompetence. Perhaps these are tough words but I'm so extremely disappointed in the group-think that is currently going on in the SOA world that I feel compelled to point it out. First, the show can be found here: http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?culture=en-US&EventID=1032262538&CountryCode=US MS stated four primary tenets to SOA. My first thought was "holy smokes, they got it down to four?!!!" Well, here they are: 1. Boundaries are explicit 2. Services are autonomous 3. Services share schema and contract, not class 4. Service compatibility is based on policy Boundaries are explicit - yep, hard to argue. But what does this actually say? How about this instead: "All exchanges of data, metadata, logic or other binary asset MUST BE exchanged through a contract. Runtime changes to code dependencies are NOT allowed." Services are autonomous - Most people know that I firmly believe that "services are not autonomous", they are synergistic. Services work together in a 'service ecosystem'. Services will influence each others metadata. In no way are services autonomous. Services share schema and contract, not class - I believe the point is that you want to share data using self describing, self validating, extensible schema systems that are ubiquitously deployed. That's cool - use an abstract typing system. Service compatibility is based on policy - Yes. Agreed. The patterns group then identified some "anti-patterns" or things not to do: 1. Avoid CRUDy interfaces. Don't use the CRUD pattern. Guys - this is so wrong I felt sorry for them. After listening to them babble on this for a while all credibility was lost. I think what they meant to say is "Use CRUD, but don't violate the age-old wisdom around fully encapsulating and abstracting the persistence mechanisms. " The second anti-pattern was avoid "loosely goosey" interfaces. The example they used was something like "runQuery(qry)". This one is tougher. If you really don't know what query combination needs to be run at design time then... you pretty much need something like "runQuery(qry)". This gets into a real interesting space that I wish MS would have talked about. Is it ok to pass XPath statement? Is it ok to pass an XQuery command? What is the right way to solve the runtime predicate problem? Surely the answer isn't "don't solve it". What about the surrogate key problem - where the only primary key is vendor specific key? The list goes on and on... MS has the brains to do this stuff right. I wish they would ask some of their smart people to help the patterns & practice group get this stuff right. posted by jeff | 6:33 AM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
