Adaptéry a eventy v ICS (Integration Cloud Service)

Poměrně čerstvým přírůstkem v rozsáhlém portfoliu Oraclích cloudových PaaS služeb je ICS. Je vhodná zejména pro integraci dvou různých cloudových aplikací mezi sebou. K tomuto účelu obsahuje sadu adaptérů, které umožňují připojení nejen k Oraclím aplikacím, ale i jiným SaaS providerům, jako např. SalesForce. Paleta adaptérů obsahuje jak aplikační, tak i technologické adaptéry a rovněž adaptéry pro sociální sítě jako Facebook či LinkedIn.
Podporovány jsou samozřejmě i nativní Web Services a REST, takže je možné vytvořit integrace s jakoukoli jinou aplikací nebo službou, pro kterou dosud není k dispozici předpřipravený adaptér.
K dispozici je i agent, kterého můžete instalovat on-premise a který pak funguje jako gateway mezi ICS a on-premise aplikacemi ve vašem DC.

Samotný koncept integrace, tedy propojení dvou bodů, které vystavují rozhraní většinou na bázi SOAP/REST, je stejný jako OSB. Dalo by se říci, že ICS je v podstatě tenký klient, který vám umožňuje vystavit proxy a business rozhraní a mezi tím v request/response pipelines provádět zpracování zprávy. Přitom samozřejmě nemáte k dispozici ani zdaleka všechny funkce jako v on-premise OSB, pouze jejich omezenou podmnožinu:

Definovaný koncový bod (Connection) může být využit jak pro příchozí, tak odchozí komunikaci. Ne všechny ICS adaptéry však tento model podporují, většinou proto, že výrobce příslušné cílové aplikace nevystavuje  k tomu potřebné operace a eventy. Záleží tedy na tom, jaký adaptér používáte a s jakou aplikací se integrujete. Např adaptéry pro OSC, ERP, RightNow a SalesForce mohou být využity jako zdroj i jako cíl. Oproti tomu adaptéry pro Eloqua a NetSuite podporují pouze outbound komunikaci.

Pokud to daný adaptér podporuje, můžete vytvářet i Event based triggers (fakt nevím, jak to napsat česky :). Když v externí aplikaci dojde k určité události (event), pro kterou jste vytvořili trigger, je zpráva s daty této události odeslána do ICS. Adaptéry v ICS obsahují podporu pro discovery a konfiguraci eventů. Při aktivaci flow, zpracovávajícího daný event, se ICS adaptér u zdrojové aplikace automaticky zaregistruje jako subscriber pro tento event. Zprávy obsahující data eventu jsou pak zdrojovou aplikací odesílány na příslušný ICS endpoint.

Situace není ztracena ani v případě aplikací, které ve svých rozhraních publikování eventů nepodporují (tj. nevystavují subscription API), jako např. Salesforce. Po přihlášení do Salesforce je možné v této aplikaci definovat odchozí zprávu a přiřadit ji k určité události, spolu s případnými podmínkami pro odchytávání této události. Následně v Salesforce vygenerujete nad takto definovaným rozhraním WSDL. Toto WSDL pak v ICS naimportujete pomocí Salesforce adaptéru. ICS pak vystaví endpoint potřebný pro příjem zpráv ze Salesforce. Tento endpoint následně zaregistrujete v Salesforce a jste ready 2 go.

WLS 12.2.1 infrastruktura a licence pro Multitenant edition

Budete-li chtít stáhnout instalátor Weblogicu z OTN, dozvíte se z download page, že:
- Quick installer obsahuje plné Dev prostředí pro JEE7 + Coherence
- Generic installer navíc obsahuje samples a soubory pro console help
- Infrastructure installer k tomu přidává FMW Control a Java Required Files (JRF) pro správu Multitenant domén s více oddíly (partitions).

Pokud tedy chcete odzkoušet Multitenant, Continuous Availability, nebo k WLS doinstalovávat další produkty z rodiny FMW, potřebujete stáhnout FMW Infrastructure installer.

Všechny typy instalace obsahují WLST, JMX a REST rozhraní, která podporují práci s doménami bez partitions, s jednou partition i více partitions. V případě WLS konzole však tuto doporučujeme jen pro správu domén buď bez partitions anebo single partition, nikoli však pro správu multiple partitions. Pro správu domén s multiple partitions doporučuje Oracle použít OEM Fusion Middleware Control, jejíž instalace včetně podpůrných JRF (Java Required Files) může být provedena pouze Fusion Middleware Infrastructure installerem. Pokud tedy chcete vyzkoušet WLS Multitenant, potřebujete stáhnout Fusion Middleware Infrastructure installer, který jako jediný obsahuje instalaci FMW Control potřebné pro správu multitenant domén.

