Third day at Microsoft SOA and Business Process Conference I will attend the following sessions:
SOA Lifecycle – Enabling Agility through Grass Roots SOA Kevin Farley & Alexander West
High Availability, Fault Tolerance, and Scalability with BizTalk Server 2006 Jay Lee EBI Solutions
Effective Techniques for Handling Large Messages in Service Oriented Solutions Thomas Abraham Digineer
Configuring, Building and Deploying BizTalk Applications in a Distributed Environment Paul Gomez ThinkBox Solutions
First SOA LifeCycle:
These are SOA and developer tracks, since I have some experience on high availability, fault tolerant scalable BizTalk environment, because I made architecture/implemented for an flex worker company in Holland I very curious on this session. …
SOA lifecycle – Enabling Agility through Grass Roots
Business Rules Services
Having business rules as service (designed as exception)
Provision smart client Configuration Run from console
Security, SSL
WS-Security
Kerberos RADIUS (Secure token, pass multiple boundaries) WSE 2.0, WSE 3.0, WCF
XSD.exe (ability to serialize) XsdObjectGen, thinktecture WSCF
Contract oriented interfaces security
Service composition how to gather or aggregate services (worry about gather then, not reuse) align with use cases
use versioning
Host and Factor (WCF)
Implement composition
Choices: .Net (Inhertance), Web Services (facade pattern), BizTalk orchestration (composition pattern)
Organize by use case –> composition for performance (cache)
Hosting in an SOA asmx runs IIS not good for long-running, WCF (performance)
Shared services Enterprise Library 2.0 (AzMan)
use policy logging, exception handling
SQL Repository (Log to centralized store) –> reports
High Availability, Fault Tolerance, and Scalability with BizTalk Server Jay Lee (BI Solution)
BizTalk Farm
Role administrator
High availability concept
Farm demo
Database disaster recovery (set up log shipping)
Best Practices
Three roles (admin, developer, and analyst) Analyst is about rules and business process interact developer who builds and test it,
administrator deploy solutions environment.
What does a farm look like e.d. Role separation so developer/administrator (development lifecycle)
Concept high availability and goals
fault tolerant infra
high perform/scalability load balancing
security
back up disaster (message box or other)
Distributed architect
high availability (active/active)
Microsoft cluster service support
– sso redundancy (queuing cluster)
hardware affinity no, go
Enterprise sso secret server (passive cluster)
Scale out dedicated to specific host (scale out message box)
Deployment options: msi, batch/wmi script 3rd party Nant, BizTalk Assembly Checker (<-- good tool, remotly gac), gotdotnet SQL Agent jobs --> message active –> reset status to queued
NO MESSAGE LOSt
BizTalk Database recovery
(a) backup
– config sched back
– store file offsite
(b) log shipping
– config dest backup sql ser
(C) restore
– ..
BACKUP SERVER REMOTE LOCATION
backup logs 15 minutes
backup data every couple of hours or so (once a day)
SQL Agent
Job 15 min
BackFullUp Job check if it is run (every day)
BakckUp Transaction log
Clear up backup history
Another job DTA purge and archive
makes sure dta too large message box gets backup –> look in to this
MS BizTalk 2006schema –> logschipping scripts –> look in to this
Deployment procedures document !!! See documentation (help file)
Lee graber
In the afternoon there was a session about deployment:
Effective Techniques for Handling Large Messages in Service Oriented Solutions
Here are the notes I made:
Real life scenarios
all about large message
Asp.net
BizTalk
Problems exist everywhere even in J2EE
in-memory in DOM (like PDF)
Problems with large messages BizTalk 2004
large Messages defined
Why? is very relative : network capacity, hardware capacity (we talk messages here not files !!!)
Message over 5 Mb is LARGE
Know your services
Troubles wit large message
– latency
– bandwidth
– base64 encoding
– memory usage
– encrypt cpu
– custom coding (threading, memory …
– queue message/processing
– size/time
Redesign service
scale up/out hardware
compression
SOA purity/practically one call pass all data or split it up (complex)
streaming avoid encryption but use SSL, avoid unnecessary persistence
XSLT in memory , alternative mapper is not a good item
Scale up BizTalk 2006
multiple message boxes, SQL Server hardware
LOTS of memory
Move to win 2003 x64
Load/Stress testing before scaling
Keep data from getting to Message Box
Pipeline slice/Splice
XNOTE Stopwatch
LoadGen BizTalk
Serializations points
use messages only
persistence point
avoid mapping
create separate hosts each 2Gb memory space, each independent throlloting (biztalk send/receive)
Eliminate Message bodies tracking
ASP.NET
WSE, MTOM, WCF full support MTOM, Tool: Fiddler ASP.NET
make sure to know your services (usage patterns)
plan for future growth
choose one more approaches: hardware scaling, splitting, combining, compression, refectory services, MTOM, avoid encryption, USE LOADGEN
blog tabraham
BizTalk performance team
core team on large message
Last session of today here are some descriptive notes. Not a very interesting session, most what was being discussed is common knowlegde for BizTalk developers/adminstrators.
Configuring, Building and Deploying BizTalk Applications in a Distributed Environment Paul Gomez
agenda
config
build
deployment
Hosts
logical container
contains adapter handlers, recv loc, orch
host multiple inst more machines
mmc
runs as NT service (Host)
inst part host more server
inst different hosts on a different servers
main type’s bizt
improvises biztalk ocrh rev snd
IIS http soap
isolated host (soap recv handler)
binding functionality to biztalk hosts
Best practices hosts
different host for each functionality (security, scalability, management)
diff recv and send
separate not-trust and non-trust items (security reasons)
run two or more instances of each host of more server reliability
understand bonding performed and which host is implemented
multiple server development same config concerning hosts !!! deployment
High availability
deploy multiple server three (basic)
two BizTalk , one db (cluster I think other)
config multiple BizTalk hosts (recover/disaster)
SSO Master solid story reliable on BizTalk
Avd. deply multi serv, cluster sql, sso masyer, MSDTC, Microsoft cluster EDI cannot run it
Direct Adapter Concept
out of proces adapter, allow inline dont net code message direct in MsgBox (hown grown adapter from ThinkBox Solutions)
four biztalk adapters, two biztalk dec orch, other with other adapters, SQL Clustered, ENT SSO clusterd and MSDTC
Ent SSO
Achilles hill BizTlak server
dont restart biztalk server (cahce sso)
back up sso soon as it genreated
making master sercet server available
cluster ent sso on master secreta server
figurate out to get notifited if it fails SMTP or MOM
BizTalk Application Concept
single assembly for everything (artifacts together that belong to each other), schemas and maps –> depends on each other so together can (partition)
build/deploy strategy around BizTalk application
interface and implementation model for orchestration that reuse possibilities
Logical grouping BizTalk app
Build proces (VS.NET, set project properties, sn)
Multi Server considerations (everything’s is bound default host inst)
Bindings what is it? logical and psychical port mapping (customizing BizTalk binding files documentation)
