Практический SOA для новичка
Юлия Array передается по ссылке. Вам нужно создать копию:
julia> A = [0.0 0.1 0.2 0.3];
julia> B = deepcopy(A)
1×4 Array{Float64,2}:
0.0 0.1 0.2 0.3
julia> A[1] = 0.1;
julia> A, B
([0.1 0.1 0.2 0.3], [0.0 0.1 0.2 0.3])
Обратите внимание, что для этого кода будет достаточно просто copy, но если, например, у вас есть массив объектов, который вы изменяете deepcopy, следует использовать. [ 115]
7 ответов
I think the question has more to do with the concepts involved than the tools. Answers to the items:
- Understand and internalize bounded context. Keeping unrelated pieces separate its important to get real reuse on different services. Related technologies won't help you on this, its you that separate the app in appropriate contexts, which you can appropriately reuse for different services.
- Clear endpoint for communication based on known protocols allows implementing different pieces with different technologies
- Having the operations flow like independent actions based on different protocols, gives you a lot of places where you can add tiers. Is a particular sub-process of the overall process using lots of resources and the server can't take it anymore, just move to a separate server. Load kept growing, and that server isn't taking it anymore, add an additional server and load balance. You also have more opportunity to use caching and connection pooling.
- Have a critical sub-process that needs to be available all the time, add a server so you can have a fail over. Have an overall process that needs to be "available" all the time, use queues for pieces that can be processed later.
Do you really need to support that type of load? Set appropriate performance/load/interoperability targets that relate to the specific scenario. If you really need to support that type of load, I recommend you get someone on board who has dealt with it.
If it is something for a load that might eventually be, identify the bounded contexts and design the interaction between those with a SOA mindset. Keeping the code clean is all you have to do for the rest, use TDD, loose coupling, focused integration tests, etc in your code base. With good code, if you later need to separate pieces of the system, it will be a lot easier.
There are interesting and relevant things said about services and architecture by Amazon's CTO - Werner Vogels:
- An interview about the Amazon technology platform
- A post on his blog - "Eventually Consistent - Revisited"
- A 50 min presentation about Availability & Consistency
Посмотрите проект Mule , который объединяет стек служб CXF, а также пакет REST Mule, который предоставляет RESTful альтернативы. Я думаю, вы увидите, что это решает все ваши проблемы, и в документации есть много примеров, а также дистрибутив.
Могу ли я порекомендовать книгу: Архитектура корпоративного обслуживания, опубликованную Springer Verlag.
All of the advice here is well and good, but don't worry about it until you really need to.
Focus on building a usable, functional application that people really like. When you start running into problems, then start handling bottlenecks.
You will never be able to foresee every way an application will fail, so how can you tell if [[insert tech here]] is your answer?