Z licenčního pohledu je to tak, že WLS EE a Suite umožňují využívat jen domény s jednou partition. Práva pro využívání více partitions obsahuje až edice WLS Multitenant, která se v licenční hierarchii nachází na nejvyšším stupni, ještě nad Weblogic Suite.

Jak se vyvíjela podpora Mavenu ve WLS

Pokud někdo někdy skutečně čte Release Notes, v těch k Weblogicu 12.2.1 se dozví, že došlo k ukončení podpory starší verze Weblogic Maven Pluginu 12.1.1. (wls-maven-plugin.jar). To některé uživatele může zmást a proto zaslouží podrobnější vysvětlení:

Hlavním důvodem pro ukončení podpory starší verze pluginu je jeho architektura, která vyžaduje mít lokálně nainstalovaný WLS, ze kterého pak vykonstruuje umělou CLASSPATH. Takovýto přístup ale není v souladu se standardním způsobem, jakým Maven deklaruje a řídí závislosti.

První opravdu významná a dobře použitelná podpora Mavenu přišla až s WLS 12.1.2, kde pokrývala klíčové oblasti jako

• provisioning POMů pro Oracle knihovny, API a utility
• další plugin oracle-maven-sync, který umí výše uvedené artefakty uložit do lokální repository
• místo používání uměle konstruované CLASSPATH z lokální instalace využívá sadu deklarovaných závislostí, což je mnohem více v souladu se standardním Maven modelem.

Ve verzi 12.1.3. pak byla přidána podpora pro wlst-client goal, který umožňuje vzdálené spouštění WLST skriptů, aniž by bylo třeba mít lokálně instalovaný Weblogic. To je důležité pro podporu DevOps a Continuous Integrace, neboť veškeré potřebné závislosti/artefakty mohou být natažené z lokální nebo firemní repository standardním způsobem, kterým Maven řídí závislosti a synchronizaci.
Byla také publikována veřejná Oracle-Maven repository, obsahující všechny artefakty, pluginy a archetypy. Díky tomu mohou vývojáři a testeři používat naše API a pluginy, aniž by je předtím museli lokálně instalovat.

Protože verze od 12.1.2+ jsou mnohem vyzrálejší, více Maven friendly a z hlediska dalšího vývoje poskytují více možností, došlo k "deprecation" verze 12.1.1., která díky zásadním změnám v architektuře pluginu od 12.1.2+ přestala být jakkoli relevantní a proto byla odstraněna.

Školení na WebLogic zdarma

Zní to dobře a navíc je to dokonce i pravda :) Nejedná se však samozřejmě o standardní týdenní školení Weblogic Administration I, II apod. Jde o série krátkých (většinou mezi 15-60 minutami) přednášek či paperů, které k danému produktu či tematu vytvořili konzultanti z Oracle.

Jením zdrojem těchto přednášek je Oracle Learning Library (OLL). Ta obsahuje řadu přednášek i na trilion jiných témat, počínaje db až po aplikační balíky typu Siebel.

Další materiál, specificky k Weblogicu, je zde:

·         Best Practices for WebLogic and SOA Management Self-Study Course

Oracle University Course:

·         Oracle WebLogic Server 12c: Enterprise Manager Management Pack

WLS Performance Monitoring and Diagnostics

·         Navigate the Middleware Routing Topology

·         Customize Middleware Performance Summaries

·         Diagnose WebLogic and Java Performance Bottlenecks

·         JVM Diagnostics as a Service (new in EM 12c R4)

·         How to Use JVM Diagnostics to Find the Root Cause of Lock Threads

·         Capture Diagnostics Snapshots

·         Use the Middleware Diagnostics Advisor to Size the JDBC Connection Pool

·         Diagnose Performance Issues End-to-End

·         Construct a Service Level Agreement

·         Overview of Business Transaction Management 12c

·         Service Dashboard

·         Business Application Dashboard

WLS Configuration and Lifecycle Management 

·         Administrate WebLogic Domains from a Single Pane of Glass

·         Use and Report on Out-of-the-Box Compliance Standards

·         Create WebLogic Domain Provisioning Profile

·         Clone an Oracle WebLogic Domain from the Software Library

·         Redeploy a Java EE Application

·         Patching WebLogic Server

·         Automate Disaster recovery with "Oracle Site Guard"

·         Schedule and Track WLST Scripts
·         Create Install Media Based Provisioning Profile for Fusion Middleware

Všechna školení jsou jako obvykle v jazyce anglickém. Kdo jím nevládne, může navštívit můj Oracle middleware Czech Channel.

Různé verze schemat pro webové aplikace na WLS

Čeho všeho si lidé nevšimnou? Třeba následujícího:

