SOA Refactoring Best Practices

• Get business buy-in
• Train architects, developers, and business analysts in SOA best practices
• Establish a center of excellence that is staffed with cross-functional architects and business analysts with strong technical, communication, and business expertise. This center should foster a business-technical feedback loop and provide cross-organizational coordination. It should also publish design principles, guidelines, best practices, patterns, and templates, and centralize architecture and standards for federated implementation and management. The center markets services and promotes reuse, manages assets, and provides a portal for communication within the organization.
• Use SOA for evolutionary growth of agile IT. Related benefi ts of SOA are incremental development and deployment of business applications, reuse of business components in multiple experiences, and low-cost assembly of some new business processes.
• Plan for shared infrastructure cost recovery, metering, and charging for services.
• Fund shared-services infrastructure, remembering that return on investment is realized in the long term rather than in the short term. SOA is strategic solution with solution realization for tactical problems. Business units share the infrastructure and leverage common investments.
• Implement data services early.
• Use a business-service perspective for selecting and implementing coarse-grained services. Business processes with high maintenance and operational costs are ideal candidates for the benefi ts of SOA.
• Follow the recommended implementation path shown in the SOA project type matrix: Start small with a pragmatic use case, plan ahead, grow SOA infrastructure, and add applications/projects in an evolutionary approach.
• Educate support groups. The network-centric, policy-based, distributed nature of SOA-based applications requires IT support and operations groups to understand the differences between traditional applications and SOA-based applications. Support and operations groups need to understand and learn the new administrative tools for the SOA platform and services-management vendor products.

SOA Refactoring and Middleware

"Architecturally, one of the hallmarks of most ESB solutions is messaging-centric integration, which embraces and interfaces older, proprietary MOMs with the emerging world of SOAP-based Web services. In addition, ESB environments are often distinguished from legacy middleware approaches by their superior architectural flexibility, supporting diverse multipoint messaging Hows such as hub-and-spoke. decentralized and peer-topeer with equal agility. By contrast, legacy MOMs primarily support peer-to-peer messaging patterns, while traditional integration brokers-such as Microsoft BizTalk Server- focus on hub-andspoke integration."

"As ESB functionality becomes ubiquitous in application platforms, pure-play ESB middleware vendors will struggle for survival. Today's ESB middleware market segment will fade away, absorbed into the SOA platforms that will dominate all distributed environments. ESB- enabled SOA platforms will dominate, and also accelerate the decline of today's separate ESB middleware market. The rest of this decade will see ongoing acquisitions, mergers and consolidations among platform and middleware vendors. In particular, Sonic, Tibco, Cape Clear, PolarLake and Fiorano. though currently positioned well in the ESB space, won't survive long unless they partner or merge with SOA platform vendors."

SOA Refactoring and Mainframes

• File transfers - transferring data files between the mainframe and the other computers on the distributed system
• Call to programs (transactional or batch) - executed in the mainframe environment using proprietary access.
• Use of stored procedures and other devices built into DBMS (triggers, warnings, etc.) - data processing is taken over by the DBMS engine itself. A duly authorized transaction (or more usually a program), in the mainframe environment, performs a call to a stored procedure or causes execution of a trigger.
• Data replication to DBMS used on open systems - extracting data managed by a DBMS on the mainframe and copying it logically (by calling transactions) into another environment.

In his article, SOA: Refactoring Mainframe Applications into Dynamic Web Applications, Jeff Hanson writes:

"Typical mainframe systems expose information using a two-tier architecture consisting of dumb terminals that present the results of business logic executed by the mainframe. Most conventional integration efforts revolve around screen-scraping. Screen-scraping software electronically "reads" the information from a mainframe terminal screen, letting businesses replace hard-wired terminal interfaces with Web-enabled thin clients. However, that form of integration refactoring affects the presentation only, it doesn't help expose business logic in a form that can be easily reused and/or represented in different ways. A better way is to let the presentation tier handle application-specific UI generation and the business tier factor the legacy routines into logical business services."

SOA Refactoring and Web Services

SOA Refactoring and Security