Tim Bauer’s Running Thoughts

Watched this in that there is an ongoing market swell in all technology stacks around SOA, ESB, BPEL, etc. Go here:

LINK

or hit http://www.jboss.com/services/online_education and look for SOA Part II. That said this webcast is definitely worth watching for a variety of reasons.

1. Burr has clarity. Burr is thier evangelist on the technology stack and he does a great job pulling it all together (what it is, why to use it, how JBoss does it, etc). More so than other vendors I have seen speaking on the topic. So just for that you should watch (as many of us also don’t have clarity — i wont name names).
2. The Power of Open Source a BizTalk Competitor overnight? Later in the webcast they demo’d thier beta ESB product and its pretty robust. Will be available in q4 of this year. The key “AH HA!” was that thier code base came from an insurer that donated thier custom ESB to JBoss. DONATED. Welcome to the next generation of software. Companies build out complex CUSTOM frameworks and then lobby to get it adopted (for free) into the overall community champion (JBoss).
3. Nice BPEL Overview Alot of clients are starting to jawbone on BPEL. GE for example. Keep in mind that BPEL is, in short, a variant of what BizTalk does. Enables orchestrations etc. Rather impressive demostration of how that integrates w/ Eclipse (beta designer granted but BPEL spec isn’t formal to q4 - nov - anyway) with a similar look and feel to MSFT VS and/or BTS Designer. I was suprised with how close it was in look and feel.

In summary, it is clear that JBoss is moving faster than I thought possible. Powered by the contribution of the community and large code base donations I think they will make a strong run at maintaining thier hold on current clients from the MSFT push while stealing other clients from both camps (BEA/IBM, MSFT) for a Total Cost of Ownership play. Will be fun to watch over the next few years.

Here are my detail notes for those amused

