46 lines
7.1 KiB
Markdown
46 lines
7.1 KiB
Markdown
Architectural style: what is and isn't allowed in an architecture. There doesn't have to be ONLY one in a system. For example, we mix MVC and layering. If we use layering, that doesn't mean every piece of code we write has to fit into _this_ style. When thinking about architecture, think about them as ingredients to a meal. Service Oriented Architecture is an architectural style. SOA is likely to be founded on messaging. Architecture is what architects do. Architects are those who do architecture. :-) **Bus & Broker Commonalities**
|
||
Attempt to handle spatial coupling (but in very different ways). **Broker Architectural Style**
|
||
Also known as hub and spoke. Another name: mediator pattern. Lots of apps talk to the broker. The broker mediates communication between the applications. Broker was introduced to save the integration between a large number of applications to all the other applications. Instead, all applications integrate with the broker and the broker figures it out from there. Problem: the more things you integrate, the more complex and loaded the broker becomes. The need for scaling presents itself. Examples:
|
||
|
||
- Biztalk
|
||
- Websphere
|
||
- MS SQL Service Broker
|
||
- CORBA
|
||
- UDDI (concept was service discovery)
|
||
Challenges
|
||
Not really tech itself, but what it was used for. Broker becomes bloated as number of integrating apps increases. Advantages
|
||
Generic engine to use to communicate between applications.
|
||
Central management of communication. IT can look at what's going on. Disadvantages
|
||
Embodies 11th fallacy: business logic can and should be centralized SOA was a reaction to the problems caused by highly-centralized business logic (brokers). Brokers work well for a relatively small number of integrations. **Bus Architectural Style**
|
||
Very simple, older style thank broker. Sources produce events, they go to sinks. That's it. Baseline assumption was that the things outside the bus were going to change. The assumption of the broker was that things outside the broker would _not_ change. PCI bus and ethernet are bus architectural styles. Internet was built around this. Smart endpoints, dumb pipes. This allows the endpoints to change a lot. This was all hardware implementations of bus topology. Software buses try to do the same thing.
|
||
|
||
- Everything on the bus needs a name
|
||
- Just like an ethernet card, every component on the bus needs a bus
|
||
Some new ESB products that are actually brokers: WebSphere, Mule, Sonic Software Bus techs: NServiceBus, MassTransit, Rhino Service Bus
|
||
Tibco Rendezvous, RabbitMQ, Qpid JGW's bus setup is hub-and-spoke in physical topology, but logically still a bus (dumb pipes, no single point of failure). RabbitMQ and ZeroMQ were created trying to solve the problem of quick message transfer rather than super-reliable message transfer. Their motivation is speed over reliability. Difficulty: much more difficult to design distributed solutions than centralized ones. When researching technologies, make sure to discover the reason they were created and the space out of which they came and which problem they were trying to solve (or even which aspect of which problem they were trying to solve). **SOA Building Blocks**
|
||
Tenets of Service Orientation:
|
||
|
||
1. Services are autonomous (single responsibility--high cohesion)
|
||
2. Services have explicit boundaries (low coupling)
|
||
3. Services share contract & schema, not class or type (platform coupling)
|
||
4. Service interaction is controlled by policy (runtime elements to get things to talk to each other)
|
||
Those who came up with these were not coming up with something new. They were looking back at old stuff and seeing what worked. What is a service?
|
||
A technical authority for a specific business capability. Nothing is "left over" after identifying services. You can't say "the UI is over here and talks _to_ the services". The UI code (in this case) was written for a reason to serve some business process and therefore should below in one of the services. Everything must be in some service. What is NOT a service:
|
||
|
||
- A service that only contains functionality: this is a function!
|
||
- A service that has only data is a database, not a service. (CRUD stuff). If all you have is a CRUD service, all you've done is create a proxy for a database.
|
||
This was the message of object-oriented programming: encapsulation. SOA takes it to the next level: encapsulate business domains. If you want your services, keep them in separate code repositories. It's hard to cross those boundaries and that's good. Client platforms are not out-of-scope for services. Therefore, UI components can belong to services. When we say that a service is the authority for a particular business capability, this may span several systems. SERVICES ARE NOT SYSTEMS. UI composition allows you to put service-oriented components in different services. A pricing component could come from the marketing service and the order component could come from the sales service. SOA aims to divide up business responsibility to make it easy to add business features later one without changing a lot in the existing systems. You don't always want to model the way the business currently operates. There is usually a lot of overlap and disagreement on what requirements are. **Homework:**
|
||
Example problem domain: hotel management system.
|
||
Marriott in Dallas. A single hotel.
|
||
Functionality to book a room.
|
||
Search screen: check-in, check-out boxes. _Frontend experience_
|
||
Use case #1: availability by in/out dates. What is the price? Can be multiple types of rooms. If multiple room types are available, show all and their prices. don't look for complexity around pricing--just assume list price. Use case #2: Making a reservation. Guest information (first, last, etc), credit card information for securing reservation. User clicks book now. One guest, one room, one reservation. _Hotel experience_
|
||
Use case #3: check-in process. Finding reservation based on guest's name (what type of room, how many nights). Next, finding room to put guest in. Use case #4: check-out process. Simple for guest. From hotel's perspective: this is last night of reservation, print up bill on that night. Verify you've left the room. Total charge (finalizing the charges)--did you trash room? Did you eat minibar food? Ultimately, charging card for appropriate total? Edge cases to think about:
|
||
|
||
- Guest side: One room left, two people are trying to book it? How to preserve consistency? Overbooking is OK, but infinite overbooking is not allowed!
|
||
- Hotel side: No show. Reservation made, but guest didn't show up. Probably a guest period.
|
||
Objective: find service boundaries. What are the services? What data are they responsible for? What parts of the UI are they responsible for? What events do they publish? What events to they subscribe to? What do they do with the events? How do they collaborate with each other to implement the flows discussed? Hints:
|
||
|
||
- Be careful with naming services
|
||
- Consider using stand-in names for services (red, blue, green--colors), then name them at the end.
|
||
WHEN DOING DESIGN, DEFER NAMING AS LONG AS POSSIBLE! |