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

1. Components, Remoting Middleware and Webservices- and how it all fits together Markus Völtervoelter@acm.orgwww.voelter.de

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

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

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

5. 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 • Summary

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

7. Components: A Taxonomy

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

9. 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?

10. ... 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 anexample...

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

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

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

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

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

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

17. 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!

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

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

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

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

22. Reuse for Webservices and Components • (Web-)services (and their implementations) are used as is on the service provides machine. • This is why we do not needto take care of deployment/configuration/ additional services • 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

23. Reuse for Webservices and Components • (Web-)services (and their implementations) are used as is on the service provides machine. • Components (and their implementations) are bought from a 3rd party and installed on my own container or infrastructure. Component-based Development(CBD) Service-oriented computing(SOC)

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

25. How it fits together

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

27. C O N T E N T S • 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

28. 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,

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

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

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

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

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

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

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

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

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

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

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

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

41. EAI Reference Model

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

43. C O N T E N T S • 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

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

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

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

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

48. C O N T E N T S • 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

49. Summary: The big picture • The world will continue to be made of webservices, components and traditional middleware.

50. In eigener Sache... Server Component Patterns Component Infrastructures illustrated with EJB Markus Völter Alexander Schmid Eberhard Wolff Wiley Pattern Series