Oracle Virtual Technology Summit 26. listopadu

Koncem listopadu bude probíhat zajímavý online seminář, sestávající z několika paralelních tracků, zaměřených na:

• databázi
• Javu
• Middleware
• Vývoj

Celá akce bude samozřejmě v jazyce anglickém, neb je určena zákazníkům z celé Evropy. Javovská část bude zaměřena zejména na nové vlastnosti JDK 8 a JEE7. Middleware track se soustředí hlavně na vývoj a integraci mobilních klientů za podpory OSB 12.1.3.

Podrobný popis všech tracků je k dispozici zde, registraci najdete tady.

Enterprise Scheduler Service (ESS)

Jak asi víte, koncem června uvedl Oracle na trh novou verzi balíku SOA Suite, konečně ve verzi 12c. Ta je technologicky postavena nad Weblogicem 12c, takže konečně po asi 5ti letech dochází ke sjednocení vývoje obou těchto platforem.
V rámci SOA Suite 12c se kromě produktů, které do SOA Suite patřily už v předchozích verzích, objevily i dvě nové, řekl bych velmi zajímavé komponenty: Managed File Transfer (MFT) a Enterprise Scheduler Service (ESS), na kterou se zaměřuje tento příspěvek. Jeho cílem je stručně a srozumitelně popsat hlavní vlastnosti a funkcionalitu ESS.

Každá větší společnost potřebuje ve svém IT prostředí spouštět opakovaně či ad-hoc velkou spoustu rozličných typů úloh (dále jobů). Mohou to být shell/OS scripty, uložené procedury, volání EJB atd. A právě tuto problematiku, ve které často panuje značný chaos, pomáhá řešit ESS.

ESS podporuje následující typy jobů: PLSQL, Java, EJB, spawned a samozřejmě i Web services. Vlastní typy jobů prozatím podporovány nejsou.
Řeší také vzájemné závislosti a konflikty mezi joby.
Monitorování, konfigurace a troubleshooting ESS jsou prováděny pomocí nástroje Enterprise Manager (EM), podporován je i WLST.
Scheduling jobů je definován v souladu s IETF standardem RFC 2445 (iCal), který slouží k definici opakovaně spouštěných úloh. Je např. možné rozdělit jednu velkou úlohu na více podúloh, např. zpracování výplat pro zaměstnance velké firmy provádět sadou podúloh, jednu pro každé písmeno abecedy (dle jejich přijmení). Tato množina je pak označována termínem "jobset". Jobsety mohou být vnořené a joby v nich mohou být prováděny buď sekvenčně, nebo paralelně.
Vytvoření jobu probíhá následujícím způsobem:

V praxi to pak v Enterprise Manageru vypadá takto:

ESS pracuje s následujícími objekty:
WorkAssignment mapuje sadu zdrojů(WorkShift) na joby, vybrané pomocí kriterií uložených ve Specialization.
RequestProcessor je namapován na server a zajišťuje spouštění k němu přiřazených WorkAssignmentů.
WorkShift objekt určuje zdroje (thready a throttling), které pak přiřazuje konkrétním jobům.
Specialization obsahuje kriteria jobu: uživatel, produkt, kategorie, job, jobset.

Schedule je objekt, obsahující definici data, času a opakování. Je definována nezávisle na konkrétním jobu a k jobům/jobsetům je přiřazována až po jejich vytvoření.

Vztahy mezi těmito objekty zachycuje následující diagram:

Throttling (regulace zátěže): ESS umožňuje pro každý job nastavit omezení, jaký maximální počet instancí tohoto jobu může  v čase běžet

Targeting: je možné říci, na jakém serveru a kdy má být daný job prováděn. Tedy např. servery X a Y budou provádět každých posledních 5 dní v kvartálu účetní joby apod. Tím je možné využít kapacit silnějších a výkonnějších serverů a směrovat na ně tuto zátěž.