V definici weblogic.xml pro WLS 12.1.3 viz http://docs.oracle.com/middleware/1213/wls/WBAPP/weblogic_xml.htm#WBAPP572 je odkaz na schema http://xmlns.oracle.com/weblogic/weblogic-web-app/1.7/weblogic-web-app.xsd. Toto schema (weblogic-web-app.xsd) používá web-app_2_5.xsd:

<xs:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"/>

Orpoti tomu definice web.xml pro stejnou verzi WLS 12.1.3 používá referenci na totéž schema ve vyšší verzi 3.0: http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/web-app_3_0.xsd

Samozřejmě se jedná o bug, ale může mít nějaký praktický dopad?

Nikoli, protože odkazované standardní schema obsahuje jen definice jednoduchých datových typů, případně typů, které existují už od pradávna :), např:

javaee:xsdStringType 

javaee:xsdIntegerType 

javaee:emptyType

javaee:xsdNonNegativeIntegerType 

javaee:url-patternType 

javaee:servlet-nameType

Proto by tento bug neměl způsobovat žádné funkční problémy a jeho oprava byla zařazena až do release WLS 12.2.1.

JSON nebo XML?

Toť otázka, která začíná být aktuální zejména v souvislosti s fenomenem příchodu mobilních klientů. V jejich případě totiž hrají důležitou roli zpoplatněné mobilní datové přenosy. Připojení pomocí WiFi není často k dispozici vůbec, nebo je velmi pomalé a klient tak musí realizovat datové přenosy prostřednictvím mobilní sítě. V ní má datové přenosy buď omezeny limitem na objem přenesených dat, které má k dispozici v rámci měsíčního paušálu, nebo platí per use za každý MB. V takovém případě přináší použití JSONu významnou výhodu, neboť objem přenášených dat může být v tomto případě i řádově nižší. To je pro klienta samozřejmě výhodné, ale při hodnocení výhod a nevýhod této technologie musíme vzít v potaz i dopad na stranu druhou, kterou je aplikační server a potažmo IT architektura celého  prostředí, ve kterém jsou aplikace provozovány.
S XML je totiž spojena řada podpůrných specifikací, vyvinutých během řady let pro potřeby podnikového nasazení služeb, kterých "klasické" SOAP Web servicy v praxi hojně využívají: 

• XML Payload Handling: XML Namespaces, XML Schema, XPath, XQuery, XInclude, XML Pointer 
• Interakce: SOAP, WS-Notification, WS-Addressing, WS-Eventing, WS-Enumeration 
• Výměna metadat: WS-Policy, WS-MetadataExchange, WSDL 2.0 Core, WSRF
• Bezpečnost: WS-Security, XML Signature, XML Encryption, WS-Trust, WS-Federation       
• Reliable Messaging: WS-ReliableMessaging, WS-Reliability, WS-RM Policy Assertion 
• Řízení transakcí: WS-BusinessActivity, WS-AtomicTransaction, WS-Coordination, WS-CF

Vyzrálost SOAP/XML je mnohem vyšší, než u REST/JSONu a toto je třeba vzít v úvahu při návrzích řešení a vyhodnocení jejich dopadu na stávající architekturu. V případě, kdy máte k dispozici OSB 12c, je vaše situace výrazně usnadněna, neboť nabízí současnou podporu obou těchto standardů.

Autostart WLS na platformě Windows

WLS lze na Windows po startu systému automaticky spouštět dvěma způsoby: 1. pomocí Windows service (beasvc.exe), nebo 2. Node Manageru. Který z těchto způsobů je lepší, nebo je snad dokonce vhodné používat oba najednou?

Krátká odpověď: jako best practice doporučuje Oracle používat NM pro start/restart všech WLS serverů, včetně Admin serveru. Přitom je doporučeno mít v konfiguraci NM nastaveno CrashRecoveryEnabled=true, což NM umožní v případě problému instanci automaticky restartovat.

Proč tedy NM?
Přestože je technicky možné spouštět některé servery pomocí beasvc.exe a jiné pomocí NM, určitě bych to nedoporučoval. Z pohledu správy je to nevýhodné a admin by si asi těžko vzpomínal, které z x serverů spouští pomocí NM a které beasvc. Rovněž zde hraje roli rozdělení zodpovědnosti a organizace v provozu, kdy za Windows služby odpovídá a spravuje je správce, který nemusí mít ani ponětí o tom, jak WLS funguje a jak provozovat JEE aplikace.

Na rozdíl od generické Windows služby, je NM přímo navržen a implementován výlučně pro správu WLS. Průběžně monitoruje servery, které spustil, a může provádět operace, které Windows služba provádět neumí, jako např. reagovat na změnu stavu (health) serveru, nebo jeho přetížení.