Szolgáltatásorientált rendszerintegráció Comparison of component technologies Simon Balázs, BME IIT Outline Definitions Component technologies RPC, RMI, CORBA, COM+,.NET, Java, OSGi, EJB, SOAP web services, REST services, WebSockets, SCA Comparison of component technologies (C) Simon Balázs, BME IIT 2 Definitions SOA Service-Oriented Architecture (SOA) is paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. In SOA, services are the mechanism by which needs and capabilities are brought together. (OASIS) (C) Simon Balázs, BME IIT 3 4 BME IIT, Simon Balázs Service A service is a discoverable software component that exists as a single stateless instance and interacts with applications and other services through a loosely coupled (often asynchronous), message-based communication model. Properties of SOA Architecture style Abstracts complexity Standard protocols Standard interfaces Self-contained services Autonomy Internally and externally callable services Loosely-coupled services Reusable services Discoverability through a repository Incremental integration Dynamic integration Service composition Business process execution Quality of Service (QoS) characteristics (security, transactions, performance, etc.). (C) Simon Balázs, BME IIT 5 (C) Simon Balázs, BME IIT 6 1
SOA Manifesto priorities Business value over technical strategy Strategic goals over project-specific benefits Intrinsic interoperability over custom integration Shared services over specific-purpose implementations Flexibility over optimization Evolutionary refinement over pursuit of initial perfection Component A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties. (Szyperski) (C) Simon Balázs, BME IIT 7 8 BME IIT, Simon Balázs Relation of SOA, CBD, OOP and AOP Service-Oriented Architecture (SOA): services are software components, which operate in a distributed environment and focus on documentcentric communication Component-Based Development (CBD): the interaction between components depends on the technology that the components are based on components can provide the basis for implementing services, and components can encapsulate objects Aspect-Oriented Programming (AOP): complementary paradigm affecting the software system on several levels orthogonal to OOP, CBD and SOA (C) Simon Balázs, BME IIT 9 Relation of SOA, CBD, OOP and AOP SOA: high service reusability at the enterprise level CBD: high component reusability on a smaller scale OOP: objects are reusable within a single application The level of abstraction increases: OOP >> CBD >> SOA AOP: does not raise the level of abstraction separates different concerns (e.g. security, logging) from the domain logic Services Components Objects Aspects (C) Simon Balázs, BME IIT 10 Component technologies Implementing the SOA SOA is not a technology! SOA is a paradigm for developing distributed applications built from services SOA can be implemented using any component technology Examples: RPC, RMI, CORBA, COM+,.NET, Java, OSGi, EJB, SOAP web services, REST services, WebSockets, Spring, SCA, ESB,... (C) Simon Balázs, BME IIT 11 (C) Simon Balázs, BME IIT 12 2
Serialization Deserialization Deserialization 2/19/2016 Serialization SOA architecture Distributed communication layer architecture service repository find get interface publish interface Client application Client stub/proxy Interface Interface Server application Server stub client request-response protocol service Network Protocol 13 BME IIT, Simon Balázs (C) Simon Balázs, BME IIT 14 Remote Procedure Call (RPC) Inter-process communication Calling functions in a different address space Applications do not have to deal with the details of the network protocol An RPC call is like a normal function call for the application but it can fail if there are network problems Problems to solve: serialization, byte order memory management RPC is not a standard no standard protocol, no standard interface There are many different (incompatible) RPC protocols Usually there is no interface descriptor, no service registry Remote Method Invocation (RMI) RPC for OOP Java RMI: Java serialization direct transfer of serialized Java classes distributed garbage collection interface descriptor: Java interface protocol: RMI-IIOP service registry: Naming service.net Remoting:.NET serialization interface descriptor: C# interface protocol: TCP or SOAP over HTTP service registry: none (C) Simon Balázs, BME IIT 15 (C) Simon Balázs, BME IIT 16 Common Object Request Broker Architecture (CORBA) OMG standard for RMI Independent of: programming languages operating systems Mappings to many programming languages Very complex standard implementations don t implement the complete standard incompatibilities between early implementations Very complex programming API Interface descriptor: Interface Definition Language (IDL) Protocol: Internet Inter-ORB Protocol (IIOP) Service registry: naming service, trading service Component Object Model (COM+) Microsoft technology COM for inter-process communication DCOM distributed communication marshalling distributed garbage collection was a major competitor of CORBA COM+ (.NET Enterprise Services) transactions resource management security Interface descriptor: Microsoft Interface Definition Language (MIDL) Protocol: proprietary COM+ RPC Service registry: Windows Registry (C) Simon Balázs, BME IIT 17 (C) Simon Balázs, BME IIT 18 3
.NET Framework Runtime for.net applications Component:.NET assembly (DLL) Service: class Versioning support: no DLL hell Code access security Interface descriptor: assembly descriptor Protocol: in-memory calls Service registry:.net runtime Java Virtual Machine (JVM) Runtime for Java applications Component: JAR file Service: Java class No standard versioning support: JAR hell possible solutions: Maven, OSGi Code access security Interface descriptor: none Protocol: in-memory calls Service registry: JVM (C) Simon Balázs, BME IIT 19 (C) Simon Balázs, BME IIT 20 OSGi Standardized by the OSGi Alliance Dynamic module system for Java Components are bundles they can be loaded and unloaded dynamically Communication: only local calls within the JVM Semantic versioning Service interface descriptor: Java interface Bundle interface descriptor: Bundle manifest Protocol: in-memory calls Service registry: OSGi runtime SOAP web services XML-based RPC Platform and language independent Advanced QoS: security, transactions, reliability But: very slow compared to binary protocols Convenient language API Interface descriptor: WSDL Protocol: SOAP Service registry: UDDI (C) Simon Balázs, BME IIT 21 (C) Simon Balázs, BME IIT 22 REST services HTTP extension: GET, POST, PUT, DELETE Can be used for RPC: JSON/XML over HTTP (always with POST) Faster than SOAP No QoS: security, transactions, reliability Convenient language API Can be easily tested from browsers Interface descriptor: none/wadl/wsdl 2.0 Protocol: application specific over HTTP Service registry: none WebSockets HTTP upgrade to TCP After upgrade: only plain TCP application protocol over TCP is a custom protocol the custom protocol can be a standard protocol, e.g. SOAP Fast response times Convenient language API Server can notify clients unlike in the traditional web model But: WebSockets are not scalable and can overload the server Interface descriptor: none Protocol: application specific over TCP Service registry: none (C) Simon Balázs, BME IIT 23 (C) Simon Balázs, BME IIT 24 4
Enterprise Java Beans (EJB) Server side components Remote and local invocations Stateless EJBs are scalable Stateful EJBs are not scalable Advanced QoS: security, transactions Interface descriptor: Java interface Protocol: RMI or in-memory Service registry: JNDI Service Component Architecture (SCA) OASIS standard Programming model for building applications and systems based on SOA Component and assembly model Creation and composition of services SCA is not a communication technology: SCA wraps other communication technologies SCA components can communicate using any technology (via SCA bindings) Interface descriptor: WSDL or Java or other nonstandard Protocol: any protocol specified by SCA bindings Service registry: the SCA runtime environment (C) Simon Balázs, BME IIT 25 (C) Simon Balázs, BME IIT 26 Enterprise Service Bus (ESB) Not a standard Realization and enforcement of SOA principles Protocol and data format conversion Message transformation and routing Advanced QoS: security, reliability, transactions Service virtualization Interface descriptor: WSDL or Java or other nonstandard Protocol: any protocol supported by the vendor (HTTP, JMS, FTP, SMTP, etc.) Service registry: usually a separate component or part of the ESB runtime Comparison of component technologies (C) Simon Balázs, BME IIT 27 (C) Simon Balázs, BME IIT 28 Comparison aspects Component Service Service interface descriptor Protocol Service registry Versioning Response time Scalability Programming language Simplicity of the API QoS (security, transactions, reliability) Comparison I. RPC Java RMI.NET remoting Component application JAR DLL Service function Java class.net class Interface descr. none Java interface.net interface Protocol custom RMI-IIOP TCP or SOAP Service registry none Naming service none Versioning none none none Response time fast fast fast Scalability none none none Prog. language specific Java any.net language QoS none none none (C) Simon Balázs, BME IIT 29 (C) Simon Balázs, BME IIT 30 5
Comparison II. CORBA COM+ (.NET Enterprise Services) Component application COM+ component Service CORBA service COM+ component Interface descr. IDL MIDL Protocol IIOP COM+ RPC Service registry naming/trading service Windows Registry Versioning none yes (GUID) Response time fast fast Scalability yes yes Prog. language any any on Windows API complex simple QoS yes yes Comparison III..NET runtime JVM OSGi Component assembly JAR file bundle Service.NET class Java class OSGi service (Java class) Interface descr. assembly descriptor none Java interface Protocol in-memory call in-memory call in-memory call Service registry.net runtime JVM OSGi runtime Versioning yes none semantic Response time fast fast fast Scalability none none none Prog. language any.net language Java Java QoS yes yes yes (C) Simon Balázs, BME IIT 31 (C) Simon Balázs, BME IIT 32 Comparison IV. SOAP REST WebSocket Component application application application Service SOAP service REST service WebSocket service Interface descr. WSDL none/wadl/ WSDL 2.0 none Protocol SOAP HTTP TCP Service registry UDDI none none Versioning none none none Response time slow slow, but can be faster than SOAP fast Scalability yes yes none Prog. language any any any QoS yes none none (C) Simon Balázs, BME IIT 33 Comparison V. EJB SCA ESB Component application SCA component application Service EJB class SCA service any Interface descr. Java interface WSDL / Java interface Protocol in-memory / RMI any any Service registry JNDI SCA runtime ESB runtime Versioning none none yes Response time fast depends on the protocol any depends on the protocol Scalability yes yes yes Prog. language Java any configuration QoS yes yes yes (C) Simon Balázs, BME IIT 34 6