Webinar: Rockwell Collins SOA Review
Watched this webcast on http://www.ebizq.net.
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.
| Quote: |
| • Shawn Fergason • SOA and Security • Rockwell Collins - Aviation Sector - Communications ($3.4B) • 6:00 - SOA Drivers ………….○ Increasing demand for information from customers ………….○ Started w/ Portal ……………………..§ Content framework ……………………..§ Security framework ……………………..§ Single point of access ……………………..§ HOWEVER, bad reuse. Manual data interchange. This drove SOA for them. • 11:30 - SOA Router Or Not? ………….○ Peer to Peer or not ………….○ Choose central ……………………..§ Central authority models ……………………..§ Schema validation ……………………..§ Encryption treatment ……………………..§ Single focal point for SOA calls ……………………..§ Key enabler to extend services out to partners w/o compromising security. Put in XML gateway (inspect traffic). Behind DMZ (so firewall in front of this) but infront of intranet. • 15:45 - How Network Infra Overcomes Blindspot to XML ………….○ Layer 3-7 can’t see and act on XML ……………………..§ Firewall (no deep packet inspect, no layer 7) ……………………..§ Web App Firewall (not SOAP/XML capable) ……………………..§ Generic Reverse Proxy (way too passive - like firewall) ……………………..§ SSO - Can’t review payload traffic ……………………..§ Application SDKs - No reuse, lack flex, lack consistency in policies, not heterogenous ……………………..§ …………………………………□ Resource demanding: Auth, encrypt, decrypt, validation, sig processing, compress/decompress …………………………………□ Cant control audit, auth, change management of svcs • 20:00 - Implementation Constraints ………….○ Rapid implementation requirements ………….○ Application layer security ………….○ Service Protection Requirements (Denial of Service, Payload Threats, Service Theft - valid users). ………….○ Services Up 24X7, Schema validation, high availability / load balance (fail over) • 26:00 - SCM Huge Interest in SOA ………….○ Repair process (compliance - contracts) ………….○ Supplier integration (real time delivery eta on WIP material) • 28:00 - Infra ………….○ Before SOA Router ……………………..§ DMZ (portal UI here) ……………………..§ Partner Network zone (portal middle tier, AD) ……………………..§ Data Center (web services) ………….○ After ……………………..§ New path from DMZ to XML security gateway and Data center (bypass middle partner) • 31:30 - Estimated Savings ………….○ 1st two projects saved $70k (2-3 months). ……………………..§ Had forecasted years for payback (10-12 services in a year was forecasted). Slow pace. ……………………..§ Found two projects that had shared services needs … lead archs, using SOA, moved to a shared service infra for both teams ……………………..§ Very hard savings (had costed out another angle) ………….○ Continue to see similar results • 34:00 - Focusing on SCM Next ………….○ Focused on Repair Services (R&D Driven). Not demanded by SCM group. Working w/ key partner ready for system to system integration. ………….○ Order status sharing (today manual via portal) ………….○ Want to replace EDI capabilities (DSSI opp in pipeline is same thing) • 36:00 - Recommendations ………….○ Select the pilot project to leverage (otherwise strategy stays on shelf) ………….○ Stakeholders - Business / Tech Evangelist • Q&A ………….○ SSL Wasn’t Enough? Insufficient for them. Inspect messages and insure it matches expected schema’s and perform authority checks. ………….○ XML Gateway Policy Based? May move to re-writing (right now policy based) ………….○ Middleware done by ESB? No. ………….○ XML Gateway get pierced by DMZ intruder? No. Communication for traffic in portal is treated different (so not authorized packets get hammered out) ………….○ How decide on vendors to enable? Won’t give vendors selected. Evaluation criteria most matched technically. Really came down three things (1) price (2) key long term growth for the vendor (3) partner that would provide good support in implementation. ………….○ Any ESB products considered? No. Watching that market. Evolving. Don’t see the need right now. ………….○ Back end systems had services? Had a combination … SAP (not web services) and custom web solutions (were service enabled). Built a tier to talk w/ SAP via web services. Current version not but will that way. ………….○ SOA built around how to secure Internally? Yes demand started there for us. ………….○ SAP’s ESA model considered? No. Not mature enough. Exchange infrastructure piece is being considered. Some pieces augment what they have done. Nothing in SAP is a replacement. Spent a lot on SAP. Security issues. ………….○ Process for controlling service interface definitions? New to this so not @ 100’s. Do have a SDLC. Look at existing services in design of new systems (reuse / augment). Key concern is keeping services that were extendible (open). ………….○ Followup on versioning, how approach that? Assume you are talking about the versioning of the definitions of the schema’s. Struggling with this. Done some work checking in the policy checking stuff into the source system. ………….○ Many decision factors on gateway were looking at ways to secure message traffic (multiple msg layers, types, encrypt/decrytp, multiple auth sources ie ldap, ad, radius). Not hot on transforming message in gateway initially but became crucial. Partners can’t always produced file needs. ………….○ Utilizing web service mgmt tools? No. Looking at how manage changes in policy. Evaluating time when need is valid. Right now size isn’t there to validate instrumentation. |
Subscribe