Quote:
• Bruce Sutter - Tech Evangelist for JBOss
• Agenda
…………..○ Catalysts
…………..○ WS-*
…………..○ BPEL
…………..○ Service Bus
• 2:00 Catalysts
…………..○ Agility
…………..○ M&A
…………..○ Current Hundreds of technologies
…………..○ Users might be many roles
……………………….§ Data scattered across enterprise
……………………….§ EVPs Budgets create fragmentation
…………..○ Portals spawning (6 per BU, 10-12 Bus per org)
……………………….§ Customers want single point of entry
……………………….§ B2B, B2C, etc
…………..○ Swivel Chair Integration
……………………….§ Fax, Web, Call 4 Report, Web Service,
…………..○ JBoss SOA Engines
……………………….§ jBPM. Process driven. Human or batch
……………………….§ jBPM BPEL. Unique orchestration for web services (Have to have WSDLs). All communication to BPEL process is SOAP call. Invoke Ruby, etc.
……………………….§ Rules Engine. Production Rules Engine.
……………………….§ J2EE / Java EE 5 Services (JMS, EJB, WS, Hibernate JPA)
……………………….§ JBOss App Server (Swing, Browser, .NET, Batch, External)
• 11:30 - WS-*
…………..○
…………..○ Use JIRA to vote on functionality
…………..○ WS-Eventing.
…………..○ WS-Security.
……………………….§ Before, had a login process to get security token. Encryption via SSL (tying to HTTP transport). So if you go to ESB you might have segments that don’t support HTTP.
…………..○ WS-Addressing (JSR 261)
……………………….§ Before, endpoint was in HTTP Header. Take SOAP to server and goto post command parm at end. Problem multiple stopping points not easy (Service BUS enables this)
…………..○ WS-Policy.
…………..○ MTOM
…………..○ WS-Context. Maintain state conversations. Like a cookie.
…………..○ WS-Coordination. Business activity for long running compensating transactions.
…………..○ WS-AtomicTransaction. Two phase commit
• BPEL
…………..○ JBOSS resources on committee. November 2006 will get ratified.
…………..○ BPEL is part of jBPM. Beta 1.1
…………..○ BPEL fixes WSDL
……………………….§ Creates ordering.
……………………….§ Concurrency
……………………….§ Choreography w/ external entities
…………..○ XML, WSDL API to it, Can consume other WSDLs, allows for state, allows asynch of other web services (forking) and rejoin
…………..○ Key words -
…………..○ BPEL file overview - import, partnerlinks (anyone interacting with in/out), sequence tag — receive, assign, invoke, replay, flow, etc.
…………..○ 21:00 — DEMO - Eclipse - BPEL Designer (Alpha)
……………………….§ He will send you doco if asked to setup a basic model
……………………….§ Very similar look and feel to BTS (MSFT)
……………………….§ Task definition deploys par file to app server.
……………………….§ Example of a form doing BPEL (invoke a BPEL process). Add webservice to form. See WSDL file w/ BPEL process. Code is basically a call to the PROXY.
……………………….§ There are differences in BPEL spec and Designer (again he can send doc to cross chasm for now)
…………..○ 26:00 - JBoss ESB Beta 1
……………………….§ Came out just last week
……………………….§ Rosetta code base donated by a Large Insurance company. Running thousands of transactions. 3000 employees, 40 locations, 2 million customers.
……………………….§ Donation June 2006
……………………….§ Beta 3q 2006
……………………….§ First GA is 4th 2006
……………………….§ ESB - Listeners and Actions provide transport and message mediation
……………………………………□ Listeners - Some connectors - like file, http, ftp, jms, email, soap … are avail now. Seam in front of web/portal is also there
……………………………………□ Actions - Pluggable Arch — Transform, route, security, mgmt, JBoss ESB, Service Registry, Event Log, Composition Engine (BPEL, Seam, jPDL, Scripting, Process Store)
……………………….§ Out of Box - Listeners
……………………………………□ File
……………………………………□ SQL Table Poller
……………………………………□ JMS Queue topic listener
……………………………………□ Web Service Invoke to Bus
……………………………………□ Working on HTTP Listener (REST calls)
……………………………………□ FTP / SFTP (coming)
……………………….§ Core Services
……………………………………□ Service Registry
……………………………………□ Persistent Event Repository
……………………………………□ Notification Service - Msg queue to msg queue notification of a process
……………………….§ Messages
……………………………………□ Serializable Java Objects and/or XML
……………………………………□ Transformation declarative and java based
……………………….§ Usage
……………………………………□ NOW–File System -> JBoss ESB -> File System
………………………………………………..¨ FUTURE - add notifications, transformation
……………………………………□ Message Queue - MQ Cluster - MQ
………………………………………………..¨ Same as above
………………………………………………..¨ Registering in specific transaction events .. Listen for certain events … decoupled integration
……………………………………□ Combined Usage Example
………………………………………………..¨ Multiple listeners and multiple actions
………………………………………………..¨ FTP Poll, persist msg, log, email on rcpt, transform, post to file repository. Now you can do that in ESB.
……………………….§ 36:00 - Getting Started
……………………………………□
……………………………………□ Need latest version of EJB3.
……………………………………□ There is a a JEMS Installer (gui installer that installs EJB3)
……………………….§ 38:00 - Demo
……………………………………□ Config File (listener) review
……………………………………□ Show how ESB picks up files in momements, acts on it through ESB process, and spools out. In CMD window.
……………………………………□ Email example w/ notification. 4 lines in the config file of ESB listener to get it working.
……………………………………□ Notification to JMS. Same config file for listener. Different config lines (4) to push to JMS Queue. JMX console shows the messages going through. Then you could have a bean or process respond to that message.
……………………………………□ Multiple steps in same listener (hard code or via GUI in Eclipse). File listener sends alert to queue. The listener on that queue. Show how they bat the message back and forth between the listeners and the associated code behind the listener.
……………………….§ 47:00 - Trail Blazer Demo
……………………………………□ Advanced demo of capability
……………………………………□ Customer interact w/ web or vb that hits services that hits ESB gets persisted then gets managed from there in ESB. Multiple listeners act on the single message (partner network model)

Watched this webcast on http://www.ebizq.net.

http://www.ebizq.net/webinars/archive.html

You have to signup but its free. Not a bad looking site for EAI/BPM/SOA research. I bookmarked it.

Anyway, I checked this out in light of ongoing conversations w/ clients around various aspects of EAI/SOA/etc. Wanted to hear what a $3.5B company had to say about it. The guy was very well spoken but drew long in the tooth towards the end. Still excellent detail discussion of how they setup thier infrastructure and why. Here are the keys I heard:

1. No Bus (ESB) for them (not big enough). It was interesting that they choose not to leverage an ESB (Enterprise Service Bus) to start with. They felt that thier number of services (~100) didn’t warrant it.
2. WWW –> DMZ –> FORK. Thier infra design basically boiled down to four enviroments: WWW, DMZ (app UI’s live here), PARTNER (business logic layer lives here), INTERNAL (web services live here). Prior to an SOA plan they would route service calls serially through the environments. With SOA (via an XML Gateway between the DMZ and INTERNAL) they simplified accesss and increased security. Interesting that it bypassed some of the business logic layer in the PARTNER area (I assume they redeployed that.
3. Try again SAP They are an SAP shop (as alot of our customers are) but don’t feel that SAP’s SOA toolkit was ready to be the core of thier solution. This is interesting in that alot of our SAP customers (RA, HD, Miller, JJ Keller, etc) are looking for ways to expose SAP services out to thier org … and here is one unbaised team deciding no way (rolling thier own).

A good webcast. Two thumbs up. Detail notes below.