I have been trying to draw SOA layers diagram with Visio 2013, but cannot figure out the "Service Components" naming convention. How components should be named deeply in details? Should it be named technically?
Consider this:
Service layer: car information search
Operations: get car information by code, get car information by holder, etc
Service components: How to name it???
If someone can upload exact real world example of SOA layers, it will be the most helpful thing
It's hard to relate all layers to interact each other, i cannot find any real example of SOA layers diagram...
Thanks in advance
Here is what I found in terms of real-life sample:
Click for high resolution image
It is from this presentation.
The description of the service component layer according to SOA RA by the open group, you can read in detail here. As I look at the architecture building blocks of this layer it seems to hold the underlying functionality/logic that enables the service to act accordingly to its contract (which is defined in the Services layer). So in your case probably you will have a Search Manager or Data Manager or Car Search Manager as a service component.
Note that most of the components in this layer are quite technical and are used in the realization of multiple services (e.g. Service Invoker, Service Publisher, etc.), so it makes sense to name them in a more general way (not just in the context of one service). I suggest that you dont't even include these in the diagram explicitly, unless your aim is going into great technical details.
Related
I am working on a Rhapsody SysML project for work and we need to be able to model different configurations of our system. To give a concrete example, if our system is a vehicle, we want to be able to simulate that vehicle with different configurations of engines, wheels, etc.
This is my first time using SysML but in the book A Practical Guide to SysML it discusses, in chapter 7, the concept of Instance Specifications. These sound like exactly what we need, and Rhapsody appears to have support for them. So we created an Instance Specification in Rhapsody, giving it specific values for the engine and wheels. But once we create the instance specification we cannot find any way to actually create an instance from that specification. We noticed that Rhapsody doesn't even generate any code for the instance specification.
So my questions are the following, can Instance Specifications be used to create different configurations of a system and if so how? If not, what is the best method for modeling different configurations of a system?
Thanks for any help you can provide.
I'm having problems to understand the conception of DDD. I have an ASP.NET project with this structure:
ASP.NET MVC4 project: xxx.UI.Web
Class Library project: xxx.Application xxx.Domain xxx.Infra.EF
I'm trying to keep this relation:
xxx.UI.Web only have relation with xxx.Domain and xxx.Application
xxx.Domain doesn't have relations.
xxx.Application have relation with xxx.Domain and xxx.Infra.EF
xxx.Infra.EF have relation with xxx.Domain
But now I'm having many problems to keep this concepts with Entity Framework. I have created the Entity repositories in the xxx.Infra.EF and created a generic repository (with interfaces and so on) in xxx.Application.
The problems begin when I need to pass a personalized Entity context to my repositories, because I use the repositories in the xxx.UI.Web and I can't instantiate a new Entity context because It will broke my project pattern (The Entity context comes from xxx.Infra.EF).
My idea is to create many helper methods that will process this kind of operations for my xxx.UI.Web, and I wouldn't like to create this methods in xxx.Application (It looks a little strange to create many methods with a little relation with my business logic).
So I was reading a little about Domain Driven Development (DDD) and I knew about the Service layer, and I think It seems to be the layer that was created to solve problems like this, or not?
My idea is to create a new class library project called xxx.Service and make this project keep relation with xxx.Domain and xxx.Infra.EF. Is It right? I know that I could search for another solutions for my case with Entity context, but I guess I'll have more problems like this in the future with other things, so I tried to find solutions for It. I should study much more about It, but I think I could identify the solution for my problem.
I suggest you further study the concept of layered architecture.
You are correct that the Domain should not reference other layers, such as the Presentation Layer and Infrastructure Layer.
The most common style of layered architecture is the "Onion Architecture". See image and link below.
http://jeffreypalermo.com/blog/the-onion-architecture-part-1/
The Service Layer
You are also correct that a new layer (Service Layer) will solve your problem. You see, the problem arises because the UI/Presentation Layer is talking directly to the repositories(Infrastructure).
In our approach, the Presentation Layer does not communicate directly with the Infrastructure and Domain. We have a Service layer that comes between the Presentation and the Domain.
The above architecture borrows heavily from the Onion Architecture. We don't have domain services. Application Core is our CrossCutting Layer.
People often misunderstand the point of a multi-tiered application. The goal is not necessarily to remove dependencies, but rather to encapsulate and modularize code. Your MVC frontend shouldn't need to be concerned with your entities and how their queried, added, updated, etc., but it doesn't mean it doesn't need access to them. Long and short, don't focus on project references, but rather factoring out code that is not in each project's "domain" into a more appropriate "domain".
To that end, it's not really possible to say based on the information you provided exactly what you should do. The question is opinionated to begin with and will very likely end up being closed as a result. Ultimately, you have to decide what's best for your project. Do what makes sense, rather than blindly following some pattern. After all, patterns are supposed to just be a codification of common sense approaches to common problems, anyways.
I generally use IoC pattern in my projects which are most of the time ASP.net based. Are there any guidelines on how to structure the projects in a general 3 layered project UI+BL+Data Access. I want to know more about how the folders should be created, where should constants be kept at within each layer (I keep all the strings such as query string parameters, stored procedure parameter etc in file named Constants which is singleton). How should I create classes that interact with Data Access layer from Business Layer etc. and all such code structure questions.
Is there any guidance or a book on this?
Microsoft has a plethora of information on this. I've used Microsoft .NET: Architecting Applications for the Enterprise as my bible for software architecture
http://www.amazon.com/Microsoft%C2%AE-NET-Architecting-Applications-Pro-Developer/dp/073562609X
Check out this MSDN guide as well
http://msdn.microsoft.com/en-us/library/ff647095.aspx
Also, take a look at some application frameworks like Sharp Architecture for examples
http://sharparchitecture.net/
A lot of NHibernate tutorials demonstrate software design principles that can be applied to any solution
http://nhforge.org/blogs/nhibernate/archive/2010/04/25/first-three-nhibernate-quickstart-tutorials-available.aspx
#robbymurphy has a great answer. I would only add that I keep most constants and interfaces in a separate project/assembly altogether. I call this my "core" assembly and and define interfaces that allow me to pass data from the top of the stack to the bottom without tightly coupling them.
It is not so much where they are used, but for what purose. I once attended a seminar class where the instructor pounded "high cohesion, low coupling" into our heads, over and over.
Keep those things that, in the real world, belong together, together, but, reduce dependencies between object whenever possible.
This is a cohesion question as well as a coupling issue: if the constants are truly internal to a class, make them private static members (i.e. and internal state enum) . If they are truly internal to a project, create a class for them, and make them internal (a database specific constant in your data layer). Otherwise, put them in a public class in their own project.
original question
when should i use multi-tier web application instead of single tier web application?
update to my question
i accepted the following definition to differentiale "Tier" and "Layer"
Layers Refer to specific layers of abstraction with in an application (software) where as tiers Refer to the physical residence of those layers (hardware)
App.Layer == "Software"-----logical
App.Tier == "Hardware"------physical
Layers:
1) presentation layer
2) business layer
3) data access layer
4) data layer
5) external system access layer
Tiers:
1) Presentation tier (webserver)
2) Data tier (database server)
Let's start by asking, will the application hold data? If it does, is the data going to be read by multiple users concurrently? How often? Based on the answer to these questions (and many other) you might want to decide whether a database is the way to go.
As far as layers (UI, Data Access, Business Logic, etc) is concerned, it trully depends on a project by project basis. Are you developing a web app for proof of concept? Are you expecting it to maintain it? Do you trust all the developers in your team? But my rule of thumb is to alway use layers unless i'm throwing something together really quick to either prove something or know it will never be maintained and I need to do it fast.
If you decide to use a framework such as MVC, MVP, MVVM, etc then by default you're dividing your app into layers.
Keep in mind that these divisions help you isolate certain aspects of your app, which in turn allow you to easily work with TDD, separation of concerns, maintainabilty, etc.
In conclusion, you have to look at your requirements, goals, team members, and short and long term objectives and decide. There is no white or black answer here
when should i use multi-tier web application (Tier == "Hardware"------physical)
Scalability.
I work for a firm that provides certain types of financial consulting services in most states in the US. We currently have a fairly straightforward CRUD application that manages clients and information about assets and services we perform for each. It only concerns itself with the fundamental data points and processes that are common to all locations--the least common denominator.
Now we want to implement support for tracking disparate data points and processes that vary from state to state while preserving the core nationally-oriented system. Like this:
(source: flickr.com)
The stack I'm working with is ASP.Net and SQL Server 2008. The national application is a fairly straightforward web forms thing. Its data access layer is a repository wrapper around LINQ to SQL entities and datacontext. There is little business logic beyond CRUD operations currently, but there would be more as the complexities of each state were introduced.
So, how to impelement the satellite pieces...
Just start glomming on the functionality and pursue a big ball of mud
Build a series of satellite apps that re-use the data-access layer but are otherwise stand-alone
Invest (money and/or time) in a rules engine (a la Windows Workflow) and isolate the unique bits for each state as separate rule-sets
Invest (time) in a plugin framework a la MEF and implement each state's functionality as a plugin
Something else
The ideal user experience would appear as a single application that seamlessly adapts its presentation and processes to whatever location the user is working with. This is particularly useful because some users work with assets in multiple states. So there is a strike against number two.
I have no experience with MEF or WF so my question in large part is whether or not mine is even the type of problem either is intended to address. They both kinda sound like it based on the hype, but could turn out to be a square peg for a round hole.
In all cases each state introduces new data points, not just new processes, so I would imagine the data access layer would grow to accommodate the addition of new tables and columns, but I'm all for alternatives to that as well.
Edit: I tried to think of some examples I could share. One might be that in one state we submit certain legal filings involving client assets. The filing has attributes and workflow that are different from other states that may require similar filings, and the assets involved may have quite different attributes. Other states may not have comparable filings at all, still others may have a series of escalating filings that require knowledge of additional related entities unique to that state.
Start with the Strategy design pattern, which basically allows you outline a "placeholder", to be replaced by concrete classes at runtime.
You'll have to sketch out a clear interface between the core app and the "plugins", and you have each strategy implement that. Then, at runtime, when you know which state the user is working on, you can instantiate the appropriate state strategy class (perhaps using a factory method), and call the generic methods on that, e.g. something like
IStateStrategy stateStrategy = StateSelector.GetStateStrategy("TX"); //State id from db, of course...
stateStrategy.Process(nationalData);
Of course, each of these strategies should use the existing data layer, etc.
The (apparent) downside with this solution, is just that you'll be hardcoding the rules for each state, and you cannot transparently add new rules (or new states) without changing the code. Don't be fooled, that's not a bad thing - your business logic should be implemented in code, even if its dependent on runtime data.
Just a thought: whatever you do, completely code 3 states first (with 2 you're still tempted to repeat identical code, with more it's too time-consuming if you decide to change the design).
I must admit I'm completely ignorant about rules or WF. But wouldn't it be possible to just have one big stupid ASP.Net include file with instructions for states separated from main logic without any additional language/program?
Edit: Or is it just the fact that each state has quote a lot a completely different functionality, not just some bits?