ESS pracuje s následujícími uživatelskými rolemi:

• Job Developer - pomocí EM nebo JDeveloperu vytváří implementace a definice jobů a jobsetů.
• Business User - používán pouze ve Fusion aplikacích společnosti Oracle
• Administrator - pomocí EM definuje spouštění jobů, zabezpečení, spouští, monitoruje a zastavuje joby atd.

V rámci balíku SOA Suite je ESS plně integrován s Oracle EM, BPEL, OSB a MFT komponentami. To umožňuje provádět zajímavé věci, jako např. spouštět v určitou denní (v praxi spíše asi noční) dobu dávkovou recovery všech neúspěšných BPEL instancí, které EM eviduje ve svém Error hospital.

ESS podporuje Weblogic a DB pouze ve verzi 12c.

V případě db je uložená PLSQL procedura volána db schedulerem. Výsledek jobu je možné vrátit pomocí AQ fronty. U Java jobů je vrácen výsledek pomocí Java Callback API, u webových služeb je možné použít async WS callback.
Následující stavový diagram zachycuje možné stavy a životní cyklus jobu:

Doporučené nasazení ESS je ve stejném clusteru jako SOA Suite, na který deployneme ESS runtime. Ten je tvořen .ear archivem, obsahujícím ESS Runtime plus pár sdílenými knihovnami.

Správa ESS

Je prováděna výlučně pomocí nástroje Enterprise Manager (EM):

 
Jobů může být prováděno obrovské množství. Pokud např. zakládají joby BPELovské procesy, typicky stovky nebo tisíce instancí těchto procesů během jednoho dne, nebo i hodiny, může být spouštěno a archivováno stejné mnpžství jobů. Proto je třeba historii již provedených jobů čistit, a právě k tomu slouží tzv. purge politika, kterou je možné realizovat dvěma způsoby: 
Logical Purge - automaticky přiřazením Purge policy k jobu
Physical Purge - DBA ručně spouští uloženou PLSQL proceduru.
V rámci Purge policy je možné zadat různá kriteria pro čištění informací o jobech, které skončily úspěšně, s chybou apod.

Dokončení jobů: v případě chyby se ESS snaží job opravit (je-li to pro job povoleno) automaticky, a poté jej znovu spustit. Nejde-li job opravit automaticky (nebo to není povoleno), je upozorněn admin, který jej může opravit ručně.

Samozřejmě je možné v EM zobrazovat informace o jakémkoli job requestu:

Přehled o patchích na WLS

Až do verze 12.1.1 vypisoval Weblogic do server logu přesné číslo verze včetně patche.
Od 12.1.2 dále se však do logu zapisuje jen číslo minor verze. Budete-li tedy např. aplikovat 12.1.2.0.2 PSU, bude v server logu stále zobrazeno jen .....WLS_12.1.2.0.0.....

Chcete-li se podívat na to, jaká je verze včetně patche, je zapotřebí použít OPatch Inventory:

./opatch lspatches
18545123;WebLogic Server 12.1.2.0.2 PSU Patch for BUG18545123   Mon May 21 10:54:42 IST 2014 

Kolik WebSocket připojení je schopna utáhnout instance Weblogicu?

Náhodou jsem kápnul na zajímavý slide:

60 tisíc socketů (bez SSL) a 20k zpráv za vteřinu mi přijde docela impozantní. Autor slidu v kometáři píše, že testovali stejný benchmark i s SSL a tam WLS zvládl 40 tisíc socketů.
Samozřejmě záleží na tom, kolik ze socketů je aktvních a jaké přesně operace provádějí. Tedy co přesně server s příchozími XMLky dělá, jak je parsuje a jak je parsing náročný...

Nová SOA Suite 12c je konečně venku !!!

Nové vlastnosti:

