email article printer friendly

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).