Web.Services.Business.Objects.And.Component.Model.pdf

Web Services, Business Objects and Component Models

Web Services, Business Objects and

Component Models

White Paper - July 2001 (updated October 2001)

By Philippe Mougin & Christophe Barriolade, Orchestra Networks

Web services technologies such as SOAP, UDDI and WSDL will facilitate inter-enterprise

cooperation on the Internet. Using Web services, your information system will be able to

communicate much more easily with your partners' information system than in the past.

This leads to an important question: what technology should be used for implementing

Web services themselves? The general trend is to use top-level approaches which

combine workflow and object modeling. This combination of Web services and a dynamic

object approach is shaking up standard business component models i.e. EJB, COM and

CORBA. New, more suitable technologies are emerging. Here, at Orchestra Networks, we

use Web services to develop our technology. This document is a technical analysis based

on our experience in this area.

www. orchestranetworks .com

Foreword by

Alain Lefebvre, Groupe SQLI and

Jean-Christophe Cimetiere, CEO,

TechMetrix Research.

---------------------------------------------------------------------------------------------------

Web Services, Business Objects and Component Models

Table of contents

Foreword: The true nature of Web Services

Web Services, a definition

Industry recognition and support

Introduction

What do Web services offer?

Web services technologies

Moving to the business objects approach

COM 13

COM past and present 13

Does COM/DCOM offer a distributed call protocol for Web services? 13

Does COM offer support that is suited to development using business

objects? 14

Tomorrow: .NET, C# and the Common Language Runtime 14

CORBA 16

A multi-language object standard 16

Does CORBA offer an infrastructure for distributed calls that can be used

for Web services?

A protocol not suited to the Web

The problem of static glue

CORBA's failures on the Internet

CORBA as a Web services directory?

Where can CORBA's distributed capacities be used?

CORBA, for high-performance, inter-language communication

The limitations of CORBA's multi-language model

CORBA faced with optimized single-language models

Is CORBA suited to business object development?

The CORBA business object view

Beware!

EJB

The EJB vision 23

Does EJB technology offer a distributed calling protocol that can be used

for Web services?

Protocols that are not suited to the Web

Limited interoperability

EJB vs. SOAP

EJB for business object modeling within Web services

EJB, the quest for location transparency

Complex EJB development

A static glue approach

Pay attention to performances

Difficulties of the object-oriented approach using EJBs

---------------------------------------------------------------------------------------------------

Web Services, Business Objects and Component Models

EJB 2.0

Conclusion: EJB and object modeling

What technologies can be used for developing Web

services in Java?

J2EE

HTTP

XML

RPC is not the only model

Persistence framework and transactional object monitor

A domain in turmoil

An attempt at standardization

Conclusion

Native connection to Web services

Workflow for assembling Web services

Separating layers and customization

Integrating the concept of collaboration

References

About Orchestra Networks

About SQLI -TechMetrix Research

---------------------------------------------------------------------------------------------------

Web Services, Business Objects and Component Models

Foreword: The true nature of

Web Services

Establishing a Web presence or developing distribution channels is both long and costly.

On achieving these objectives you then must offer enough content and features to

encourage visitors/customers/partners to venture beyond the homepage and to come

back later.

Most Web sites which attract a lot of traffic use content syndication to enrich their own

offering. They base themselves on Web services to extend their functionalities. Look at

Yahoo! – most of its features come from other Web sites: travel, weather, paydirect,

maps and Web searches using Google services. These features are integrated into the

portal as native services. Each supplier therefore avails of greater exposure and/or

income and enables Yahoo! to offer more services to users.

The example of Yahoo! illustrates the basic concept of Web Services. The problem is

that, up until now, integrating services from different companies was very difficult. While

sophisticated middlewares (EAI solutions, for example) are very useful for one-to-one

integration, many-to-many integration is a whole different ballgame which requires

specific development for each new service to be integrated. Similarly, for service

providers, adding a new partner generally means customizing the source code.

The good news is that Web services are no longer a mere concept but a technological

reality. The first chapters of this story have already been written by some software