The 12c release of SOA Suite positions the product as the only integration product in the market today that can support all major ongoing technology trends: mobile enablement via major REST & JSON improvements throughout the suite, cloud integration via the new line of cloud adapters and Internet-of-Things with Oracle Event Processing providing the impedance matching layer between devices and enterprise systems. While other vendors may boast similar claims in high-level positioning documents, Oracle goes beyond the hype by delivering tangible features to back up these assertions in SOA 12c.

In addition to these, SOA Suite 12c includes hundreds of new features, based on years of collaboration with our large customer base: a single developer installer (that includes weblogic, SOA, JDeveloper, Enterprise Manager and Java DB), new JDeveloper-based design time environments for Service Bus and Event Processing, completely redesigned modern web console for Service Bus, streamlined Enterprise Manager dashboards, new application adapters (SAP, JDE, ...) & technology adapters (Coherence, MSMQ, ...), debugging and testing capabilities in JDeveloper, templates, a powerful scheduling engine, new B2B features such as streaming support for large payloads and enhanced end-to-end monitoring in SOA for healthcare. Also, to support the industrialization of SOA and web-scale requirements, you will find many improvements in startup time and memory footprint, simpler tuning options and more efficient dehydration store management (including auto-purging). Finally, special attention has been placed on the upgrade experience from 11g to 12c, ensuring that customers can uptake the new release without any business disruption.

Zdroje informací:

• Oracle SOA Suite 12c - video series (incl. videos on upgrade 11g->12c)
  
• Oracle SOA Suite 12c - podcast series
• Oracle SOA Suite 12c - datasheet
• Oracle SOA Suite 12c - whitepaper
  
• What's new in Oracle SOA Suite 12c? - whitepaper
• Managed File Transfer 12c - datasheet
• FY15 Q1 SOA salesplays
• SOA on the new Oracle Streams educational channel

Další info viz oficiální tisková zpráva.

Upgrading Oracle SOA Suite to 12c

Videosérie (v angličtině) na YouTube, popisující jednotlivé fáze upgradu SOA Suite 11g na 12c.

Memory footprint na WLS 12c vs 10.3.

Někteří uživatelé, kteří plánují přechod z WLS 10 na 12c, si myslí, že vyšší verze Weblogicu bude určitě potřebovat i více paměti, oproti generaci předchozí . A ptají se, s jakým navýšením by měli přibližně počítat.

Myslím, že spotřebu paměti můžeme rozdělit do dvou hlavních oblastí:
- paměť, kterou alokuje a využívá vlastní Weblogic kontejner
- paměť spotřebovávaná aplikacemi

K tomu, abychom zjistili vlastní režii Weblogicu, stačí spustit "prázdný" (bez deploymentů aplikací) managed server verze 10 a 12c. Poté, co je spustíte, proveďte pár full GC a pak se podívejte, kolik paměti každý z nich alokuje. Moje zkušenost je taková, že 12c měla vždy o něco nižší footprint, než 10ka. Zkusil jsem 12c spustit s pouhými 50MB (což samozřejmě nedoporučuji), a běžela, byť samozřejmě s mnohem vyšším počtem GC.

Pak je třeba nasadit aplikaci, (např.) Grinderem nasimulovat nějakou zátěž a znovu porovnat spotřebu paměti a podívat se na průběhy GC. Na základě těchto informací se pak můžeme pokusit poladit JVM pomocí odpovídajících parametrů. Potřebná nastavení JVM se totiž neodvíjejí ani tak od verze WLS, jako spíše od potřeb konkrétní aplikace a jejího využití různých funkcionalit serveru.

Design WLS domény pro "velkou" aplikaci

Dnes mi v mailu přistála zajímavá diskuse o architektuře WLS domény pro klíčovou aplikaci. Řeší se v ní v podstatě rozhodování mezi dvěma možnostmi: je lepší pár nadupaných serverů, nebo více menších?
Autorem odpovědi je Will Lyons a naprosto s ním souhlasím.
Jsem línej to překládat, takže pastuju originál:


