1.Web service- Consumer and exposer both async and sync, need to design their scehema with the help of XSD(DTO), and need to design WSDL for the exposed web service, if WSDL will not be designed we can not invooke multiple operation with in a web service.
2.Mediater: Will be used for routing the request and response.
3.DB Adapter, Used for working with only, invoking query, procedure, function, Further working on this DB adapter for replacing PL/SQL with it.
4.BPEL(Business process execution language), Used for desigining business of web service either proxy or service, Validation part, Orchestration of web services will be done here, Multiple operation designing with WSDL/BPEL.BPEL is a Web services orchestration language
5.JMS Adapter, Used for publishing and consuming Messaging, will be used in async web service if requeired
6.OSB can be also used but it will be prefer to use it only when no orchestration is performed, it requieres to use only at the time of proxy generation and validation part over proxy web service.
7.Exception handling, System generated and user defined exception
SOA Advatange over Mannaul orchestration:
1.Replacing manual code with SOA components by which performance will be increased as these components are highly optimized in respect of performance.
2.Interanlly Web service interact with each other with the help of messaging.
3.Services share schema not the classes.
4.Service compatibitly is defined based on RM.
5.Easy to manage complexity, Need to focus on business.
6.Changes will not impact the consumer.
7.Reduces TCO and increase ROI on evolving systems
8.Add value to core investments by leveraging existing assets
9.New systems can be built faster for less money because
10.existing services can be more easily reused (Chappell)
11.Built for flexibility
12.Long term value of interoperability
13.Every thing will be used as a service
14.Monitoring of services is more good as we can check state and all component request/response data inside SOA with the help of EM Console
15.Guaranteed Delivery:Transactionally persist the messages to a data store before passing the message onto the BPEL orchestration engine. Each time, delete the message that was persisted prior to the previous process.
16.Message History and Audit Logs:Attach a message history to the message that lists all applications or components that the message has passed through since origination.
Design Patterns:
Error Hospital. This pattern provides exception handling as a service. To maximize process simplicity and performance, the business processes are designed as simple asynchronous or even short-lived synchronous processes. When there is an exception, messages are published to an error hospital process that then provides the necessary exception management, including human services if needed.
Many service orchestration patterns are implemented in orchestration engines such as Oracle BPEL Process Manager:
Composite Service. Combines the functionality of multiple services into a composite service and makes it available to consumers interested in it as a whole. BPEL supports this by automatically making every process available as a service that can be used as a building block to build higher-level, compound flows.
Orchestration Engine. Specifies the control and data flow associated with an orchestration explicitly, using a standard language such as BPEL that can run on an orchestration engine. The orchestration engine can provide infrastructure services such as audit trails, persistence of long-running flows, common exception handling patterns, and so on.
Service Compensation. Provides transactional support in a manner that is aligned with loose coupling, stateless services, and long-running processes.
Orchestration Instance. Creates and allows users to independently observe and manage concurrent instances of a business process.
There are a number of design patterns that Monster uses in the architecture of our integration middleware.
SOA Develloper Benefiits
- SOA’s don’t replace OO Development, but they extend the reach of the functionality.
2.SOA’s make components reusable at the business level and not the component level.
3.Application Location Transparency
4.Loose Coupling allows flexibility
5.Greater “Potential” for Re-Use
6.Think Cross Platform Re-Use
7.Developer Yellow Pages of Services – UDDI
8.Common Services Framework leaves developers to work on business logic. (Routing, Reliability)
- Industry View: Platform Independent Use
- Helps applications evolve over time and last
- Rich tools to Design, develop, debug, deploy services
Comments
Post a Comment