Java SOA Cookbook

1. Java SOA Cookbook
   
2. By: Eben Hewitt
   
3. Publisher: O'Reilly Media, Inc.
   
4. Pub. Date: March 26, 2009
   
5. Print ISBN-13: 978-0-596-52072-4
   
6. Pages in Print Edition: 742
   
7. Subscriber Rating: 4 out of 5 rating [7 Ratings] Subscriber Reviews

复制代码

1. Defining SOA
   
2. Problem
   
3. The term “SOA” is surrounded by hype, hyperbole, and generality. You want a definition that you can work with.
   
4. 
   
5. Solution
   
6. You must define SOA with some modicum of care before proceeding in order to set expectations appropriately. This is made somewhat difficult given the avalanche of hype surrounding SOA in recent years. But it can be done. There are many possible definitions of SOA. Here is my offering:
   
7. 
   
8. SOA is a kind of architecture that uses services as building blocks to facilitate enterprise integration and component reuse through loose coupling.

复制代码

1. Modeling Services
   
2. Problem
   
3. You have determined a service candidate and want to begin modeling the service.
   
4. 
   
5. Solution
   
6. Employ established architectural modeling techniques such as generalization, decomposition, and aggregation.

复制代码

1. Making a Service Composable
   
2. Problem
   
3. You want to make sure that your service is designed in such a way that it can be reused within a composition.
   
4. 
   
5. Solution
   
6. Do not tie your service interface or implementation to any specific business process. Instead, move business process-specific code into an orchestration or new process service.

复制代码

1. Designing Schema for SOA
   
2. 
   
3. Problem
   
4. 
   
5. You want to define your data types with XML Schema to use within your SOA, but Schema is so flexible that you aren’t sure how to do it. You want to follow patterns and best practices for Schema that make the most sense specifically in an SOA context.
   
6. 
   
7. Solution
   
8. 
   
9. Follow one of the Schema design patterns discussed here: Russian Doll, Salami Slice, or Venetian Blind.
   
10. 
    
11. There are several generally accepted design patterns that apply when creating XML schemas. The inherent flexibility that XML Schema affords means that it can be difficult to figure out how to start writing them in a consistent, clear manner that will give you the perfect combination of expressiveness, flexibility, and strong-enough typing. This is all aggravated when your aim is to design them for an SOA in a way that allows you both to generate to Java code and to use as raw XML.
    
12. 
    
13. Schema defines basic building blocks for defining entities: simple types, complex types, elements, and attributes. Beyond these, there are many choices to make regarding global or local types, namespace qualification, and more. Making uninformed choices at this level can crush your SOA, inadvertently limiting its flexibility. Without careful schema design, you could work very hard to make loosely coupled services that are composed using orchestrations and brokered ESBs for different domains, only to suddenly find that in reality the services in your SOA are very tightly coupled at the root because of a poor choice in schema design. A simple schema change here could force you to redeploy whole sets of service compositions.
    
14. 
    
15. But XML is at the heart of your SOA, and you want to use the considerable power of Java while maintaining the flexibility that XML gives you. You can have it both ways, but you just need to think about the ramifications of your schema design choices. In this section, we’ll look at three well-known design patterns for constructing schemas: Russian Doll, Salami Slice, and Venetian Blind. There are two others that people sometimes employ: Garden of Eden and Chameleon, which we’ll have to discuss in the following recipe because of the attractive nuisance it makes.
    
16. 
    
17. The patterns here are generally differentiated by one thing: whether or not your elements and types are globally defined. A global element or type is one that is a child of the schema node. A local element or type is one that is nested within another element or type. A local element cannot be reused elsewhere.

复制代码

1. Creating Canonical Data Model
   
2. 
   
3. Problem
   
4. 
   
5. You want to create a canonical data model for your SOA, as discussed in Woolf and Hohpe’s Enterprise Integration Patterns (Addison-Wesley Professional), but you aren’t sure how to proceed.
   
6. 
   
7. Solution
   
8. 
   
9. Read the discussion below. You may choose not to do this. If you do choose to employ a canonical data model, you probably want to have a data architect create this up-front, following a detailed analysis of your organization’s data from a master data management perspective, and before you have lots of services in place.
   
10. 
    
11. In short, your mileage may vary, but the solution is probably to define schemas local to services that reuse a separate layer of schemas, defined independently of services, at the enterprise level.

复制代码