> We are evaluating design of new weblogic domain which we want to be
> created as our servers are reaching EOL. Based on our requirements
> following two approaches were finalized.We want to know from you the
> pros and cons of having these designs.
> 1.)All managed servers are hosted on 3 boxes which have 140GB RAM each
> box(including OS) and it is completely occupied.
> 2.)All managed servers to be distributed across boxes which have 20GB
> at max(including OS).(Effectively in this case in order to make it 140
> we need 7 boxes,multiply it by 3 to get 420 effectively which makes
> the value to 21).

...

My response would be:
- Your question implies that you have a single domain/cluster with at
least 20, or 40, or 60, or 80+ managed servers with XGB of memory per
WLS managed server process.   Please confirm/deny and clarify this at a
minimum.
- Since your question implies a cluster/domain with at least 20 managed
servers, this suggests a large and therefore an important
configuration.    To obtain a better answer to your question, you should
compare the details of the current configuration with the alternative
projected configurations.   Comparing alternative at this level of
detail is more likely to identify potential issues:
     - How many domains
     - How many clusters/per domain
     - How many WLS managed servers per cluster and per domain
     - How many apps/WLS managed server
     - For apps being deployed in the same managed server, is this a
deliberate choice, and are there specific requirement that they be
deployed in the same server
     - How much memory/WLS managed server
     - How much memory is available on the physical server for WLS
managed server processes (after use of memory by OS and other software
processes running on the physical server)
     - What version of WLS, OS, JVM and are they all supported
     - How are you/will you spread these domains/clusters/servers/apps
across the servers in your current and future alternative configurations
     - Are you/will you use of multicast vs. unicast messaging for your
clusters
     - Are you/will you use the WLS Admin Console for
monitoring/managing domains in production
     - Do you have any evidence of any capacity limits or bottlenecks in
your current system or in the projected system(s)
- Having said the above:
     - It seems likely that a "21 physical server" configuration would
be sub-optimal (too few WLS managed servers per physical server and/or
too many managed servers per domain, and/or too many physical servers
per domain)
     - As a rule of thumb, there will be less network traffic when
running a given WLS configuration on fewer physical servers with greater
processing capacity.  So the 21 physical server configuration has more
risk for network bottlenecks.
     - You should consider the HA considerations (impact of planned and
unplanned downtime on WLS application availability) based on the number
of physical servers you select.  For example, is 3 servers enough?   It
may be.
     - Your question implicitly assumes that the [(WLS application
processing capacity)/(GB of memory on the physical servers)] is a
constant across all the physical servers you are evaluating. This
assumption is probably invalid or overly simplistic.

Velikost Java heapu

Pokud je na serveru nastavena velká velikost heapu, např. 8GB, je dobré popřemýšlet nad jeho nastavením. Pokud totiž použijeme doporučované nastavení ms=mx, nebude tato oblast paměti poté, co JVM zaplní heap, použitelná pro jiné aplikace.

Pokud použijeme konfiguraci, kde se ms != mx, vstupuje do hry faktor reserved vs commited heap. Nastavíme-li např. ms=1G a mx=8G, pak bude oněch 8G pouze rezervováno (virtuální paměti) a alokován bude pouze 1GB (fyzické paměti). JVM pak bude při provádění GC provádět změny v alokaci fyzické paměti, může např. provést resizing heapu z 1GB na 2GB a alokovat tak další 1GB z oné 8GB rezervace. Takž pak bude mít rezervováno 8GB a 2GB komitováno.

Nevýhody spojené s velkým heapem jsou:

• Nevyužívá optimálně paměť serveru
• Pokud by měl být vyšší, než je fyzická paměť na serveru, dojde samozřejmě k pagingu a řádovému zpomalení odezev systému

Velikost heapu by měla být nastavena zhruba tak, abychom snížili počet full GC cyklů a jejich pauz, aby server "neškytal" :). Pokud máme k dispozici deterministický GC, můžeme jej naladit tak, aby byla frekvence GC co nejnižší a zároveň pauzy co nejkratší.

