Components, Remoting Middleware and Webservices - and how it all fits together

Components, Remoting Middleware and Webservices

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e www.voelter.de © 2002 Markus Völter. - 1 -

Components, Remoting Components, Remoting Middleware and WebservicesMiddleware and Webservices

- and how it all fits together- and how it all fits together

Markus Vö[email protected]



C O N T E N T S

• Introduction

• Components•Server-Side Component Infrastructures

•Are Webservices Components?

• Reuse Issues

• Using Components and Webservices

• Challenges for Service Oriented Computing

• Traditional Middleware & Webservices

• Webservices and EAI

• The Future

• Summary



C O N T E N T S

• Introduction



• Reuse Issues





• The Future

• Summary



Why this presentation?

• Maybe you‘ve heard some of the following statements:

•CORBA is dead, we‘ll use Webservices instead

• .NET primarily uses Webservices for remote communication

•Webservices are the „components of the future“.

•EAI problems are solved with webservices

•Webservices are too slow – cannot be used in practice

• Well, all this is not really true. This session tries to classify the different technologies and outline their use.



C O N T E N T S

• Introduction



• Reuse Issues





• Summary



Definition of Terms: Components

• Clemens Szyperski defines a component as

“A software component is a unit of composition with contractually specified inter-faces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.”

• Important aspects of this definition:•Contractually specified interfaces

•Explicit context dependencies only

•Can be deplyoed independently

•Composition by third parties



Components: A Taxonomy



C O N T E N T S

• Introduction



• Reuse Issues





• The Future

• Summary



Server-Side Component Infrastructures

• EJB, COM+ and (maybe someday) CORBA Components are examples of server-side component infrastructures.

• Most important principle: Separation of Concerns

•Functional concerns of an application are factored into reusable Components

•Technical concerns are provided by a standardized entity, a so-called Container

• Having this container is the real benefit of server-side component infrastructures.

• And the rest of Szyperski‘s requirements?



... Contractually specified interfaces ...

• Every component has an explicitly described interface defined in Java, MSIDL or CIDL.

• Clients can only invoke operations defined in this interface.

• The implementation is not visible or accessible to cliens.•For example, it can be exchanged,

•Or it can be dynamically assigned

• Unfortunately, the interface definition contains no semanticinformation (except for types).•Pre/Postconditions could be an

example...



... Explicit context dependencies only ... (I)

• Lifecycle callback operations are used by the container (context) to control the lifecycle of a component instance.

• Examples are related to pooling, passivation, creation, destruction, etc.



... Explicit context dependencies only ... (II)

• Annotations („Deployment Descriptors“) specify what a component instance expects from its container, regarding

•Services provided by the container (transactios, security, ...)

•Available resources in the environment (database connections, message queues, ...)



... Explicit context dependencies only ... (III)

• A component definition includes a specification of what other (component) interfaces are required for it to run successfully.

• The container makes sure these interfaces are available to the component at runtime.



... Can be deployed independently ...

• Server-side components require an explicit installation step to make it available to the container.

• At this time, all context dependencies are checked and ensured.



... Composition by third parties ...

• All the previously mentioned aspects help in making it useable by third party application assemblers.

• In addition, components provide a controlled way for configuration (using parameters and the annotations).

• Also, a packaging mechanism is defined.



C O N T E N T S

• Introduction



• Reuse Issues





• The Future

• Summary



So: Are Webservices Components?

• Webservices do have a contractually specified interface:•WSDL is used here for definition,

•And SOAP for accessing it

• Webservices specify absolutely nothing about•How it should be implemented

•How it is deployed

•How it can be configured

•Who or what provides additional services to it such as transactions or security (this might change...)

• Does this mean there is something missing from webservices (i.e. „are webservices bad?“?)

NO! It just means, that webservices are not components!



Comparing Webservices and CORBA

• Let‘s briefly compare some webservices features to CORBA (as an example of a remoting middleware) features:

• Note that both technologies can use static proxies and dynamic invocations (manually assembling a SOAP request vs. using the DII in CORBA).

• Main difference (in addition to transport):Webservices don‘t use the concept of object identity. A webservice implementation is thus no object.

Webservices CORBA

Webservice Stateless-Objekt

WSDL IDL + Interface Repository

SOAP + HTTP IIOP

UDDI Naming, Trader



Webservices as a remoting middleware

• So, in essence, webservices are just another remoting middleware, like CORBA, DCOM, Java RMI.

• Of course, there are some distinguishing features, mainly the focus on (MS-Java) interoperability, by using XML and HTTP as the basic technologies.



C O N T E N T S

• Introduction



• Reuse Issues





• The Future

• Summary



Reusing Webservices

• Reuse of webservices is intended to happen based on clients using services hosted by other machines/networks/companies.

• The service implementation does not move, it is not redeployed. • this is the concept of Application Service Providing (ASP)

• To make it reusable, we do not need to care about•How it should be implemented

•How it is deployed

