Transcript Kein Folientitel

Components, Remoting Middleware and Webservices
Components, Remoting
Middleware and Webservices
- and how it all fits together
Markus Völter
[email protected]
www.voelter.de
ingenieurbüro für softwaretechnologie .
www.voelter.de
-1-
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
CONTENTS
• 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
ingenieurbüro für softwaretechnologie .
www.voelter.de
-2-
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
CONTENTS
• 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
ingenieurbüro für softwaretechnologie .
www.voelter.de
-3-
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
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.
ingenieurbüro für softwaretechnologie .
www.voelter.de
-4-
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
CONTENTS
• 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
• Summary
ingenieurbüro für softwaretechnologie .
www.voelter.de
-5-
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
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
ingenieurbüro für softwaretechnologie .
www.voelter.de
-6-
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
Components: A Taxonomy
ingenieurbüro für softwaretechnologie .
www.voelter.de
-7-
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
CONTENTS
• 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
ingenieurbüro für softwaretechnologie .
www.voelter.de
-8-
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
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?
ingenieurbüro für softwaretechnologie .
www.voelter.de
-9-
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
... 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 semantic
information (except for types).
• Pre/Postconditions could be an
example...
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 10 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
... 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.
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 11 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
... 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, ...)
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 12 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
... 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.
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 13 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
... 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.
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 14 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
... 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.
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 15 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
CONTENTS
• 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
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 16 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
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!
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 17 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
Comparing Webservices and CORBA
• Let‘s briefly compare some webservices features to
CORBA (as an example of a remoting middleware)
features:
Webservices
CORBA
Webservice
Stateless-Objekt
WSDL
IDL + Interface Repository
SOAP + HTTP
IIOP
UDDI
Naming, Trader
• 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.
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 18 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
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.
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 19 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
CONTENTS
• 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
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 20 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
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)
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 21 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
Reuse for Webservices and Components
•
Components (and their
•
implementations) are
bought from a 3rd party
and installed on my own
container or infrastructure.
(Web-)services (and their
implementations) are used as
is on the service provides
machine.
A's provider
A
Client
Container
A
B's provider
B
network
B
Client
C
D
D's provider
C's provider
D
•
This is why we need to
take care of
deployment/configuration/
additional services
ingenieurbüro für softwaretechnologie .
•
C
This is why we do not need
to take care of
deployment/configuration/
additional services
www.voelter.de
- 22 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
Reuse for Webservices and Components
•
Components (and their
•
implementations) are
bought from a 3rd party
and installed on my own
container or infrastructure.
(Web-)services (and their
implementations) are used as
is on the service provides
machine.
A's provider
A
Client
Container
A
B's provider
B
network
B
Client
C
D
D's provider
C's provider
D
Component-based
Development
(CBD)
ingenieurbüro für softwaretechnologie .
C
Service-oriented
computing
(SOC)
www.voelter.de
- 23 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
CONTENTS
• 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
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 24 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
How it fits together
A's provider
A
Client
B's Cont.
network
B1
B2
B3
B4
network
C's provider
C
D's Cont.
D1
ingenieurbüro für softwaretechnologie .
www.voelter.de
D2
- 25 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
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.
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 26 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
CONTENTS
• Introduction
• Components
• Server-Side Component Infrastructures
• Are Webservices Components?
• Reuse
• Using Components and Webservices
• Challenges for Service Oriented Computing
• Traditional Middleware & Webservices
• Webservices and EAI
• Summary
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 27 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
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,
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 28 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
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.
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 29 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
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 (preand postconditions).
• Discovery, Mobility, Failover, QoS, selfreconfiguration, ... (see P2P systems )
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 30 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
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.
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 31 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
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, Webserviceaware 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.
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 32 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
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...
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 33 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
CONTENTS
• 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
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 34 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
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).
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 35 -
© 2002 Markus Völter
Components, Remoting Middleware and 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.
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 36 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
.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.
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 37 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
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.
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 38 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
CONTENTS
• 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
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 39 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
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)
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 40 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
EAI Reference Model
message transport
data transformation (logical)
workflow
business rules
Process Layer
bridging
data transformation (technical)
security mappings
transaction coordination
Communications Layer
message transport
protocol adaptations
...
sockes
http
EMail
Protocol Adapters
Adapted from: Wolfgang Keller: Enterprise
Application Integration, dPunkt Verlag
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 41 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
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.
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 42 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
CONTENTS
• Introduction
• Components
• Server-Side Component Infrastructures
• Are Webservices Componets?
• Reuse Issues
• Using Components and Webservices
• Challenges for Service Oriented Computing
• Traditional Middleware & Webservices
• Webservices and EAI
• The Future
• Summary
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 43 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
CONTENTS
• 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
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 44 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
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.
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 45 -
© 2002 Markus Völter
Components, Remoting Middleware and 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.
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 46 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
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.
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 47 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
CONTENTS
• Introduction
• Components
• Server-Side Component Infrastructures
• Are Webservices Componets?
• Reuse Issues
• Using Components and Webservices
• Challenges for Service Oriented Computing
• Traditional Middleware & Webservices
• Webservices and EAI
• The Future
• Summary
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 48 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
Summary: The big picture
• The world will continue to be made of webservices,
components and traditional middleware.
Company 1
Company 2
ERP-System
A
A'
WAN
Internet
Firewall
G
Firewall
G
G
Realtime Factory
control system
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 49 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
In eigener Sache...
Server
Component
Patterns
Component Infrastructures
illustrated with EJB
Markus Völter
Alexander Schmid
Eberhard Wolff
Wiley Pattern Series
ingenieurbüro für softwaretechnologie .
www.voelter.de
- 50 -
© 2002 Markus Völter
Components, Remoting Middleware and Webservices
The End.
Thanks
Questions?
Comments?
Criticism?
 Most current slides at
Markus Völter
www.voelter.de/oop2003
ingenieurbüro für softwaretechnologie .
[email protected]
www.voelter.de
www.voelter.de
- 51 -
© 2002 Markus Völter