Podpora Javy 8 na WebLogicu

Dle lidí z Product managementu v Redwood Shores plánují podporu osmičky následovně:

- Releasy nižší než 12.1.3 nebudou s JDK8 nikdy certifikovány. Změny v produktu by byly dalekosáhlé a tudíž spojené s náklady, za které se backport nevyplatí dělat.

- Ani WLS 12.1.3. nebude v době svého uvedení na trh (tj. asi v polovině letošního roku) certifikován. Dojde k tomu až později, ale pouze u WLS. Další FMW produkty (např. SOA 12.1.3.) však s osmičkou certifikovány nebudou.

- Prvním releasem, dodávaným a certifikovaným s JDK8 bude až 12.1.4. Tímto releasem bude také ukončena podpora JDK6, který s ním již nebude certifikován.

Videa o Weblogicu

Na českém kanálu, věnovaném WLS, jsou momentálně k dispozici tato videa:

• WLS Maven plugin: prezentace a ukázka praktického použití pluginu

• Continuous integrace a buildy s Hudsonem

• Admin port a Side by Side deployment: prezentace a ukázka

• FastSwap tříd: prezentace a ukázka

• Sdílené knihovny, Filtering Classloader a Classloader Analysis Tool

• Demo Classloader Analysis Toolu

Implementace WebSocketu v nadcházejícím WLS 12.1.3

Ve verzi WLS 12.1.3, která by měla být uvedena za pár týdnů, je integrována Open Source referenční implementace WebSocketu 1.0 zvaná Tyrus. Jedná se o verzi 1.3, což je předposlední stable release tohoto projektu. Díky tomu bude možné vyvíjet aplikace využívající standardní WebSocket 1.0 API, tak jak je specifikováno v JEE 7.
Pro zachování zpětné kompatibility bude ve WLS 12.1.3 a několika následujících releasech WebLogicu podporováno i WLS 12.1.2 WebSocket API, poté bude jeho podpora ukončena a bude z WebLogicu odstraněno.

Aplikace na WLS nebude moci využívat obou implementací WebSocketu, bude moci používat jen jednu z nich. Na jednom serveru však budou moci být současně nasazeny různé aplikace, využívající různé implementace WebSocketu.

Kromě toho bude WebLogic 12.1.3 obsahovat WebSockets Emulation klienta, díky kterému se bude možno vyhnout nekonzistentním HTML 5 implementacím na straně browseru a serveru. Na straně WebLogicu bude možno emulaci konfigurovat pro každou jednotlivou aplikaci zvlášť. Díky tomu si bude server moci v situacích, kdy není možné použít WebSocket connection napřímo, nastavit s různými klienty různé transportní mechanismy.

Dalším typem transportu, podporovaným ve WLS 12.1.3., bude HTTP long-polling transport. Na straně klienta bude k dispozici malý JavaScript klient (orasocket.js), který zajistí sestavení a správu tohoto long-polling spojení. Vývojáři budou moci na straně serveru nadále používat standardní WebSocket API, a na straně klienta HTML5 WebSocket JS API/objekt. Přenos datových paketů, ošetření lifecycle eventů apod. bude zajištěno transparentně pomocí long-polling transportu.

Český Youtube kanál o WebLogicu

Protože představit a předvést nové či zajímavé vlastnosti WebLogicu všem uživatelům osobně není v silách jediného smrtelníka, rozhodl jsem se pro vystavení přednášek na Youtube. Přitom bych chtěl u představovaných funkcionalit držet následující schema:
- v prvním kroku formou prezentace představit a popsat danou problematiku
- v druhém kroku pak praktická ukázka / demo

Jako první jsem zvolil problematiku použití Mavenu na Weblogicových projektech. Weblogic Czech kanál je vám k dispozici zde.