vendors (Microsoft, IBM-Apache, Ariba, Bowstreet...). All of these vendors are working to

produce key standard protocols (i.e. SOAP, WSDL and UDDI) so as to make Web

Services easier to use, and they also provide tools and solutions for creating Web

Services.

Web Services, a definition

According to Mark Colan (IBM), Web Services are "Internet-based modular applications

that perform a specific business task and conform to a specific technical format." So, if

certain processes from your applications can be invoked over the Internet, within a

method and with a standard format, then you are already a server of Web Services.

Similarly, if you call on certain processes external to your applications via Internet, then

you are already a client of Web Services.

Everyone understands that for this sort of openness to work, you need standardized

formats and methods. The good news is that this all exists and has been available since

April of last year: SOAP 1.1.

SOAP is a Remote Procedure Call (RPC) protocol that uses standard Internet protocols

for transport - either HTTP for synchronous calls or SMTP for asynchronous calls. SOAP

uses XML for the envelope (i.e. the format of data transmitted). The abbreviation SOAP

stands for Simple Object Access Protocol, but we could also translate it as "Service-

Oriented Architecture Protocol."

---------------------------------------------------------------------------------------------------

Web Services, Business Objects and Component Models

Of course, this is all very well, but SOAP is still just an RPC, calling low-level functions

and leaving pretty much everything up to developers. In order to make it easier to use,

there is a format for describing services that can be invoked by SOAP — WSDL (see [1] ) .

WSDL can be seen as a complement to SOAP, as it facilitates interoperability between

Web services. Like IDL (Interface Definition Language), which acts as a service describer

with CORBA, WSDL (Web Service Description Language) is an XML syntax to describe

Web services. The specifications for WSDL come from a joint initiative by Microsoft, IBM

and Ariba. More and more SOAP implementations support this description language; with

WSDL, applications that use SOAP can self-configure exchanges between Web services,

while hiding most of the low-level technical details.

Industry recognition and support

Not only does SOAP rely exclusively on well-established standards, but it is also widely

recognized by the major market players such as Microsoft, IBM, Oracle, and even Sun.

Even Microsoft's MS.net initiative has SOAP at its core, though the protocol has been

taken on as a W3C project and has a multitude of open source implementations.

Within this context, SOAP and WSDL can be seen as the main pieces in the puzzle, but

they do not form the entire schema on their own. As was the case for sites aimed at

end-customers, Web Services dedicated to enterprises are set to experience a massive

boom, if we are to believe the predictions. Industry professionals, confronted by an

extremely rich offering in which it is hard to identify anything, will then have to face the

eternal question of "Where — and how — does one find information?"

What the market needs is a simple service enabling players to:

•

Find the right partner (the one offering the Web Service(s) you need)

•

Get the information necessary to be able to embark on electronic exchange with the

partner (access a WSDL document for instance).

This is where UDDI (Universal Description, Discovery, and Integration) comes in. UDDI

was the brainchild of several of the giants of the IT industry (IBM, Microsoft and Ariba,

the very same three that were behind WSDL… and it's no coincidence); it is essentially a

vast worldwide database of services offered on the Web. At least 130 companies have

promised to support UDDI. 36 were members of the original project and a further 94

have joined the movement since. The project has already managed to gather together

companies such as Accenture, Cargill, Clarus, CommerceOne, Compaq, Dell, I2, ICG,

Rational, Sabre, SAP, Sun, Tibco, WebMethods. All the players involved see it as a major

step forward.

UDDI offers a technical framework that is independent from platforms and totally open,

so that enterprises can find one another, define how they will interact on Internet, and

define how information should be shared using a worldwide registration system. The

result of this project, according to its promoters, will be that enterprises will be able to

enter the B2B world a lot quicker.

So the technical schema that we can draw up for Web Services features the following:

•

XML: format for data exchange and description

•

SOAP: protocol for calling Web Services

•

WSDL: format for describing Web Services

UDDI: central organization for registering, finding and using Web Services

•

---------------------------------------------------------------------------------------------------

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: