SOA Suite 11g Deep Dive
•Als PPTX, PDF herunterladen•
0 gefällt mir•1,643 views
SOA hat sich inzwischen als Architekturstil durchgesetzt und ist in vielen Unternehmen etabliert. Mit Einführung der Fusion Middleware 11g hat Oracle die SOA Suite erheblich verändert und stellt damit ein mächtiges Werkzeug für die Entwicklung und den Betrieb von Services, auf Basis der Service Component Architecture (SCA), zur Verfügung. Services können sehr einfach, schnell und vor allem deklarativ mit der SOA Suite entwickelt und betrieben werden. Die SOA Suite stellt damit eine gute und ausgereifte Plattform für den Betrieb von Services zur Verfügung. Bei der Präsentation handelt es sich um einen Auszug aus dem DOAG Expertenseminar vom 14. und 15. Oktober 2013 in Berlin.
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie SOA Suite 11g Deep Dive
Ähnlich wie SOA Suite 11g Deep Dive (20)
SOA Suite 11g Deep Dive
- 1. SOA Suite 11g Deep Dive > Best Practices für Entwickler und Administratoren 1
- 3. WebLogic Komponenten WebLogic Domain Maschine 1 Node Manager Maschine 2 Node Manager Maschine 3 Node Manager AdminServer Cluster ACE Managed Server A Managed Server C Managed Server E Cluster BD Managed Server B Managed Server D 3
- 4. WebLogic Domain Configuration startup AdminServer Managed Server A Managed Server B 4
- 5. FMW-Erweiterungen… • Oracle-spezifische Libraries • JRF… • ADF… • … • $DOMAIN_HOME/config/fmwconfig/*.* • Enterprise Manager • MDS • Diagnostic Monitoring Service (DMS) • Oracle Platform Security Service (OPSS) 5
- 6. Fusion Middleware Sicherheitsarchitektur Oracle Platform Security Service (OPSS) 6
- 7. > SCA und SOA Suite 7
- 8. Was ist ein Composite? 8
- 9. Oracle SOA Suite 11g Web based customization Rich End User Interaction BPM Workspace BPMN 2.0 / BPEL SOA Composite Editor Process Portal (WebCenter) MS Office Process Composer (Business & IT views) BPEL BPMN Process Core B2B Human Workflow Business Rules Mediator Service Infrastruktur Process Analytics BAM Proc Cubes Common JCA-based connectivity infrastructure Optimized binding MDS Policy Manager WebLogic Server EM console +BPMN Screens 9
- 10. URLs • SOA Suite Services http://servername:port/soa-infra • Fabric Provider Servlet http://servername:port/soa-infra/services/* • CompositeDeployerServlet http://servername:port/soa-infra/deployer • EdnDbLogServlet http://servername:port/soa-infra/events/edn-db-backlog http://servername:port/soa-infra/events/edn-db-log • ClusterInfoServlet http://servername:port/soa-infra/cluster/info 10
- 12. Deployment-Schritte 1. SOA-Bundle oder SCA-Deployment an CompositeDeployerServlet senden http://servername:port/soa-infra/deployer 2. Erstellung eines temporären Verzeichnisses (/tmp/sar_base_dir_<randomId>/*) auf dem SOA Server. Anschließend das Composite in das temporäre Verzeichnis entpacken. 3. Operation redeploy/deploy feststellen (redeploy = undeploy und dann deploy) 4. Wenn vorhanden, dann Deploymentplan “anwenden” 5. Shared Metadaten in das MDS speichern (MAR-File) 6. Composite in das MDS speichern (/soa-infra/deployed-composites) MDS Label = "soa_" + UUID.randomUUID().toString(); /soa-infra/deployed-composites.xml 7. Aktivierung CompositeDeploymentCoordinator – deployServices(); – deployReferences(); – deployComponents(); – deployWires(); 8. Benachrichtigung von Cluster-Membern im Cluster mit Coherence 12
- 13. > MDS 13
- 14. MDS = Metadata Services • • Zentrale Komponente der Oracle Fusion Middleware für die Verwaltung von – Konfigurationsdaten von Komponenten und – Metadaten zu Applikationen MDS-Nutzung diverser Fusion Middleware Komponenten – ADF – WebCenter – SOA-Suite – JDeveloper – Fusion Applications 14
- 15. Metadata Repository basierend auf Datenbank basierend auf Dateisystem 15
- 17. MDS Repository – SOA Suite “custom” Artefakte Composites soa-infra Konfiguration /soa/shared /apps 17
- 18. > abstrakte vs. konkrete WSDL 18
- 19. Abstrakte und konkrete WSDL 19
- 20. Designtime Referenz auf abstrakte WSDL im MDS 20
- 21. Runtime Deploymentplan Notwendige Anpassungen: Element binding.ws Attribut port Element binding.ws Attribut location Empfehlung: Property endpointURI 21
- 22. Runtime: binding.ws Attribut Beschreibung port Syntax: WSDL-Namespace#wsdl.endpoint(Service-Name/Port-Name) wsdlLocation URL mind. für eine abstrakte WSDL-Datei. Falls binding.ws location nicht definiert wurde, sollte die hier referenzierte WSDL-Datei ebenfalls eine konkrete WSDL darstellen. location URL zu einer konkreten WSDL. endpointURI Überschreiben des definierten Endpunktes in der „konkreten“ WSDLDatei. 22
- 23. > Threads and Transactions 23
- 24. Sequentiell Routing Rule • • Sequential Routing Rules werden immer im gleichen Thread und gleichen Transaktion des Callee-Threads ausgeführt. Beim Aufruf vom Mediator wird geprüft, ob bereits eine globale Transaktion existiert. Wenn dies der Fall ist, erfolgt die Ausführung innerhalb dieser bestehenden Transaktion. Andernfalls wird eine neue Transaktion geöffnet. In diesem Fall übernimmt der Mediator die Lifecycle-Kontrolle der Transaktion (commit/rollback). 24
- 26. Thread and Transaction Details 26
- 27. Parallel Routing Debugging • Table „mediator_deferred_message‟ stores messages for parallel routing rules. For a given Mediator component, one row in this table corresponds to message for one parallel routing rule. Following SQL will provide number of messages, component name, and status for each Mediator component with parallel routing rules. Status could be one of READY (0), LOCKED (1), COMPLETED (2), ERROR (3). select count(*), component_dn, status from mediator_deferred_message group by component_dn, status order by component_dn, status • Table „mediator_case_instance‟ stores information about case instance. This table contains one row for each mediator case (i.e. routing rule) of a mediator instance. select count(*), status, case_name from mediator_case_instance group by status, case_name order by case_name; 27
- 28. Transaktionsverhalten Synchroner BPEL Prozess Property: bpel.config.transaction Wert Beschreibung required Ausführung in einer bestehenden (globale) Transaktion. Wenn keine Transaktion existent, dann wird eine neue Transaktion erstellt. requiresNew (default) Die Ausführung erfolgt immer in einer neuen Transaktion. Eine bereits bestehende Transaktion wird “ausgesetzt” 28
- 29. Transaktionsverhalten asynchroner (one way) BPEL Prozess Property: bpel.config.oneWayDeliveryPolicy Wert Beschreibung async.persist (default) Nachricht wird auf jeden Fall in der Datenbank gespeichert, bevor die eigentliche Verarbeitung startet (Tabelle: DLV_MESSAGE) async.cache Nachricht wird In-Memory gehalten. sync Ausführung innerhalb des aufrufenden Threads. Nachricht wird nicht zwischengespeichert. 29
- 30. oneWayDeliveryPolicy & Transactions Wert Beschreibung != sync > neuer Thread + neue Transaktion sync + requiresNew Aufrufender Thread + neue Transaktion (vergleichbar parallel Mediator) sync + required Aufrufender Thread + gleiche Transaktion (wenn vorhanden) 30
- 31. Asynchroner Fall bpel.config.oneWayDeliveryPolicy=async.persist / async.cache Thread 1 Thread 2 TX1 TX2 Client BPEL Process receive Server BPEL Process receive invoke Decision throw fault ... catch fault lb Rol ack 31
- 32. Receive Event Publish Event Event Delivery Network (EDN) ArbeitsschrittService Queue Mediator before BPEL Controller BPEL Event BPEL Mediator after BPEL Event Arbeitsschritt2BAMService Event Mediator 32
- 34. Fehlerkategorien • Prinzipiell 2 Fehlerkategorien: – Business faults – Runtime faults (or technical or system faults) 34
- 35. Business Faults • • • Application-specific Business logic decides how to handle fault Anticipated errors: failures in business state, input data inconsistencies, exceptional states • Examples: – Invalid account number submitted – Credit limit exceeded – Outside allowable date range 35
- 36. Business Faults Definition • Defined in service WSDL – Service designer defines message structure for the fault – messageType defined in WSDL • Example WSDL: <?xml version="1.0" encoding="UTF-8" ?> <definitions name=" NegativeCreditFault"> <message name="CreditRatingServiceFaultMessage"> <part name="detail" element="NegativeCreditFaultDetails" /> </message> </definitions> 36
- 37. Runtime Faults Also known as technical or system faults • • • Runtime faults – (remoteFault, bindingFault, etc.) - unexpected Infrastructure faults – Service down, network outage, connection timeouts Data format errors – Inappropriate data structure, corrupted message 37
- 38. Mediator (2): Fault Groups Fault Group Description TYPE_ALL all mediator faults TYPE_DATA Data related faults Assignment, Filtering, Transformation & Validation TYPE_METADATA Mediator metadata related faults Filtering conditions, transformation metadata, mediator metadata validation TYPE_FATAL fatal errors DB related, Cache related, error handling, SOA Infrastructure related, messaging, transaction etc. TYPE_TRANSIENT Errors that can be recovered Infrastructure related, messaging related 38
- 40. Fault Management Framework Policy Driven Fault Handling • Externalize your error handling • Policy-driven • Intended for technical faults (but handles business faults as well) • Engine level – No impact on BPEL process design – No impact on process in runtime (fault is isolated from process) • XML-based fault policies – Conditions for faults (fault name, XPath on fault content) – Set of actions (retry, human intervention, replay scope, rethrow fault, abort, custom Java action) – Centrally managed • Manual resubmission supported through Enterprise Manager console 40
- 41. Fault Handling Policy • Maps faults to actions • Specify fault by QName – e.g., bpelx:remoteFault, medns:mediatorFault • Specify criterea with XPath – Query fault code, details, etc • Specify action to be performed • Specify policies at different levels: – Composite – Component • Overrides any fault handling in the BPEL process • Defined in fault-policies.xml in the same directory as composite.xml – Can also be stored in the MDS and referenced in composite.xml – useful if standard policies across SOA applications 41
- 42. Fault Policy einbinden • • fault-binding.xml und fault-policies.xml im “Root”-Verzeichnis des composites ablegen. Ablage im MDS und Referenz in composite.xml <property name="oracle.composite.faultPolicyFile"> oramds:/apps/faultpolicyfiles/fault-policies.xml </property> <property name="oracle.composite.faultBindingFile"> oramds:/apps/faultpolicyfiles/fault-bindings.xml </property> 42
- 43. Java Action • Implements IFaultRecoveryJavaClass interface public interface IFaultRecoveryJavaClass { public void handleRetrySuccess(IFaultRecoveryContext ctx ); public String handleFault(IFaultRecoveryContext ctx ); } • • • • handleRetrySuccess is invoked upon a successful retry attempt. The retry policy chains to a Java action on retrySuccessAction handleFault is invoked to execute a policy of type javaAction Typically handles ‘side tasks’: notifications, fault logging and extended decisions about recovery action Executed in EJB context – within composite’s transaction 43
- 45. Java Fault Policies installieren 1. Java Sourcen in JAR-Archiv zusammenfassen. 2. Jar-Archiv nach $FMW_HOME/Oracle_SOA1/soa/modul es/oracle.soa.ext_11.1.1 kopieren 3. build.xml ausführen 4. SOA Suite durchstarten Achtung: Bug in build.xml, ab 11.1.1.7! <taskdef resource="net/sf/antcontrib/antcontrib.pro perties"> <classpath> <pathelement location="${env.ANT_HOME}/lib/ant-contrib0.6.jar"/> </classpath> </taskdef> 45
- 46. > Security 46
- 47. Sicherheitsstandards und Frameworks Trust Management, Federation Message Structure XML Frameworks Confidentiality, Integrity, Authenticity Transport Layer (HTTP, FTP, JMS, etc.) Non-XML Frameworks Transport-Level Security: Secure Socket Layer (SSL) Transmission Control Protocol and Internet Protocol (TCP/IP) 47
- 48. Oracle Web Services Manager Überblick Web Services Manager IDM Service Fusion App Service HTTP, SOAP, REST Attach, Deploy SOA Service WS Clients OWSM Agent JDeveloper Portal Users Enforcement Decision Policy Management Enterprise Manager Policy Persistence Policy Manager OWSM Policy Store Oracle Platform Security Service 48
- 49. Policy Policy Request Response Assertion 1 Assertion 2 Assertion n Policy Type Description Reliable Messaging Reliable messaging policies that implement the WS-ReliableMessaging standard describes a wire-level protocol that allows guaranteed delivery of SOAP messages, and can maintain the order of sequence in which a set of messages are delivered. Management Management policies that log request, response, and fault messages to a message log. Management policies may include custom policies. Adressing WS-Addressing policies that verify that SOAP messages include WS-Addressing headers in conformance with the WS-Addressing specification. Transport-level data is included in the XML message rather than relying on the network-level transport to convey this information. Security Security policies that implement the WS-Security 1.0 and 1.1 standards. MTOM Binary content, such as an image in JPEG format, can be passed between the client and the Web service. In order to be passed, the binary content is typically inserted into an XML document as an xsd:base64Binary string. Transmitting the binary content in this format greatly increase the size of the message sent over the wire and is expensive in terms of the required processing space and time. (Message Transmission Optimization Mechanism) 49
- 50. Policy Attachement • • • Designtime im JDeveloper, z. B. SCA-Composites Annotations (SecurityPolicy), Deployment-Deskriptor, z. B. JAX-WS Services Runtime im Fusion Midleware Control – Manuell – Policy Sets 50
- 51. Oracle Web Services Manager OWSM Agent OWSM Agent request response Reliable Messaging Policy Interceptor Management Adressing Security MTOM Client Policy Interceptor Pipeline • Prüft die Einhaltung von Policies anhand der Policy Interceptor Pipeline. • Request: Reliable Messaging > Management > Adressing > Security > MTOM • Response: MTOM > Security > Adressing > Management > Reliable Messaging 51
- 52. > Purging 52
- 53. Herausforderung • stetiges Wachstum im Dehydration Store (*_soainfra) – abhängig vom Audit Level – abhängig von den SCA Composites 53
- 54. Herausforderung • Einfluß des Audit Levels auf das Datenbank-Wachstum Quelle: Oracle Whitepaper SOA 11g - The Influence of the Audit Level on Performance and Data Growth Oktober 2012 54
- 56. Purge Varianten • • • • • • Purge Scripts – Looped Purge Script – Looped Purge Script in Parellel Mode Database Partitioning TRS Script Enterprise Manager Infrastructure Management API (Java) “Development Only: Truncate Skript” 56
- 57. > Tuning 57
- 58. Einflussfaktoren • • • Nachrichtenanzahl Nachrichtengröße Komplexität der Transformation • Art und Weise der Composites – synchron vs. asynchrone Services – langlaufende oder kurzlaufende Services • Systemarchitektur – Ungleichverteilung und Lastspitzen • Security & Verschlüsselung 58
- 59. SOA Suite Audit Level Die Audit Level können auf folgende Werte gesetzt werden: • „Inherit“: übernimmt Einstellung der nächst höheren Schicht • „Production“ (default): Instanz- und Payload-Aufzeichnung; Mediator und Assign-Aktivität in BPEL zeichnen keine Payload-Details auf • „Development“: Alle Instanz- und Payload-Details werden aufgezechnet; negative Auswirkungen auf die Performance • „Off“: Keine Instanz- und Payload-Aufzeichnung; für große Payloads empfohlen „Capture Composite Instance State“ (On|Off): Status laufender Instanzen wird evaluiert; negative Auswirkungen auf die Performance 59
- 60. Tuning-Bereiche • • • • • Datenbank: Indizes, SGA, Tablespaces, Processes, Sessions, ... Dehydration Store: v.a. Purging-Strategie ! JVM: Heap Size (min=max), Garbage Collection (Timeouts) WebLogic: Connection Pools, Threads, Transaction Timeout, ... SOA Komponenten: Thread Pools, Log Level, Batching, ... 60
- 61. Markus Lohn Head of Technology Consulting > Consultant, Trainer und Experte für SOA und Java EE-Technologien (Oracle 8i - FMW 12c) > Umfangreiche Erfahrung bei der Umsetzung von komplexen Projekten mit Oracle-Technologien seit 1999 in den Branchen: Öffentliche Verwaltung, Banken und Versicherungen, Automotive, Industrie und Baugewerbe Mit Markus Lohn vernetzen E-Mail: markus.lohn@esentri.com Blog: blog.esentri.com Twitter: @MarkusLohn 61
- 62. Über die esentri AG „Wir leben unsere Vision vom agilen Unternehmen der Zukunft. Mit unserer Begeisterung für führende Technologien vernetzen wir Systeme, Prozesse und Menschen.“ @esentri facebook.com/esentri 62
Hinweis der Redaktion
- WebLogic Domain: Zusammenfassung von Managed Servern und ClusterzumAdministrierenAdmin Server: 1x/Domäne, zentralerPunktzur Administration der Domäne, eigene JVM, hosted WebLogic Console und Konfigurationsdaten (config.xml)Managed Server: eigene JVM’s, Hosting von Applikationen und Ressources, verarbeiten RequestsCluster: Gruppierung von Managed Servernzueiner “Runtime-Umgebung” ausClientsicht, ermöglichtSkalierung und HA fürApplikationenNode Manager: optionalerDeamon-Java-Prozess, notwendig auf Servernmit Managed Servern, ermöglichtStarten/Stoppen von Managed Servernüber Console, ferner Monitoring und automatischer Restart von Managed Servern.
- config/config.xml XML Repository beinhaltetServerkonfiguration + weitere XML-Dateien in Subfoldern, managed by AdminServer, WLSTMSI = Managed Server Independence Managed Server nutztgecachtelokaleKonfiguartion, wenn Admin Server nichtverfügbarversuchtaber in jedem Fall zyklisch den Admin Server anzusprechenThe Administration Server stores the master copy of the domain configuration, including the configuration for all managed servers in the domainEach Managed Server stores a local copy of its configuration. When a Managed Server starts, it connects to the Administration Server to synchronize the configurationWhen configuration is changed, the Administration Server sends changed configuration to Managed Servers
- Oracle Platform Security Services (vormals JPS in 10g)OPSS..Securityframeworkfüralle Fusion Middleware Produkte und Fusion Applicationszunächstunabhängigvom Application Serverausgelegtfür Java EE und Java SE Applikationen Portable (unterschiedlicheApplikation Server) Abstraktionsschicht um EntwicklungszeitzusparenKonzentration auf das Wesentliche, nichtjedePlattform und Umgebungzukennen
- Initialisierung von Spring durch ListenerThe WLSFabricKernelInitializer runs last and looks for the completion of FabricProviderServlet before the soa-infra is open to accept requests Server LifecycleAt startup checks synchronization of SCA across cluster (each server uses MDS as single source of truth and checks its version of eachcomposite against the MDS version) At restart reviews content of: deployment-composites.xml (which is stored in Metadata Repository (MDS)) For each component check if expanded directory for the SCA exists under: $DOMAIN_HOME/servers/xxx/dcif not there, then the expanded directory will get recreated from the files stored in MDS (goes back to a sub part of deploy)
- Demo: EMöffnen und neue Partition anlegen => dannfolders.xmlöffnen
- Aspekt 1: Entkopplung von der Runtime-Umgebung, Fehler!!!!!!!Aspekt 2:Dependency order is not recorded in SOA Suite for composites. So, during server start-up, there might be multiple retries before all composites are loaded to the server if a wrong dependency order is followed by the server.This does not necessarily mean the composites are not loaded at all, but server may end up trying to load a composite multiple times before it is finally succeeds after restart. This results in multiple errors in logs and also overall time taken for restart. E.g., as seen in the diagram below, if the server tries to load A before B and C are deployed then the composite loading fails. This can also happen during deployment time if there is a circular dependency between composites.Solution to this problem is isolating design time and runtime dependencies. This can be done by moving WSDL dependencies to abstract WSDL’s. We can store the abstract copies of all such WSDL’s in MDS.
- Transaction 1 Message is inserted in Mediator store (DB) in this transaction. Mediator participates in the global transaction started by the callee. If callee has not started a global transaction, Mediator starts and manages a global transaction. Sequential routing rules are executed as part of Transaction 1 as well. Transaction 2 and Transaction 3 Each routing rule is processed in its own transaction Mediator starts and manages Transaction 2 and Transaction 3. Mediator invokes outbound reference (adapter/service) in this transaction. If outbound adapter is a transactional adapter and has been configured to use XA transaction, it will participate in Transaction 2 started by Mediator.
- Locker Transaction 1. Starts transaction T1 2. Locks N messages 3. Commits transaction T1 4. Selects N messages locked in step 3 above 5. Adds to in-memory LinkedBlockingQueueWorker Transaction(s) Get message from in-memory LinkedBlockingQueueStart transaction T2 Process message If processing successful, update status of message as completed in database. Commit transaction T2 If processing fails, rollback transaction T2 Start transaction T3 Enqueue to error hospital Set status of message in database as errored. Commit transaction T3
- BPEL always executes in the context of a transaction. It never executes outside the context of a transaction. By default, the BPEL Process Manager creates a new transaction, regardless of whether the process is synchronous or asynchronous. I.e. if a transaction already exists, it is suspended and a new transaction is created. When the child transaction completes, the master transaction continues. (See Oracle BPEL Process Manager Transaction Semantics.)
- Property „bpel.config.oneWayDeliveryPolicy“ steuert das Verhalten: „async.persist“: + zuverlässig: NachrichtwirdimRahmen der aufrufenden TA dehydriert+ skalierbar: Invoker Thread ausdem Pool fürweitereAusführung- keinegarantiertesofortigeAusführung„async.cache“:+ schnell: eingehendeNachrichtenwerden In-Memory gehaltenmöglicheÜberflutung (out-of-memory) mitNachrichtenverlust„sync“mit„required|requiresNew“:+direkteAusführungimaufrufenden Thread (ggf. mitneuerTransaktion)
- one and only oneEvent delivery to the subscriber in its own transaction. If subscriber failed delivery will be retried a configured number.GuaranteedEvent delivery asynchronously without a global transaction. Subscriber can create its own transaction. Howeverthis transaction is independent from the EDN. However if subscriber failed the event is not resend! Message losecan be the result for some subscribersImmediateEvent delivery in the same global transaction and thread as the subscriber.
- WSDL-Definitionzeigen (Shared Artefacts)esentriBaseTypeszeigen
- Default Action wennkeine Fault-Policy definiert: Human InterventionSequentiell Routing Rules werdenimmer an den Caller übergeben und die Transaktion rollbackauchwenn Fault-Policy vorhandenwäreTYPE_DATA: Contains errors related to data handling. – TYPE_DATA_ASSIGN: Contains errors related to data assignment. – TYPE_DATA_FILTERING: Contains errors related to data filtering. – TYPE_DATA_TRANSFORMATION: Contains errors that occur during a transformation. – TYPE_DATA_VALIDATION: Contains errors that occur during payload validation. TYPE_METADATA: Contains errors related to Mediator metadata. – TYPE_METADATA_FILTERING: Contains errors that occur while processing the filtering conditions. – TYPE_METADATA_TRANSFORMATION: Contains errors that occur while getting the metadata for a transformation. – TYPE_METADATA_VALIDATION: Contains errors that occur during validation of metadata for Mediator (.mplan file). – TYPE_METADATA_COMMON: Contains other errors that occur during the handling of metadata. TYPE_FATAL: Contains fatal errors that are not easily recoverable. – TYPE_FATAL_DB: Contains database-related fatal errors, such as a Datasource not found error. – TYPE_FATAL_CACHE: Contains Mediator cache-related fatal errors. – TYPE_FATAL_ERRORHANDLING: Contains fatal errors that occur during error handling such as Resubmission queues not available. – TYPE_FATAL_MESH: Contains fatal errors from the Service Infrastructure such as Invoke service not available. – TYPE_FATAL_MESSAGING: Contains fatal messaging errors arising from the Service Infrastructure. – TYPE_FATAL_TRANSACTION: Contains fatal errors related to transactions such as Commit can't be called on a transaction which is marked for rollback. – TYPE_FATAL_TRANSFORMATION: Contains fatal transformation errors such as an error occurring because of the XPath functions used in a transformation. TYPE_TRANSIENT: Contains transient errors that can be recovered on a retry. – TYPE_TRANSIENT_MESH: Contains errors related to the Service Infrastructure. – TYPE_TRANSIENT_MESSAGING: Contains errors related to JMS such as enqueuing and dequeuing.
- Standard faults are defined as follows:Typeless, meaning they do not have associated messageTypesNot associated with any WSDL messageOracleDurch die Infrastruktur in bestimmtenSituationengeworfenFaultsvomTypRuntimeFaultMessagebindingFaultA bindingFault is thrown inside an activity if the preparation of the invocation fails. For example, the WSDL of the process fails to load. A bindingFault is not retryable. This type of fault usually must be fixed by human intervention. remoteFaultA remoteFault is also thrown inside an activity. It is thrown because the invocation fails. For example, a SOAP fault is returned by the remote service. replayFaultA replayFault replays the activity inside a scope. At any point inside a scope, this fault is migrated up to the scope. The server then re-executes the scope from the beginning.
- Beispiel:Service aufrufen, der nichtverfügbarist => mehrfachprobieren, dann human interventionService aufrufen, der nichtverfügbarist => terminate
- Beipielklasseprogrammieren und einbinden + Properties setzenFaulthandlerbeispielzeigen
- SOA und Websservices => XML-BasisUnterscheidung in... Non-XML => Transportebene XML-Frameworks => ApplikationsebeneNon-XML (Transportebene)bereits etablierten Sicherheits-Algorithmen (RSA, AES, DES,...) allgemeinen Sicherheitsstandards (SSL, X.509, PKI, Kerberos)XML-Frameworks...Confidentiality, Integrity, AuthenticityXML Encryption, XML SignatureMessage Structure, Message SecuritySOAP, WS-SecurityMessage DeliveryWS-AddressingWS-Reliable Messaging Trust Management SAMLWS-TrustWS-Secure ConversationMetadataWS-Policy, WS-Policy Attachment, WS-Security PolicyWS-Metadata Exchange Access ControlXACMLViele Standards, Versionen und Werkzeuge => WS-I Basic Security Profile In diesem Profile werden Restriktionen in Bezug auf die Verwendung dieser Standards definiert. Hierdurch soll die Interoperabilität bei Nutzung dieser Sicherheitsstandards gewährleistet werden.
- Zero Install – OWSM agent as well as policy manger is pre-package with the Oracle platform. So its available OOTB when you install any Oracle Fusion product.OWSM provides centralized policy management with distributed decision-making and enforcement. Policies are reusable across any type of web services on any platform supported by OWSM.OWSM comes pre-packaged with 90+ most commonly used OOTB policies. Think of OWSM agentas sitting “in front of” your web service to protectaccess to the functions and information your business needs.OWSM agents are embedded with WebLogic, SOA, Fusion Apps, & IDM products. OWSM agents reach out to the OWSM policy manager, which acts as a policy decision & distribution point. Policy Manager is the gatekeeper for policy access for design time as well as run time. Oracle Enterprise Manager (Fusion Middleware Control) can be used to perform OWSM policy management (Browse, Edit, Delete, Add, Export, Import, etc.). Oracle Enterprise Manager interacts with the policy manager to perform policy management operations. OWSM policies are stored in an MDS-managed repository. The repository can be shared across multiple domains, and therefore there can be one repository serving the entire enterprise. Policies stored as XML files.OWSM policies can be browsed and attached during design-time in JDeveloper. Agents OES works closely with your current identity directories and entitlements data sources (e.g. LDAP) to ensure the right functions and data go to the right user.
- Policiesdescribingcapabilitiesandrequirementsof a web servicePolicy besteht aus 1..n AssertionsAssertions sind die kleinste Einheit, die eine Operation auf einem Request oder Response angewandt wird Ausführung der Operationen erfolgt in der definierten Reihenfolge sowohl auf dem Request, als auch auf der Response in umgekehrter Reihenfolge Eine Assertion gehört immer zu einer der folgenden Categorien:Reliable Messaging ManagementAdressing Security MTOM Eigene Policies können definiert werden: Bitte Namenskonvention folgenPolicies können in Form von XML-Dateien zwischen den Umgebungen ausgetauscht werden Eigene Policies können definiert werden
- Policy Sets funktionieren aktuell nicht für JAX-WS services Policy attachment is not synchronized automatically for SOA, ADF, and WebCenter services in a cluster. When using SOA, ADF, and WebCenter services in a cluster, you must attach and/or detach policies to each instance of the cluster. This issue does not apply to WebLogic Java EE Web services and SOA composite services.
- Prüft die Einhaltung von Policies anhand der Policy Interceptor Pipeline kommuniziert mit dem Policy Manager, um die Policy-Definitionen aus dem Repository zu erhalten. Caching Verhalten erläutern Implementiert einen lokalen in-Memory Cache für die Policies, in definierbaren Zeitabständen erfolgt eine Synchronisation mit dem Policy Manager, dabei werden lediglich Änderungen ausgetauscht Wenn der zentrale Policy Manager ausfällt, dann werden die Policies immer aus dem lokalen Cache gelesen und der Zugriffsschutz ist sichergestellt. Wenn der Client jedochneu gestartet wird und der Policy Manager ist nicht verfügbar, dann kann der Service nicht aufgerufen werden. Abarbeitung erfolgt je nach zugewiesener Policy im Service Request: Reliable Messaging > Management > Adressing > Security > MTOM Response: MTOM > Security > Adressing > Management > Reliable > MessagingPolicy Interceptor fest vorgegeben
- Excel-Sheetzeigen