![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
From the IBM WebSphere Developer Technical Journal.
In each column, The EJB Advocate presents the gist of a typical back-and-forth dialogue exchange with actual customers and developers in the course of recommending a solution to an interesting design issue. Any identifying details have been obscured, and no "innovative" or proprietary architectures are presented. For more information, see Introducing the EJB Advocate.
Dear EJB Advocate,
I am a bit confused about all the hype around Service Oriented Architecture (SOA) -- and you seem to be caught up in it.
For example, in Is it ever best to use EJB components without facades in service oriented architectures, you describe best practices that one should follow in designing EJB components to make them "service oriented," such as making them coarse-grained and stateless.
The principles you describe are nothing new to those of us who built successful applications using distributed object technologies like CORBA and Enterprise JavaBeans. I suppose we have been "service oriented" all along.
I’ll admit that you get a better acronym out of "service oriented" architecture than "distributed object" architecture. But besides that, I have a serious question: is there anything new about SOA? Specifically, why should I care about the new Service Component Architecture and Service Data Objects specifications when I can do everything with Enterprise JavaBean components?
Signed,
SOA What
SCA represents a natural evolution on the server side
Dear SOA What,
The following statement may shock you, given that I am the EJB Advocate -- but just because you can code everything on the server side in Java using EJB components doesn't mean that you should. My take is that we are seeing a natural evolution of technology on the sever side similar to that which we saw with Java™ servlets on the client side.
In case you may not remember, Java servlets were introduced as a standard Java-based component to unify the proprietary Java APIs associated with specific Web servers, like Microsoft®’s Internet Server API (ISAPI). Java servlets enabled Java programmers to develop components to generate dynamic Web pages that could be run with a wider variety of Web servers from different vendors.
The most commonly used component is HttpServlets, which handled all the details of mapping the input from the HTTP request stream and output to the HTTP response stream, leaving the programmer free to concentrate on the details of the application flow logic.
As nice as this was, users soon found it tedious to generate HTML in Java code. For example, here is a snippet from an HttpServlet doGet() method to generate a simple dynamic "Hello world":
String name = request.getAttribute("name");
PrintWriter pw = request.getPrintWriter();
pw.println("<HTML>");
pw.println("<BODY>");
pw.println("<P>Hello " + name + "!</P>");
pw.println("</BODY>");
pw.println("</HTML>"); |
Various "template" languages quickly began to spring up that enabled you to embed Java code in the HTML, making the programming model more WYSIWYG (that is, declarative). Standardizing these approaches lead to the Java Server Page (JSP) specification. With JSPs, you can mix Java "scriptlets" (<%...%>) and "expressions" (<%=…%>) with HTML. For example, here is a snippet from a JSP to display the same "Hello world":
<% String name = request.getAttribute("name"); %>
<HTML>
<BODY>
<P>Hello <%=name%>!</P>
</BODY>
</HTML>" |
Just eliminating the parenthesis, quotes, and semicolons alone prevented countless thousands of bugs for Web application programmers. Further, eliminating the need to compile, package and deploy an HttpServlet component greatly reduced the turnaround time required to make a change -- whether to fix a bug or not.
But more importantly, JSPs led to an architectural change to separate the concerns of rendering the view from that to get the data. Web page designers and application programmers could suddenly work together without stepping on each others toes, each developing their own components in a language and style more suited to their role.
As an aside, the Enterprise JavaBeans specification emerged about the same time to separate the concerns even further. Adding EJB components enabled a true Model-View-Controller architecture for Web applications, where the Model was encapsulated by EJB components, the View was encapsulated by JSPs, and the Controller was encapsulated by HttpServlets.
Unfortunately, for rendering anything really useful, the interaction of Java scriptlets, expressions, and static HTML could get pretty complicated. For example, here is a snippet to produce a list of order IDs and status:
<%
OrderStatus orderStatus = (OrderStatus)request.getAttribute(
"OrderStatus"
);
OrderData d[] = orderStatus.orders;
int orderID = 0;
String status = null;
for (int i=0 ; i < d.length; i++)
{
orderID = d[i].orderID;
status = d[i].status;
%>
<P>Order Id =<%=orderID%> Status =<%=status%></P>
<% } %> |
The scriptlet to start the loop is rather complex. The scriptlet to end it is really simple, but often gets forgotten (or put in the wrong place). No tools exist that catch this and other common bugs when the JSP is being edited (like what happens in a Java IDE for "pure" HttpServlets).
In short, the problem remains that proper use of Java scriptlets and expressions is way too much to ask for the average Web page designer -- especially one who is not trained in programming.
The idea of custom JSP tags emerged and was standardized to minimize or even eliminate the need for Java programming. For example, IBM Software Services for WebSphere developed some custom tags that enabled iteration through a nested structure. These tags worked with the USEBEAN and GETPROPERTY tags provided as part of the base JSP tag library to greatly simplify the logic, as shown below:
<JSP:USEBEAN ID="OrderStatus" CLASS="com.onlinemall.data.OrderStatusData" SCOPE="request"/> <SW296:INDEXEDBEANPROPERTY BEAN="OrderStatus" PROPERTY="orders" VAR="order" TYPE="com.onlinemall.data.OrderData"> <P>Order ID=<JSP:GETPROPERTY NAME="order" PROPERTY="orderID"/> Status=<JSP:GETPROPERTY NAME="order" PROPERTY="status"/></P> </SW296:INDEXEDBEANPROPERTY> |
It was not long before frameworks like Struts arose to eliminate the need to write HttpServlets. Struts includes a rich set of custom tags for forms handling, but also a concept called "tiles" which enable declarative page composition. The important feature of tiles is the ability to recompose the page very easily without changing the underlying code components. Struts was one of the inspirations behind Java Server Faces (JSF) which standardizes the concept of declarative UI assembly from components. See Roland Barcia's excellent article on JSF versus Struts for more details.
The evolution on the client side from Java servlets to JSPs to custom tag frameworks to JSF was a step by step move away from procedurally programmed components that must be compiled toward declaratively assembled ones that can be interpreted (or at least compiled at run time). The Service Component Architecture (SCA) can be considered to be a similar evolution; enabling declarative assembly of server side components into an application.
I assume you have seen some of the other developerWorks articles on Service Component Architecture and Service Data Objects. If so, you have probably seen a diagram such as this one that shows an SCA component:
Figure 1. Sample SCA component
There are three important points of comparison between SCA and EJB components to remember:
Composition. With EJB components, Java is the only language available for implementation, so all composition of services into a larger assembly is done procedurally through Java. SCA not only supports Java as an implementation language, but also Business Process Execution Language (BPEL, which is being extended to handle such concepts as state machines, business rules, and human tasks, among others).
Invocation. The way you use a Stateless Session Bean is different than the way you use a Stateful Session Bean, Entity Bean, Custom Entity Home Method or Message Driven Bean. Specifically, each component type has a different way to locate and invoke its methods. SCA components enable a common invocation model for the client regardless of implementation type.
Data. Entity EJB components were never intended to be serializable for efficient usage outside of the scope of the container or transaction boundary. Therefore Data Transfer Objects evolved to fill the gap. SDO components provide a common abstraction for data flow between components regardless of scope.
The simplification of choices for Composition, Invocation and Data is what makes the evolution towards declarative assembly of applications from services possible in SCA -- just like JSPs and custom tags enabled the trend towards declarative assembly of UIs.
So to summarize, a major reason to care about SOA is that it will eventually enable business analysts to compose applications with minimal programmer support.
OK then,
Your EJB Advocate
Will EJB components go the way of the dinosaurs?
Dear EJB Advocate,
I hadn't really thought about how the trend towards declarative languages on the client side might apply to the server side. Now you have me wondering whether I should use EJB components at all!
Now sign me:
SOA Confused
EJB components are more like DNA: the building blocks of evolution
Dear SOA Confused,
The operative words in my summary statement were "eventually" and "minimal."
Eventually means that it will be a quite a while before the run time interpreters for BPEL will match the function and performance needed for all aspects of an enterprise application. For example, it is likely the case that "microflows" (logic intended to run in a single unit of work) will perform better as an EJB component.
Minimal means that even when the BPEL standard gets extended to enable business analysts to specify the logic through declarative concepts like state machines, human tasks, and business rules, there will always be some patterns of logic that are procedurally more easily specifiable. While it would be possible to create a "procedural" tag or visual programming language, it will be no simpler than Java -- and probably even more complex, given all the extra tag syntax to type or lines between components to draw.
In summary, it may come to pass that there will be less need to manually code EJB components; but it is likely that a few EJB components will still be needed in a complex enterprise quality application. For this reason, EJB components should be considered as the building blocks upon which extensions to the server side components are based.
Hope that I can sign you as "SOA Happy" after this!
OK then,
Your EJB Advocate
-
Java Platform, Enterprise Edition (JEE) specification (formerly J2EE); the '2' was dropped in order to separate the main concept of a Java platform for the enterprise, from a specific version.
-
Enterprise Java Programming with IBM WebSphere, Second Edition by Kyle Brown, Gary Craig, Greg Hester, Russell Stinehour, W. David Pitt, Mark Weitzel, JimAmsden, Peter M. Jakab, Daniel Berg. Foreword by Martin Fowler.
-
The EJB Advocate: Is it ever best to use EJB components without facades in service oriented architectures? by Geoffrey Hambrick
-
JavaServer Faces (JSF) vs. Struts: A brief comparison
-
Service Component Architecture
-
Introduction to Service Data Objects
Geoff Hambrick is a lead consultant with the IBM Software Services for WebSphere Enablement Team and lives in Round Rock, Texas (near to Austin). The Enablement Team generally helps support the pre-sales process through deep technical briefings and short term Proof of Concept engagements. Geoff was appointed an IBM Distinguished Engineer in March of 2004 for his work in creating and disseminating best practices for developing J2EE applications hosted on IBM WebSphere Application Server.
Table of contents
Next steps from IBM
With the WebSphere Application Server you can benefit from the simplified EJB 3.0 development experience, new persistence model, and interceptors.
- Try: Download a free trial version of WebSphere Application Server Community Edition, the lightweight Java 5 application server with robust EJB 3.0 funtionality.
- Article: Learn how call patterns and components involved in making calls to EJB components deployed in the EJB container operate in WebSphere Application Server.
- Tutorial: This tutorials shows you how to create an enterprise J2EE application that implements both Plain Old Java Object (POJO) and EJB Web services endpoints.
- Demo: Watch this demo and learn how to configure and use the WebSphere Application Server and the Eclipse IDE with the Web Tool Project Platform.
- Buy: WebSphere Application Server
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