•How it can be configured

•Who or what provides additional services to it (such as transactions or security)



Reuse for Webservices and Components

• Components (and their implementations) are bought from a 3rd party and installed on my own container or infrastructure.

• This is why we need to take care of deployment/configuration/ additional services

A

C D

B

Client

Container

• (Web-)services (and their implementations) are used as is on the service provides machine.

• This is why we do not need to take care of deployment/configuration/ additional services

A

A's provider

B

B's provider

C

C's provider

D

D's provider

netw ork

Client



Reuse for Webservices and Components

• Components (and their implementations) are bought from a 3rd party and installed on my own container or infrastructure.

A

C D

B

Client

Container

• (Web-)services (and their implementations) are used as is on the service provides machine.

A

A's provider

B

B's provider

C

C's provider

D

D's provider

netw ork

Client

Component-based Development

(CBD)

Service-oriented computing

(SOC)



C O N T E N T S

• Introduction



• Reuse Issues





• The Future

• Summary



How it fits together

A

A's provider

C's provider

netw ork

Client

B1

B3 B4

B2

B's Cont.

D2

D's Cont.

D1

netw ork

C



How it fits together (II)

• The fact that this is the way it should be can be observed by the fact that most webservice toolkits are built on top of component infrastructures:•Webservices based on (stateless session) EJBs

•Webservices publishing COM+ objects

• Webservices can be used to publish independent services (based on component infrastructures) to remote clients, typically over WANs.•Of course, service implementations need not be based on

component technologies.

•And of course, you can also use Webservices in a LAN to connect the Microsoft world with the rest of the software universe.



C O N T E N T S

• Introduction



• Reuse





• Summary



SOC-Characteristics

• Services are typically stateless. This helps scalability and other technical isssues.

• There is no concept of an object ID.

• Services should ideally be atomic transactions, avoiding the need for coordination of long-running transactions.

• The vision of service-oriented computing has a lot in common with P2P systems:

Failover, discovery, quality of service, mobility, repositories, replication, distributed garbage collection, service relationship lifecycles, evolution of services, naming, adressing, negotiation, trading, coordinations, elections,



SOC-Challenges: Technical issues

• Security is extremely important:

•Client and service provider have to authenticate.

• Important business data that is sent to and from the provider needs to be tamper-proof and secret, encryption and signatures are required.

•Access control, or authorization is necessary, especially if clients‘ data is also stored at the provider‘s site.

•Non-repudiation is necessary, to make sure the client cannot claim that services have not been fulfilled by the provider.

•Auditing is also important, especially to provide reliable billing for clients.



SOC-Challenges: Technical issues (II)

• Distributed Transactions are important to usefully combine services from different providers.

•DTCs typically required some form of transaction coordination (for example for 2PC or 3PC). Who‘s task is that? The client‘s? Somebody in the middle?

• Workflow specifications are necessary to define the legal sequences in which service operations can be invoked (pre- and postconditions).

• Discovery, Mobility, Failover, QoS, self-reconfiguration, ... (see P2P systems )



SOC-Challenges: Structures and semantics

• Clients and servers (or service consumers and providers) need to agree on the structure and the semantics of operations and the exchanged data.

•This is of course also necessary to some extend in the case of CBD, but it much more important for SOC.

•Mappings based on semantic metamodels are necessary.

• This has traditionally been a big problem:

•CORBA tried this, too (CORBAMed, Manufactoring, Telecoms) with some, but not overwhelming success

•Maybe today the economical pressure to achieve true interoperability is big enough to make it happen.

•Maybe it works for closed and well-regulated domains such as airlines, medical care or stock trading.



SOC-Challenges: State of the Art

• All these issues are attacked today in the context of Webservices, but there are not yet generally agreed upon standards:•Security: RSA BSAFE SecurXML, SAML, SSL, Webservice-

aware firewalls•Workflow: WSFL, BPML, WSCI•Transactions: WSTk, XLANG•Semantics: ebXML, Biztalk, RosettaNet

• Generally agreed upon and available standards that are implemented „everywhere“ are really necessary here, simply because otherwise the whole „use stuff that somebody else provides“ does not work.

• XML, HTTP and an open port 80 are not enough to make the webservice vision happen.



SOC-Challenges: The Business Model

• There is an additional question: Is there a business model for this kind of collaboration?

• Issues comes to mind about•Trust and security

•Reliability and SLA‘s

• Insourcing vs. Outsourcing

• But that‘s another talk...



C O N T E N T S

• Introduction



• Reuse Issues





• The Future

• Summary



Using traditional middleware

• Traditional middleware comes in many flavours, such as •Distributed Object Computing (CORBA, RMI)

•Remote Procedure Calls (DCOM, RPC)

•Message-Oriented Middleware (MQSeries, JMS)

• You should use it, when you need object identity and stateful implementations with a defined lifecycle (DOC)

• You should use it, when performance is an issue.

