Standards for Service-Oriented Architecture
Why Cutting-Edge Technology Doesn't Mean Vendor Lock-In
by Scott Dietzen

Posted May 24, 2004

BEA CTO Scott Dietzen delivers the Tuesday keynote address at eWorld 2004

XML and Web services are emerging as the platform for service-oriented architecture (SOA), both for intra- and inter-enterprise communication. As the first Java integrated development environment (IDE) for both authoring and consuming SOA, WebLogic Workshop inherently pushed the envelope with proprietary innovations. Since then, BEA has delivered on the promise of investment protection for these innovations via mechanisms ranging from open standards to open source. BEA's commitment to investment protection frees developers to take advantage of its cutting-edge productivity and integration features without fear of vendor lock-in. Let's take a look at the key SOA-based innovations in Workshop and how investment is protected in each case.

What is SOA?
XML and Web services are hot technologies today because of their role in realizing service-oriented architecture (SOA). SOA is about unleashing the shared business services that are currently bound up in monolithic and often isolated applications. By defining or surfacing such "service access points" for individual business operations, IT organizations can:

  • More closely align IT resources with their business functions
  • Create more dynamic and cost-effective systems via an optimal mix and match of
    • Buy vs. build
    • In-sourcing vs. out-sourcing
  • More rapidly deliver composite applications (think "Web flows" and "work flows") that provide unified, task-oriented views across the business
  • Achieve greater application life-cycle flexibility by more incrementally managing requirements and change
  • More easily replace opaque, "black box" systems with infrastructure that offers "business transparency"—that is, deliver real-time business intelligence on the aggregate information flowing through applications.

