A Reference Architecture For Service Oriented Architecture .
A Reference Architecture forService Oriented Architecture (SOA) Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu1
MotivationWhy do we need SOA RedundancyImplementation inconsistencyLack of inter-operability“Wrapper”-HappyLack of ModularityMisconception: SOA is about designand not technology (i.e., WebServices) Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu2
What is SOA? ---- Randy Heffner,Forrester Research"A pattern of design, development, deployment, and management of (a)applications and (b) software infrastructure and frameworks in which:Applications are organized into business units of work (services) that are(typically) network accessibleService interface definitions are first-class development artifactsQuality of service (QoS) characteristics (security, transactions, performance, etc.)are explicitly identified at design timeSoftware infrastructure takes active responsibility for managing QoS andenforcing policy for service access and executionServices and their metadata are cataloged in a repositoryProtocols and structures within the architecture are, optionally, based onindustry standards (e.g., the emerging SOAP stack of standards)”http://orchestrationpatterns.com/?q node/13 Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu3
What is SOA? ---- More definitionsThe orchestration patterns website outlines 12 additional definitions of SOAfrom industry experts The diversity in definitions is interesting “Service Oriented Architecture (SOA) is an approach to the development of loosely coupled,protocol-independent distributed applications ”“SOA is a form of technology architecture that adheres to the principles of serviceorientation “"Service-oriented architecture is an architectural discipline ”“SOA is a style of design that strives to enable easy integration and flexible applications “"A service oriented architecture is an approach to design and integrate software in a modularmethod where each module is precisely a 'loosely coupled service' ,,,”“Service Oriented Architecture is nothing but business oriented architecture ”“SOA is a framework enabling application functionality to be provided, discovered andconsumed as re-usable Web Services sets ”And so on Source: http://orchestrationpatterns.com/?q node/13 Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu4
What is SOA? ---- More definitionsThe orchestration patterns website It’soutlines12 additionalof SOAa bit confusing is definitionsSOAfrom industry experts The diversityin definitions is interesting about: “Service Oriented Architecture (SOA) is an approach to the development of loosely coupled,protocol-independent distributed applications ”1. Web Services“SOA is a form of technology architecture that adheres to the principles of service2. Businessorientation “Architecture"Service-oriented architecture is an architectural discipline ”“SOA is a style of design that strives to enableeasy integration and flexible applications “3. Services"A service oriented architecture is an approach to design and integrate software in a modular“LooseCoupling”method where each module is precisely a 4.'looselycoupledservice' ,,,”“Service Oriented Architecture is nothing butbusiness oriented architecture ”5. Integration“SOA is a framework enabling application functionality to be provided, discovered and6. All of the above?consumed as re-usable Web Services sets ”And so on 7. Or something else Source: http://orchestrationpatterns.com/?q node/13 Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu5
Microsoft and SOA A Microsoft View on SOA: “The goal for Service Oriented Architecture(SOA) is a world-wide mesh of collaborating services that are publishedand available for invocation on a Service Bus. Adopting SOA is essentialto delivering the business agility and IT flexibility promised by WebServices ”Microsoft uses a Metropolisanalogy to explain SOA The idea being that cities,like an SOA, require services(police, manufacturing,shopping, etc.) and atransportation (bus, railroad,etc.) system to thriveSource: .aspx Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu6
IBM & SOA .IBM’s Website on SOA(linked here fromdeveloperworks.com)is clearly targeted atselling IBM tools andprofessional services Source: ces/ Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu7
SOAYou may either feel educated or sleepy by now, butyou probably know little more than when youarrived at this class about SOA Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu8
SOA Buzz you however will be well equipped to play“buzzword bingo” at the meeting where somebodytries to explain SOA Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu9
Service Oriented Architecture is anExample of an Architectural StyleAn Architectural Style defines a family ofsystems in terms of a pattern of structuralorganization. What are the architectural components?What are the architectural connectors?What patterns guide the design of the components andconnectors?How are faults and unexpected events handled?Clear definition of the set of constraints on thearchitectural components and the relationships that areallowed between themBecause SOA is an Architectural Style a Reference Architecture can beconstructed to govern common aspects of all applications built in accordancewith this style Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu10
Service Oriented Architecture is anExample of an Architectural StyleSOA as an Architectural Style: What are the architectural components? Services What are the architectural connectors? Messages What patterns govern the design of the components and connectors? Data Services, Business Services, Composite Services How are faults and unexpected events handled? Language specific exception handling mapped to service faults Clear definition of the set of constraints on the architectural components and therelationships that are allowed between them Services are network addressable Services are language and platform independent Services have flexible instantiation capabilities Services are stateless Messages are formally defined by a service contract Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu11
The “Actors” in an SOA – ServiceConsumers, Service Providers & MessagesService ProviderConcreteServiceService ceConsumedServiceInterfaceProvidedServiceInterface Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu12
The Architectural Components ServicesServices are a conceptual design component, and can be implementedusing a variety of different technologies Java Beans, (Enterprise Java Beans).Net Class Files (ASMX)COBOL ProgramsThird party tools: SiebelServices are designed to have flexible interfaces and are evolved easily Services separate the concerns of the service consumer from the service providerServices can be instantiated in a variety of different ways Local components, Web Services, Sync-/Asynchronous MessagesServices are lifecycle managed by an application server container of somesort CICS, .Net Framework, J2EE (WebSphere, Axis) Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu13
The Architectural Connectors MessagesServices interoperate with each other using “messages” capable ofverifying and certifying their own syntax and semanticsArchitecture Requirements for Messages Messages do not assume any sort of delivery technologyMessages support intermediaries and can be transformed between theservice consumer and the service provider without either party beingaware of the transformation processMessages can be secured end-to-endMessages can be deserialized into language-specific componentsLanguage specific components can serialize themselves into a validmessage that adheres to both the syntactic and semantic requirementsof the message Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu14
Messages and XMLIn a SOA, messages are generally encoded as XML documents Character-based encoding is the lowest-common denominator for almostevery computing and message-transport platformResearch into XML parsing has produced parsers that can produce anddigest XML documents very fastThe valid structure of messages encoded as XML can be specified usinga standard description language – XML SchemaXML Namespaces support the flexible extension of service interfacesXML is governed by a wide verity of standards Security Transformation Industry-specific business transactions Vendor-specific schemas Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu15
Benefits of the SOA ArchitecturalStyleIts all about the interface Loosen the coupling between a service component and therequesting application Support easy and rapid evolution of the service interface with amaximum degree of backward-compatibility Interface specifies the semantics used by the service provider Loosen the coupling between an application and the database Allows current data sources to be aggregated behind a serviceinterface Allows the underlying data sources to evolve as authoritative datasources are created Messages define the types used by the interfaces of the serviceconsumer and the service provider Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu16
Best Practices for Service Design inan SOAServices for an SOA should be built using the “Design by Contract”approach Service contract developed first using a standard description language, typicallyXML Schema The service contract defines the service interface, encodes the message structure, anddefines the message semantics Services interfaces define the interface types, as such service programmersshould not be working at the XML level Objects should be generated for the service interface from the service contract (i.e.,XSDObjectGen for .Net, JAXB for Java) Service contracts should be designed for extension, and organized aroundbusiness events that the service supportsService contracts define “subject areas” that support the various business eventssupported by the serviceService contract can be used by a service invocation framework Examples: WSDL for Web Services Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu17
Best Practices for Interface andMessage Design in SOAService interfaces should be build around the specification and execution ofuseful application/business eventsThe service interface should define a collection of “subject areas” that arerelevant to the application/business events supported by the service ServiceRequestMessage MessageHeader !-- Miscellaneous Header stuff goes here -- BusinessEvent !– Enumeration of supported business events goes here -- /BusinessEvent /MessageHeader MessageBody SubjectArea1 . /SubjectArea1 SubjectArea2 . /SubjectArea2 SubjectAreaN . /SubjectAreaN /MessageBody /ServiceRequestMessage The application/business event coupled with the provided subject areas dictates what a service willdo on behalf of the consumer, this model fits in naturally to business processes where the “currentview of the truth” might be dependant on the state of the business process. Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu18
Some Misconceptions about ServicesServices are not Database API’s Use stored procedures for “black box” operations on dataA service can be implemented as a Web Service, but aWeb Service is not necessarily a service in an SOAReuse of a service is nice if you can find a requirementfor it A service is best thought of as an authoritative access point toexecute application/business events around a particular businesssubject areaA service is a great place to get a business context aware “viewof the truth” Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu19
We will see later that services come indifferent stylesService Styles Basic ServicesIntegration ServicesComposite Services Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu20
Anti-Best Practice for CreatingServices: The “Right-Click” method Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu21
.Net is no better for directly promotinga component to a service Decorate a component interface with “[WebMethod]”Create a file with an “.axmx” extension with a single line: %@ WebService Class "ClassName Goes Here" % Any method in the components class that is public anddecorated with “[WebMethod]” becomes part of theservice interface Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu22
Design Service Like Mini-ApplicationsRequestTierService Business EventChange ionLocalObjectsDomain ObjectTierThe domain layer is bound to the dataaccess layer by action objects thatmanage business event transactionsDomainObjectBuilderServices should usetype-safe objects thatserialize/deserializeto XML in accordancewith the servicecontractBusiness EventAction FactoryThe domain tierData accessrepresents theActions objects arebusiness domain(Events) aware of howand is unawareto persistof how the businessdomainobjects are persisted.objects in aBusiness logic goesdatabase.here. Drexel University Software Engineering Research Group sactionsOther (Messaging)23
OutlineObjects and ComponentsService Oriented Reference Architecture SOASOASOASOAESBFunctional ViewArchitectural ViewMessagingInterfaces (provided & required) Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu24
Objects and Components (again)Services are the main entities in applicationsconstructed using SOA principlesServices are constructed using components,which in turn, are created using objects Reviewing principles of objects and components ishelpful in understanding how to design servicesServices can then be placed in context of areference architecture for SOA Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu25
Principles of OOAbstraction An object is known by its data type and behavior, providinga stable interface for communicating with and using theobject.Encapsulation Implementation decisions are hidden inside of classes andwere protected by variables (properties) and methods thatwere explicitly made public to the outsideAllows for the separation of interface from implementationPolymorphism The ability for an class to take on different behavior-basedon the runtime binding to object types Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu26
Principles of OOInheritance The ability of one object to inherit therepresentation and behavior from another object.This inherited behavior and representation can beselectively used “as is”, extended, or replaced.Identity A class is a template for objects and objects areinstances of classesAll objects can be uniquely defined, have theirown unique identity, and manage their uniquestate Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu27
Design Principles for OOProgram to interface not implementationTo extend behavior, favor object compositionover inheritance – extended behavior andoriginal behavior are preserved This prevents a change to the original behaviorfrom impacting inherited behaviorMinimize coupling between objects to ensurethat changes are localized and do notpropagateMaximize cohesion within an object Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu28
Design Principles for OOGood interface design is essential It does not expose the underlying attributes (classlevel) or the underlying classes(subsystem/component level)Does not expose the underlying implementationDoes a logical unit of workA change to the system should not require achange to the interface (property of goodabstraction) Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu29
Problems with OOThe design principles of OO scale to design principlesfor services in an SOAOO has scalability and complexity limitations Classes have to have compile or link time visibility to allother classes – this implies repackaging/deploying an entireapplication unit when a class changesDistribution was handled manually using low level networkprotocolsInterface design had to be “perfect”, but this was difficult todo in practiceAll types must be binary compatibleType conversion and object serialization/deserialization wasa manual process Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu30
ComponentsComponents aggregate classes and focus onpackaging and distribution OO design principles directly map to component designprinciplesYet component approaches to software design havetheir problems: Components must still provide a stable interfaceComponents are only able to provide a single interface totheir clientsDesigns using components are “chatty”, often requiringmany components to perform a “useful” operation – thismakes scalability difficultComponent frameworks are proprietary COM, DCOM, CORBA, J2EE/EJB Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu31
Step 1: Containers to the rescue Containers (a.k.a application servers) are likeapplication-aware operating systems that sit on topof the native operating system (e.g., Microsoft.Net,J2EE) Standardizes resource allocation and sharing that is tightlyintegrated into component modelAble to introduce component-aware semantics E.g., Secuirty attributes based on RBAC - beyond read, write,read-write, allow, denyContainers abstract many of the “hard” things: Finding things (directories), managing network resources,reliability, availability, database connections, security, “ondemand”-stuffCode running in a container is often called “managedcode” Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu32
Step 2: Messaging infrastructure to therescue Traditional distributed inter-operability isgenerally achieved by sending a binary-encodedmessage over a synchronous network connection(e.g., socket)This approach makes it hard to: Provide multiple interfaces for a componentSupport asynchronous programming modelsSupport common architecture styles (e.g., Pub-Sub)Support severs implemented in a different technologyfrom the requestorSupport applications with high-reliability requirementsSupport external routing information Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu33
Step 2: Messaging infrastructure to therescue Messaging infrastructures are traditionallyimplemented as queues where messages,metadata and routing information are placedinto a queue and the messaginginfrastructure routes the message to from asource queue to a destination queueQueues may have properties such as triggersso that when a message of a certain typearrives it automatically invokes a componentto process the message Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu34
Step 2: Messaging infrastructure to therescue Messaging infrastructures also have theirproblems: The format for the encoded message is left to theuser – meaning the requestor and server mustagree on the formatThe asynchronous programming model is moredifficult for programmers to deal with than asynchronous programming modelDeployment of applications using messaginginfrastructure is fragmented Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu35
Step 3: Standards to the rescue – finallyenablement of SOA is possibleSOA takes the best from OO, Components,Containers, and messaging infrastructures OO and Components provide the design principlesContainers and messaging infrastructures provide theruntime environmentNow standards such as the WS-* set enablecontainers to support distributed components that: Can interoperate using messaging or synchronous messagesseamlesslyStandardize the format and define semantics for themessaging payloadsSupports external definition of routing and QoS of related tothe delivery of messages Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu36
SOA RevisitedSOA Represents every application or resources as aservice with a standardized interfaceIs based on having services exchange structuredinformation (as opposed to an RPC call)Provides facilities via a container to coordinate andmediate between the services so that they can beinvoked, used and changed effectively Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu37
Service revisitedA service is : A component that does something useful on behalf of anapplicationExposes its functionality and hides the implementationdetailsNot dependant on the context or state of other servicesA service either provides information or facilitates theprocessing of an application feature ensuring that theapplication state is changed from one valid andconsistent state to anotherDependencies between services should be defined interms of an application process Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu38
An SOA Reference Architecture Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu39
SOA Reference Model 101Message TypeDelivery MethodDelivery ChannelTransport ProtocolPayload FormatEncoding viceInterface Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu40
eMessagingModelsServiceInterfaceQuality ofService (QoS)CharacteristicsService Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.eduService Integration AdaptersApplication Specific ComponentsComponents of the SOA ReferenceArchitectureIntegration41
Establishing the Functional Aspect of theService in an SOAEvent-Driven ServiceServices that react, publish or implement enterprisebusiness events.Long lived business processes coordinating otherservices with external interactions.Core ServicesServiceServiceSecurityPoliciesManager Drexel University Software Engineering Research Group vices providing data querying, combination andtransformation for multiple data sources.OtherServicesData ServiceService t services composed of combinations ofcomponent services and rules.Business Process ServiceHTTP/HTTPSTransportBusiness Service3rd PartyApplicationsSimple services potentially acting on single enterpriseresource (e.g., database, code, etc) and are createdby aggregating and/or encapsulating one or moreapplication-specific component interface(s)LegacyRPCTCP/IPComponent ServiceFilesService pService ConsumersService Provider(or Service Requestor42
The Enterprise Architecture Reference Model for SOAContainersWebSphere entMethodologyServicesApplicationFunctional ServicesPolicy EnforcementMessaging / Transactions / EAIReportingApplicationsService RepositoryMessaging / Transactions / EAIWorkflow Service(Business Process,Business Transaction)WorkflowCoordination Service(ACID Transaction)RulesCoordinationCaching Controller Service(Simple BusinessProcess Composition) Transformation Wrapper ServiceRoutingQuality of Service Data plicationApplicationXML ProcessingStorageReporting / Information ManagementLegend:Proxy Service Integration ApplicationFrameworkComponents Design &ArchitecturalPatternsESB InfrastructureMessagingBusiness ProcessMetadataCompositionUtilityServiceSOA DesignSOAPatternsMessaging / Transactions / EAIApplicationComponentsPurchasedApplicationsBasic ServiceVia DataServiceCore InfrastructureInter-, Intra-, andExtranet GatewaysQoS - Clustering/Load tionalReporting3rd PartyIntegrationService Architectural StylesSecurityMessaging / Transactions / EAIAnalyticalReportingODSBORWarehouseData MartETLApplication SoftwareEnterprise Drexel UniversityEngineering ResearchCorporate Group (SERG)InfrastructureDataDomainArchitecture rface43
Messaging TaxonomySOA Transport Models for Messages Supported by the Reference Architecture TCP/IP XML¾HTTP/HTTPS Binary¾RMI SOAP¾IIOP XML-RPC¾.NetRemote¾MQ atProtocol CORBA RPCpayloadcontainsattributesthat directlybind toserviceparameters Attachments MessageMetadata(Security,Session,Context, etc.)¾The Custom/ProprietaryDocumentCentricpayloadis encodedas astructureddocument MessageSchema Marshallingand DatatypeSpecifications¾TheSerializedObject ensions Synchronous Asynchronous Delivery QoS¾AtLeast Once¾AtMost Once¾Exactly Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.eduOnce One-Way¾Command¾Event Request/Reply¾Point-to-Point¾One-to-Many Publish/Subscribe44
Service SpecificationStep 1:Select ServiceTypeEach designedservice shouldbe classified byits service typeStep 2:Select ServiceStyleOnce a servicetype is defined,a service styleshould beselected basedon the desiredarchitecturalcharacteristicsof the service,its requiredresources, andpotentialconsumersStep 3:Specify ServiceInterfaceEach serviceshould providea welldesignedinterfaceencapsulatingthe desiredservicebehaviorStep 4:DefineSupportedMessagingModelsA service may beintegrated intomultipleapplicationsunder differentcontexts,therefore, theservice designshould alsoconsider themessagingmodels that willbe supported bythe service Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.eduStep 5:Define Quality ofService (QoS)CharacteristicsA service shouldalso specify itsrequired andprovided QoSattributes suchas security,transactions,performance,etc.45
The Service Styles are RelatedBasic ServicesBasicService[is a special type of]UtilityServiceIntegration ServicesProxyService[is a specialization of]WrapperService Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.eduComposite ServicesControllerService[adds externalizedworkflowcapabilities to]WorkflowService[adds ACIDtransactionsupport to]CoordinationService46
ESBWhere a container layered over the OSto facilitate the managed code model,an ESB lives within a container toprovide function to services in an SOAAn ESB Facilitates effective service communicationFacilitates effective service integrationFacilitates effective service interaction Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu47
ESB InterfacesESB InterfaceDescriptionConnectionThe ESB connection interface should fully support the synchronous and asynchronous webservice stacks as well as message-oriented middleware (MQ Series), HTTP/HTTPS, Microsoft.NET Serviced Components, Java Remote Method Invocation (RMI), .NET Remoting, CICS hosttransactions.ChangeRather than changing code in a service interface, the ESB is configured with metadata to handlemanaging the service catalog, interface versioning, routing, quality of service (QoS),orchestration, security, business rules, and other volatile duties.ControlThe control interface provides enterprise management capabilities that are outside the scope ofthe individual services managed by the ESB. The control interface integrates with standardinfrastructure management facilities, handles service provisioning to maintain QoS commitments,and provides reports/logs on the health and operation of the ESB infrastructure. Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu48
ESB FeaturesESB FeaturesESB FeaturesCommunicationSecurityThe ESB supports security policies regardingservice usageQuality of ServiceThe ESB can persist requests to message queuesand retry service operations when failures occur,implement failover to alternate servers, and othersteps to ensure that otherwise unreliablenetworks and services can be made to providethe quality of service required by the requester.Service Registry andMetadataManagementWhen maintaining a name space (servicediscovery), the ESB may extend the servicemetadata this requires (such as WSDL), toenable services to be classified to ease searchingfor reuse.Extensibility forMessageEnrichmentA special case of semantic mapping, enrichmentenables database or table lookups to be mergedinto a message stream so that messages emergefrom the bus richer with data than when theyarrived.Monitoring andManagementThe ESB au
"A service oriented architecture is an approach to design and integrate software in a modular method where each module is precisely a 'loosely coupled service' ,,,” “Service Oriented Architecture is nothing but business oriented architecture ” “SOA is a framework enabling
Bruksanvisning för bilstereo . Bruksanvisning for bilstereo . Instrukcja obsługi samochodowego odtwarzacza stereo . Operating Instructions for Car Stereo . 610-104 . SV . Bruksanvisning i original
service i Norge och Finland drivs inom ramen för ett enskilt företag (NRK. 1 och Yleisradio), fin ns det i Sverige tre: Ett för tv (Sveriges Television , SVT ), ett för radio (Sveriges Radio , SR ) och ett för utbildnings program (Sveriges Utbildningsradio, UR, vilket till följd av sin begränsade storlek inte återfinns bland de 25 största
10 tips och tricks för att lyckas med ert sap-projekt 20 SAPSANYTT 2/2015 De flesta projektledare känner säkert till Cobb’s paradox. Martin Cobb verkade som CIO för sekretariatet för Treasury Board of Canada 1995 då han ställde frågan
Hotell För hotell anges de tre klasserna A/B, C och D. Det betyder att den "normala" standarden C är acceptabel men att motiven för en högre standard är starka. Ljudklass C motsvarar de tidigare normkraven för hotell, ljudklass A/B motsvarar kraven för moderna hotell med hög standard och ljudklass D kan användas vid
LÄS NOGGRANT FÖLJANDE VILLKOR FÖR APPLE DEVELOPER PROGRAM LICENCE . Apple Developer Program License Agreement Syfte Du vill använda Apple-mjukvara (enligt definitionen nedan) för att utveckla en eller flera Applikationer (enligt definitionen nedan) för Apple-märkta produkter. . Applikationer som utvecklas för iOS-produkter, Apple .
och krav. Maskinerna skriver ut upp till fyra tum breda etiketter med direkt termoteknik och termotransferteknik och är lämpliga för en lång rad användningsområden på vertikala marknader. TD-seriens professionella etikettskrivare för . skrivbordet. Brothers nya avancerade 4-tums etikettskrivare för skrivbordet är effektiva och enkla att
Den kanadensiska språkvetaren Jim Cummins har visat i sin forskning från år 1979 att det kan ta 1 till 3 år för att lära sig ett vardagsspråk och mellan 5 till 7 år för att behärska ett akademiskt språk.4 Han införde två begrepp för att beskriva elevernas språkliga kompetens: BI
**Godkänd av MAN för upp till 120 000 km och Mercedes Benz, Volvo och Renault för upp till 100 000 km i enlighet med deras specifikationer. Faktiskt oljebyte beror på motortyp, körförhållanden, servicehistorik, OBD och bränslekvalitet. Se alltid tillverkarens instruktionsbok. Art.Nr. 159CAC Art.Nr. 159CAA Art.Nr. 159CAB Art.Nr. 217B1B