• You should use it, when no interoperability (with other technologies or companies) is required.

• You should use it when you need security, distributed transactions, etc. among the different participants (this might change as these things become defined for webservices).



Is CORBA dead?

• CORBA is used as the basis for many J2EE application servers.

• CORBA currently springs to life in the embedded world (Realtime-CORBA, FT-CORBA) for Distributed Realtime Embedded (DRE-) systems.

• CORBA is not visible anymore for enterprise developers (mostly) but that does not mean, it is dead.



.NET uses Webservices for everything?

• Also not true.

• .NET‘s remoting framework can use arbitrary transports and arbitrary data encoding.

• There are several default implementations, one of them is XML+HTTP (+WSDL).

• COM+ (which is not replaced by .NET) continues to use DCOM as it‘s remoting protocol.



Are webservices „simple“?

• Currently, using webservices is rather simple.

• This is mainly because they provide rather simple functionality, such as • retrieving weather data for a given city,

• translating a word to another language

•Retrieving stock values

•Searching the web

• ...and we dont care about security, transactions, lifecycle management on the server, etc.

• As soon as we include these technical issues, using webservices will be the same level of complexity as using CORBA or DCOM•Or, seen the other way: Using CORBA to implement these

simple applications is also trivial.



C O N T E N T S

• Introduction



• Reuse Issues





• The Future

• Summary



Webservices and EAI

• EAI denotes the integration of heterogeneous systems inside an enterprise (or within a group of enterprises).

• This integration includes•Message transport (routing, 1:1, 1:n)

•Bridging between synchronous and asynchronous communication styles (polling, RPC, message queues)

•Protocol adaptations (CORBA, DCOM, sockets, ...)

•Data transformations (technical)

•Data transformations (logical, i.e. supplying default values, transforming male to 1)

•Process coordination, workflow

•Enforcing inter-application business rules

•Security mappings

•Transaction coordination (sometimes)



EAI Reference Model

Process Layer

Comm unications Layer

Protocol Adapters

EM

ail

htt

p

sock

es

...

m essage transportprotocol adaptations

bridgingdata transform ation (technical)security m appingstransaction coordination

m essage transportdata transform ation (logical)w orkflowbusiness rules

Adapted from : W olfgang Keller: EnterpriseApplication Integration, dPunkt Verlag



Webservices and EAI

• Webservices as they are now can only help with •Message transport•Protocol adaptations (because it is not necessary anymore

if everybody provides a webservice interface)•Technical data transformations (XML+XSLT)

• When some of the webservices standards are completed, they might also help with•Process coordination, workflow•Security mappings•Transaction coordination

• However, in most EAI projects, the problem is to access stone-age legacy systems that have no XML/CORBA/whatever interface. Here, the problems remain.

• Once everybody has a webservice based interface, the world will indeed become simpler.



C O N T E N T S

• Introduction


•Are Webservices Componets?

• Reuse Issues





• The Future

• Summary



C O N T E N T S

• Introduction



• Reuse Issues





• The Future

• Summary



The Future: Components

• CBD will remain an interesting topic. It will not be replaces too soon.•Things like J2EE/EJB are not going to go away.

•Rumors say that Microsoft is working on a native .NET replacement for COM+.

• Containers and their services will become more modular •See SmallComponents, JBoss‘ generalized AOP container

• Containers will be tightly integrated with webservices.

• There might be native Webservice containers that provide component services directly as webservices.



The Future: Webservices

• Webservices will continue to evolve and „reinvent“ everything that other remoting technologies have had for ages.

• Webservices will probably become more powerful than traditional middleware (concerning their expressiveness and additional services) because the business reality requires that.

• As more and more features will be added to webservices, they will become more complex (and even slower).

• Maybe there will once be a „Webservice binary data transport format“ for more efficient (smaller!) remoting.•They could use CDR or ASN.1 as the encoding format.



The Future: Traditional Middleware

• Traditional middleware will not go away, either.

• MoMs are still (and will be) the basis of really big distributed applications.

• DOC will serve as the basis for (locally) distributed component infrastructures.

• Whenever performance and network packet size is an issues, traditional middleware will be used in the future.

• The embedded world will not start to use webservices in the near future.



C O N T E N T S

• Introduction


•Are Webservices Componets?

• Reuse Issues





• The Future

• Summary



Summary: The big picture

• The world will continue to be made of webservices, components and traditional middleware.

R ealtim e Factorycontro l system

G

ER P-System

A A'

G

Company 1 Company 2

W AN

Internet

Fir

ewal

l

Fir

ewal

l

G



In eigener Sache...

Server Component PatternsComponent Infrastructuresillustrated with EJB

Markus VölterAlexander SchmidEberhard Wolff

Wiley Pattern Series



The End.

ThanksQuestions?Comments?Criticism?

Markus Völter

[email protected]

www.voelter.de

Most current slides at www.voelter.de/oop2003

Documents

Components, Remoting Middleware and Webservices - and how it all fits together