Objects and components have been successful at delivering reuse within an application (where an application is defined as code that is developed and deployed as a unit). SOA, however, depends on achieving reuse between applications. The use of SOA for interconnecting disparate applications is not at all new—consider some the prior effort that has gone into defining distributed, inter-application communication architectures (don't sweat any new acronyms):

  • Synchronous (RPC-oriented): CICS Distributed Program Link (DPL), Distributed Computing Environment (DCE), Distributed Component Object Model (DCOM), Common Object Request Broker Architecture (CORBA) IIOP, Java Remote Method Invocation (RMI), Relational Database Management System (RDBMS) stored procedures, and so on
  • Asynchronous (messaging-oriented): CICS Transient Data Queues (TDQs), Tuxedo ATMI, IBM MQSeries, Tibco Rendezvous, Microsoft Message Queuing (MSMQ), Java Message Service (JMS), and so on.

What makes application integration so hard (and hence why we, as an industry, have yet to realize universal SOA) is that applications are built by different groups of people, in different places, and deployed on different schedules. Any approach that depends upon multiple applications sharing a common object/data model (as, to a degree, do the previously mentioned) flies in the face of this reality.

The Role of XML and Web Services
Abstraction and loose coupling is the key to multiple independent applications successfully sharing infrastructure. Consider two run-away successes: SQL and HTML. With SQL and HTML, application developers must decouple their internal object model from how data is stored and searched or displayed on the screen, respectively. If we just consider the needs of an individual application, such choices are often non-optimal. But when the aggregate need across business applications is weighed, the loose coupling that comes out higher-level abstraction proves its worth (see Figure 1).

XML is an ideal candidate for loosely coupled inter-application data sharing: XML

  • Is self-describing
  • Is independent of hardware, programming language, container, and so on
  • Accommodates independent change/versioning (is less fragile to extension or application changes)
  • Is "least common denominator" (verbose, CPU-intensive, and so forth, just like HTML)

XML is to HTML as the Web services stack is to HTTP/S. WS-* (the collection of Web services specifications with the broadest industry support) defines enterprise quality of service for moving XML between applications. Although space constraints do not allow a review of the individual WS-* technologies herein, suffice it to say that:

  • All qualities of service of the prior art in distributed computing is either already available in the WS-* stack or is on the roadmap for near term publication (and standardization).
  • WS-* provides communications infrastructure for both synchronous operations (generally for query) and asynchronous operations (generally for business transactions) within a single, unified framework.
  • The WS-* family is the first to scale to meet integration challenges intra-enterprise enterprise application integration (EAI) and even inter-enterprise business to business (B2B). Preceding technologies have never come close to achieving the critical mass required for a transitive closure of participants (that is, working with all of an enterprise's own business systems, the business systems of their partners, of their partner's partners, and so on).
  • The WS-* family allows IT to reduce costs and vendor lock-in by leveraging portable and interoperable industry standards.

WebLogic Workshop
With its first release in 2002, WebLogic Workshop became the first Java IDE focused on SOA authoring via XML and Web services. With the release of BEA WebLogic 8.1 in 2003, we have transformed WebLogic Workshop from a 1.0 Web services tool into a uniquely broad spectrum development environment for authoring, consuming, and orchestrating SOA-based applications. Workshop makes it possible to build most every variety of SOA-oriented code including pure Web applications, J2EE programs, portals, business process automation, XML aggregation/transformation, message brokering, and so on.

In delivering the first IDE for SOA (prior to Workshop 8.1, the state of the art in integration was a hodgepodge of unintegrated tools), BEA did indeed introduce proprietary innovations. Innovation and proprietary, after all, inherently go hand in hand. There is overwhelming precedent that standards bodies are far better at tweaking and ratifying heretofore proprietary innovations than innovating themselves: TCP/IP, SQL, the Web, Java, and XML/Web services all came about this way. Consider that the first release of WebLogic (arguably the industry's first Web application server way back in 1996) included proprietary innovations for Web page rendering, database access, event processing, server-side components, and so on. What distinguished WebLogic from its proprietary brethren (with the notable exception of IBM WebSphere) was an early aggressive commitment to API standardization (servlets/JavaServer Pages [JSP], Java Database Connectivity [JDBC], JMS, Enterprise JavaBeans [EJBs], and so on).

BEA has been just as vigorously pursuing investment protection for our Workshop-based innovations for SOA. We have a variety of vehicles through which we work to ensure investment protection:

Protocols:

  • The BEA/Microsoft/IBM WS-* collaboration—the WS-* family has largely been initially authored by these three vendors (prior to standardization)
  • WS-* standardization—the World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS)
  • WS-* validation and profiling—the Web Services Interoperability Organization (WS-I).

Programming models:

  • BEA/IBM Java collaboration—announced in 2003, this collaboration was modeled on the BEA/IBM/Microsoft Web services collaboration. It is focused on accelerating server-side Java API standardization, in particular for SOA
  • The Java Community Process (JCP)
  • European Computer Manufacturers Association (ECMA) (for example, XScript)
  • W3C (for example, XQuery)
  • OASIS (for example, Business Process Execution Language [BPEL])
  • Portability of Workshop artifacts—if Workshop produces a J2EE-standard application, then this artifact can run unmodified in any other J2EE-compliant container
  • Open source software (OSS)—open sourcing runtime infrastructure that maps to J2EE, thereby enabling portability to containers other than WebLogic.

Workshop Investment Protection Top Ten
For virtually every innovation surfaced within the WebLogic Workshop 8.1 IDE, BEA has either delivered or announced an approach to long-term investment protection for our customers and partners. Let's consider the top 10 Workshop innovations and how investment in Workshop-built applications are being protected.

(10) Metadata and JSR-175: Workshop makes heavy use of JavaDoc annotations for capturing application metadata—declarative instructions to the container that encapsulate common but often complex behavior that the developer would rather not have to program over and over again. Smart tools like Workshop provide structured support (such as property sheets) for authoring and updating such metadata. By including such metadata in-line with the application code, developers have fewer artifacts to flip between while programming (XML deployment descriptors are still generated by the tool as appropriate). At least in part due to the popularity of this approach, Sun and the rest of the Java community have elected to embrace extensible metadata directly within the Java language (JSR-175, which is included within J2SE 1.5). Existing Workshop artifacts will be automatically upgraded to JSR-175 syntax with the forthcoming release of WebLogic.

(9) BPEL, BPELJ, and JPD: The BPEL specification was initially authored by BEA, IBM, and Microsoft—a best-of-breed blend of intellectual property from Microsoft XLANG, IBM WSFL, and BEA Process Definition for Java (JPD). Since then, BPEL has been transitioned to OASIS for standardization.

BPEL is an XML-based programming language that is also written in XML, and as such is platform independent (it can run on Java, .NET, and so on). BPEL is for both defining (authoring) and for orchestrating (writing workflows that consume) Web services. All data manipulation in BPEL is done with XML and Web services. Conditions, for example, are written in XPath. The sending and receiving of messages uses WSDL PortTypes. And so on.

BPELJ (BPEL for Java), on the other hand, defines how to intermix BPEL and Java (not unlike the way JSP allows HTML and Java to be intermixed). With BPELJ, conditions and data manipulation can be accomplished with "snippets" of annotated Java code. This allows traditional enterprise computing, such as database access through JDBC, to be seamlessly integrated with BPEL-based business processes. BPELJ allows Java/J2EE components, such as JavaBeans, to be orchestrated in the same way that Web services are orchestrated.

The BPELJ technical white paper was jointly published by BEA and IBM in March of 2004, and is already the subject of Java standardization via JSR-207 (BEA is the specification lead). BEA is already moving to implement BPELJ in our next major release of WebLogic, and will moreover provide for the automigration of workflows defined in Workshop 8.1 (BPELJ's predecessor—Process Definition for Java) to BPELJ.

With WebLogic Integration 8.1, we uniquely combined state-of-the-art graphical composition of business processes with the "get out of jail free card" ability to drop into standard Java/J2EE to do the more difficult programming—all without leaving the unified development environment of Workshop. At the same time, Workshop makes it much, much simpler to construct message-driven code without sacrificing investment protection. Whether synchronous or asynchronous, Web services or JavaBeans, HTTP or JMS, WS-* or alternate (RosettaNet, ebXML, EDI, and so on), BPEL/BPELJ and Workshop make it easy.

(8) XMLQuery: XMLQuery (or XQuery) is rapidly emerging as a "SQL for XML"—that is, XQuery is poised to become the principal language for manipulating, transforming, and aggregating XML data. XQuery is the subject of standardization at the W3C. XML Query is far easier to use and roughly six times faster than XSLT for transforming XML. (The complexity and slowness of XSLT is why most competing integration vendors have chosen proprietary alternatives.) Moreover, tools like Workshop allow for the drag-and-drop construction of transforms ("XMaps") as well as aggregated XML documents (such as a universal customer record built by querying across the existing enterprise applications—enterprise resource planning (ERP), customer relationship management (CRM), legacy, and so on). The latter is what BEA calls "liquid data." The implementation of XQuery in WebLogic 8.1 is well ahead of other commercial products, and is already integrated with WebLogic Workshop, WebLogic Integration, and Liquid Data for WebLogic.

(7) Java Web services (JWS) and JSR-181: Workshop 1.0 introduced metadata to make the authoring of Web services nearly as simple as writing plain-old Java objects (POJOs): After all, why should the developer have to hand code all of the hundreds of lines of J2EE logic required to make a simple Web service reliable and/or conversational time and time again? The base annotation syntax of Workshop JWS is being standardized within JSR-181 (BEA is the specification lead). Here's a very simple example of a Web service produced by POJO plus two JSR-181 annotations: 

@WebService
public class 
	StockQuoteService {
	@WebMethod
	public float 
		getLastTradePrice(
		String tickerSymbol){
	// ...
	}
};

With further annotations, schemas, and/or WSDL it can be customized:

@WebService(
	name="ExampleStockQuoteService",
		targetNamespace=
		"http://www.openuri.org/
		ExampleStockQuoteService/
		MyExamples")

public class StockQuoteService {
	@WebMethod(operationName=
	"GetLastTradePrice")
	@DocumentWrapper(
		requestElement(name = 
		"TradePricesRequest")
	responseElement(name = 
		"TradePriceResponse"))

	public float getLastTradePrice(
		String tickerSymbol) {
	}
};

Of course, Workshop's JWS goes on to define annotations to "turn on" richer quality of service features of the Web service architecture: 

@WebService(targetNamespace = 
	"http://workshop.bea.com/
	CreditReport")
@Conversation(maxAge="1 hour", 
	maxIdleTime="30 minutes")
public class CreditReportService {
	@WebMethod
	@ConversationPhase(START)
	@Reliable
	public void requestReport(
		String ssn) {
	}
	@WebMethod
	@ConversationPhase(CONTINUE)
	public ReportResult 
		getCurrentStatus() {
	}
	@WebMethod
	@ConversationPhase(FINISH)
	public void cancelReport() {
	}
};

Although such richer annotations will not be part of the first release of JSR-181 (in part because many containers, other than WebLogic, do not yet offer reliable and conversational Web services), BEA is nevertheless migrating JWS files to use JSR-175-based metadata as well as ensuring that, with a thin runtime mapping that can be open sourced, full JWS files can be deployed on any J2EE container. In subsequent releases of JSR-181, we hope to incorporate the rest of the JWS capabilities.

(6) EJBGen and EJB "3.0": EJBGen provides dramatic productivity gains for EJB programming. EJBGen uses JavaDoc annotations to make it far easier to turn POJOs into EJBs. EJBGen is now part of WebLogic Workshop, which makes the syntax a snap to learn. Looking forward, we are moving the syntax for EJBGen to JSR-175-based metadata (and Workshop will, of course, provide automigration to the new syntax): 

@Session public class 
	PurchaseOrderService {
	public String 
		submitPurchaseOrder(PO po) {}
}

In addition, BEA is working with the greater Java community to hopefully standardize such annotations for the next major revision of the EJB standard. More importantly, today any existing EJB project can be loaded into Workshop and edited with EJBGen, and the output of EJBGen is a standard EJB project that can be run on any J2EE-compliant container.

(5) XMLBeans: The major benefit touted for XML-based application integration is loose coupling—loosely coupled applications are insulated from changes to XML/Web service interfaces and vice versa. In practice, however, the existing programming models for XML can be tedious, error-prone, and fall well short of the loose-coupling ideal. XMLBeans is an "XML-schema compiler" (it produces a Java class wrapper from an XML schema) that addresses all of these challenges, as well as provides for efficient and lossless manipulation of XML. Looking forward, XMLBeans is tracking emerging Java-XML binding standards. XMLBeans is already available as an Apache open source project for use in application servers other than WebLogic.

(4) XScript: Many operations on XML can be more simply performed in-line using a scripting language with native support for XML. Workshop 1.0 introduced XScript (casually described as "JavaScript with XML extensions") for precisely this purpose. BEA founded and led the ECMAScript for XML (E4X) group within ECMA to contribute this technology to the international Java/ECMAScript language standard. In March of 2004, E4X was unanimously approved by the ECMA TC39 (Programming Languages Committee), making ECMAScript the first mainstream programming language to include native support for XML. The ECMA General Assembly is expected to provide final approval for an international E4X standard in June 2004.

(3) Page Flow for Java (JPF) and Struts: Apache Struts is the de facto standard model-view-controller framework for Java-based Web user interfaces. The trouble has been that authoring Struts applications is code intensive and overly complex. Workshop's Page Flow for Java (JPF) enables the drag-and-drop programming of sophisticated Struts applications by graphically managing the data and business logic flow. The run time for JPF is a standard Struts extension, which BEA has already provided as a portability kit for Tomcat and other J2EE/Servlet 1.3 containers. Moreover, in the next major release, Workshop will also support Java Server Faces (JSF, JSR-127), allowing Struts- and JSF-based components to be easily mixed and matched.

(2) Portlets, WSRP, and content management: Iterative development of portals has never been easier than with WebLogic Portal 8.1's drag, drop, and view capabilities. However, the ease of development need not come at a cost of vendor lock-in. The most fundamental building blocks of a portal are being standardized by the Java Portlet Specification (JSR-168), Web services for Remote Portals (WSRP, standardized at OASIS), and the standardized interface to content management solutions (JSR-170). Workshop supports the use of external applications in BEA portals as Workshop can (automatically) wrap existing Web user interfaces in portlets or consume WSRP-enabled applications. In addition, Workshop provides the ability to create standard Java applications and to create WSRP producers for easy incorporation within non-BEA portals.

(1) Controls: Controls are a server-side component model for drag-and-drop orchestration—the graphical programming "Web-flows" (JPF) and "workflows"/business processes (JPD and BPELJ). Controls are reusable components for dramatically simplified access to J2EE-based resources with rich IDE integration (custom wizards, properties, and graphics). Controls also provide runtime support for smartly handling container services like automatic resource management, transactions, security, asynchrony, and component nesting. The Workshop Controls framework is extensible—more than 100 independent software vendors (ISVs) are now offering their own controls to enable customization/orchestration of their value-added services using the Workshop tool and look-and-feel. Most importantly of all, when a customer or ISV builds a control, that one control can be reused inside a business process, from a Web application or portal, to build a Web service, or anywhere else within a WebLogic application.

Looking forward, BEA is reworking the Controls run time for portability to other J2EE-compliant containers. At the very least, this would enable the open-sourcing of a thin Controls run time that would ensure portability of Workshop Controls to other J2EE-containers. Our intent, however, is to work with the rest of Java community to make Controls a fully sanctioned Java standard. Stay tuned.

Wrap up
Of course, it was innovation rather than investment protection that created such excitement around WebLogic Workshop in the first place. Workshop is the first application framework to make J2EE programming as easy as PowerBuilder or Visual Basic, the easiest and richest development environment for SOA and Web services authoring and orchestration, and the first integrated tool and run time for application integration. Until Workshop 8.1, developers seeking to deliver an end-to-end integration solution, generally had to deal with distinct tools/run times for each of the following:

  • Business process design/modeling
  • Business process execution/management
  • Transformation
  • Adapter selection/customization
  • J2EE/Web services development/deployment
  • Messaging and message brokering
  • User interface (UI) design
  • Portal UI aggregation
  • B2B
  • Collaboration

(Consider how ironic this is—that before the developer could get any integration work done pre-WebLogic Workshop 8.1, they generally had to spend considerable time integrating their integration technologies!)

This top 10 summary shows how BEA is keeping its commitment to providing our customers with investment protection through standards, through open source, through portability kits, through whatever mechanism will best meet our customers' investment protection needs. As always our customers can use the latest cutting-edge BEA innovation, secure in the knowledge that their investment will be protected long term. BEA understands that the days of vendor lock-in are over, at least within the Java Community. Customers demand investment protection and BEA provides it.

Let me leave you with some final food for thought: Don't forget the "architecture" in service-oriented architecture. The real challenge to achieving SOA is not vendor technology. Rather the challenge is defining the right reusable business services (often via wrapping legacy applications), and then orchestrating those services optimally for your business:

  • Should business services be synchronous (RPC-style) versus asynchronous (messaging-style), or both?
  • Should business services be grouped in a transactional unit of work or rather organized as a set of messages and compensating actions in the case of failure?
  • How can maximal reuse of inter-application schemas be achieved? (How can we limit the proliferation of schemas representing very common data types like customer and order, since schema proliferation complicates interoperability?)

Such application architectural considerations are independent of (and generally far more important than!) underlying technology selection.

Acknowledgements: As usual, I had quite a bit of help with this article. Thanks in particular to Yaron Goland, John Beatty, Gordon Simpson, and Matt Mihic.

About the Author
Scott Dietzen is CTO of BEA Systems Inc.



© Copyright 2001-2005 Fawcette Technical Publications | Privacy Policy | Contact Us