310 likes | 329 Views
SOA Blueprints. Learning Best Practices and Sample Applications for SOA. Steve Wilkes Senior Middleware Maven 7 THE MIDDLEWARE COMPANY 09.22.2004. AGENDA. Why are we doing this? What are the goals? SOA Concepts The Reference Example The Specification Implementations.
E N D
SOA Blueprints Learning Best Practices and Sample Applications for SOA Steve Wilkes Senior Middleware Maven7 THE MIDDLEWARE COMPANY 09.22.2004
AGENDA • Why are we doing this? • What are the goals? • SOA Concepts • The Reference Example • The Specification • Implementations
Why are we doing this? • SOA is the new old thing • The concept has been around for years • The practical realization has only recently materialized • J2EE had the PetStore • Initially a Patterns application without specification • Very successful as a learning tool • In some ways too successful – people learned architectural anti-patterns in addition to the technology that was shown • SOA needs a PetStore not The PetStore • Demonstrating SOA best practice requires many applications • Industry focus on (inter) communication not eCommerce
What are the goals? • Part of a long term project, SOA Blueprints aims to: • Define a baseline standardized set of enterprise applications • Focus on SOA principles • Highlight SOA design patterns and best practices • Encourage SOA adoption • Be industry agnostic • Be applicable to as many organizations as possible • The specification will lead to: • An agreement on SOA terminology • A reference open source implementation • An implementation by vendors • Additional modules with particular industry focus
SOA Concepts • SOA Much More Than Web Services • Common SOA Terms • Patterns • SOA Platform Requirements • Standards • Glossary
SOA Much More than Web Services • Service definition does not include protocol or wire format • How many protocols in your organization? • WSDL could be the key • Service providers should concentrate on the service • Service consumers just want to use the service • It’s the SOA that allows providers and consumers to communicate
Common SOA Terms Common SOA Terms(the specification includes those highlighted in blue)
SOA Terms (cont) • Synchronous and Asynchronous Services • Component Services • Data Services • Composite (Business) Services • Conversational (Workflow) Services • Publish-Subscribe Services • Service Brokers • Exception Handling And Compensating Services • Service Security • Interception And Extensibility • Interoperability
SOA Patterns Initial patterns will include: • Service Registry and Static Binding • Service Registry and Dynamic Binding • Service Broker • Distributed Service Broker • Service Bus • Distributed Service Bus
SOA Anti-Patterns • Overly granular business services • Remote access to local services • Overuse of XML • Use of loose coupling where tight coupling is required
SOA Development Requirements Target implementation environments should provide: • Definition of services independent of implementation, location or use • Implementation and hosting of services as a provider • Location and usage of services as a consumer • Assembly of services from other services and business rules • Support for synchronous, asynchronous and conversational services • Orchestration of application presentation built on services and rules • Automated data transformation between disparate data structures • Provisioning of local and remote services • Support for simulating, testing and debugging of services
Standards Standards being considered for inclusion include: • WS-I • BPEL4WS • WS-Security • WS-Notification • Jini • WSRP • WS-Manageability
Reference Example Common Enterprise Applications(the specification includes those highlighted in blue)
The Specified Applications • Based around fictitious enterprise - GeneriCo • A distributed enterprise wide security mechanism • An employee self service portal providing: • Authentication • Organization Browser • Task List Management • Expense Reporting • Employee Reviews • A Product data service • Some payroll & supply chain functions as required by the specification • A basic HR application for management of employees and departmental structure
The Security Mechanism • Provide security for: • New Applications • Legacy Applications • Provide indentity management • Automate employee security
Employee Portal Authentication • Utilizes Security Adaptor Services • Provide Login / Logout Capabilities • Enable Password Change • Provide roles based access • to pages • to portlets • to actions
Employee Portal Organization Browser • Search for Employees • Browse Departments • Get Department Details • Get Employee Details
Employee Portal Task List Management • View Task List • See Task Details • Add Tasks • Update Tasks • Link to Expenses • Link to Reviews
Employee Portal Expense Reporting • View Report List • See Report Details • Add Report • Update Report • Authorize Report • Pay Report • Utilization ofPay Roll Services
Employee Portal Employee Reviews • View Review List • See Review Details • Add Review • Update Review • Validate Review • Add Ratings • Finalize Review • Utilization ofPay Roll Services
Product Data Services • Two Product Databases • Different Schemas • Want single dataservice to accessproduct information • Enable categorylisting • Enable productlisting • Needs to generate unique keys • Add missing information • Query across sources
Message Definition Messages are defined within the specification in a platform agnostic fashion:
Process Definition Processes are also defined in an agnostic way:
Implementation Guidelines • Specification is platform agnostic • Database schema will be supplied • WSDL will be provided for all services • Service testing will be provided by PushToTest • Transport protocols must be adhered to • Use of Portal server is recommended • Web design should follow guidelines • Standards should be adhered to where stated
Vendor Implementations Currently have commitment from the following vendors to provide implementations of the reference example: • BEA Systems • Diamelle Technologies • IONA Technologies • Microsoft • Oracle • Pramati • Sun Microsystems • Rogue Wave Software
Open Source Implementation • Looking to build open source team • Currently have a number of committed members • Technologies we’re hoping to use include: • Hibernate for persistence • Spring as a lightweight container • Axis for web service provisioning • eXo as an enterprise portal • Twister as a BPEL4WS engine • Maven for build and management • Will become reference implementation for SOA
Possible Interesting Things • An additional 10 or so vendors want to enhance the spec • Service management (Qos) an interesting add-on • Jini message board talking about an implementation • Some vendors considering CORBA implementation • Would like to include Mobility component • WSRP seems natural extension to Portal specification • Including more standards is a must • Launching an SOA Blueprints Wiki very soon • Open Source Implementation home announced soon
Next Steps • Q & A • Goto soablueprints.com • Download the specification • Send us feedback • Get involved in open source implementation
TheServerSide.com TheServerSide.NET MiddlewareRESEARCH.com Steve Wilkes Senior Middleware Maven7