Recently, I was reading 2 books and I came across with the following statements
Learning WCF from Michele Leroux:
Services encapsulate business functionality
Service orientented architecture in real world:
Services can be assembled (or ―composed‖) into business processes
Loosely-coupled
systems result in loosely-coupled business processes, [...]. Services and their
associated interfaces must remain stable, enabling them to be re-configured or re-aggregated to
meet the ever-changing needs of busines
Reading SOA in real world, I understood that I was suppose to make my independent (initially useless)services abstracted from a business context, and then compose and orchestrate then to do something useful, creating the business layer and meting the business needs.
Then, reading Learning WCF made me to think that I should make my business layer to met a specific need and then expose it as a service(of course in a non platform specific format)
Currently, I'm making my business layer and then exposing some of it's public methods via well defined interfaces, but I liked the idea of making more independent services and compose then to make the business layer.
I would like to hear from experienced SOA developers, what of those approaches would be ideal to get the benefits of SOA and why?
I'm confuse about this topic. Examples and open source projects will be of great help.
To me the idea of a service is to encapsulate business related functionality. However, this is not the same as a business process. Often separate pieces of business functionality will need to be composed into larger units to represent entire business processes. For example, making a sale will require taking payment, shipping product, calculating sales commission. All of these are discrete pieces of business functionality that could be modelled as services but they would have to be composed to represent the entire business process
However, business processes tend to be relatively long running (more than the network timeout of a single request) so somehow the state of the business process needs to be maintained - this is one of the things Workflow and Biztalk can bring to the party.
In Thomas Erl's books, he categorises Services into 'Entity Services', which are fine-grained, business process agnostic services that relate to one Entity and are often used in compositions/orchestrations, and 'Task Services' which are course-grained, usually involve more than one entity, contain more business logic, have some knowledge of the business process and are not candidates for reuse/composition.
So a business process can either be implemented in one big Task Service, or it can be implemented by combining several Entity Services into a composition.
'Task Services' sound like Michelle Leroux's vision of a service, whereas SOA in Real World has more of an 'Entity Service' vision.
In Erl's vision of SOA, both types of services can live side by side. Entity Services are the prefered goal - these can be reused and composed more easily and increase business agility. But in some circumstances this might not be appropriate, and task services would be a better solution - peformance demands and encapsulating legacy code are two examples.
Related
can someone please explain the difference between system design and object oriented design?
Object oriented design involves object modeling and uses object oriented concepts such as Abstraction, Encapsulation, Decomposition and Generalization. Both of the design involves Architectural design and conceptual design.
Is one of the design paradigm subset of other?
System design is the designing the software/application as a whole [high level] that may include analysis, modelling, architecture, Components, Infrastructure etc. whereas the objected-oriented design is the set of defined rules/concepts to implement the functionalities within a software.
Take an analogy, a football game.
So the System design involves the design of football ground, goal poles, grass on the ground, location of the ground, length/breadth of the ground, putting line marks on the ground, scoreboard, defining the playing teams, number of players to play etc.
Now, take object-oriented design: how the games need to be played is defined by a set of rules that need to be followed. Thus the players need to play the game within the defined rules. So the more the player knows those rules the better they can play the game without making fouls. Similarly, the rules for the object-oriented concepts are inheritance, composition, abstraction, encapsulation. Thus the better we know these concepts the better design we can make.
#Prashant, hope it explains a bit
Let's say you want to design an online shopping web Application (like amazon.com). So before making that web application you have to think of :
load balancing to handle the user requests,
database whether to use SQL or NOSQL,
whether to use cache like Redis or not,
making microservices for the different tasks ( like notification service, order processing service etc.)
monitoring your web application (like memory, cpu etc.),
logging (say in sumoLogic).
CI/CD
So all these will fall under system design as they are required for any system to work.
Now once you finalized all these things and went to implement (writing code) any part of the system then you can follow the Object-oriented design to make classes, interfaces etc.
For example, you started implementing the notification microservice ( say in Java), so now you have to design classes, interfaces etc., and for this, you can use the object-oriented design principles like SOLID.
So we can say that object-oriented design is a part of system design which comes into picture when we start working on the actual implementation for any part of the system.
System in System Theory can be everything. (Facets of Systems Science, George Klir, 1991) System is on TOP of TREE, Superclass of other categories.
In overall, System Development included 2 major phases:
1- System Analysis: including Planning, requirements, analysis and etc. These items related to specific methodology in system theory.
2- System Design: including design, implementation, test, deploy, maintenance and etc.
As I said, System can be everything. For example:
Mechanical systems, Psychological systems, Social systems, Aircraft Systems and so on. Each category may have detailed and specific analysis and design steps based on mentioned 2 major phases.
In computer world, Software Systems is one of System categories.
Each software Analysis and Design method is based on mentioned 2 major phases too.
Additionally, In Software Systems, we have some paradigms to analysis and design like:
Structural/Process Centered
Data Centered
Object Oriented
Service Oriented
and etc.
Each of them has it's own Analysis and Design Steps. These steps are based on 2 major phases as well. But in details, they have some differences.
To sum up, Systems Analysis and Design is a big picture to all other type of systems. Learning System Analysis and Design helps to understand all other systems analysis and design and specially helps to compare and evaluate them.
Objects are parts of a system. You can think Object Oriented Design is a part of System Design. You can design a system in high level (with overview) or in low level (with details). It will highlight
Infrastructure
Data flow management
Services
Cache management
Request/response management etc
When doing object oriented design you can think that you have to use some objects and making relations among them. But before making object you need to design some classes. So actually OOD (object oriented design) is
Designing class diagram (optional)
Making some classes
Making relations among classes
Using classes for creating objects
Implementing the purpose (basic functions and logics) etc
We're developing a comprehensive domain model encompassing 7(!) models/bounded contexts spanning several teams. We are yet to decide whether each one of the BCs is entirely disconnected from the others (being orchestrated by a layer above) or whether they are going to communicate via domain-events.
The application under development is for all purposes a SWT/Swing single-threaded application, so no fancy distributed mumbo jumbo between the different BCs is needed.
Yet, a big question remains: how to integrate all those different models? Should it be the Application Layer to undertake the task? If yes, and since in some (hopefully, few) cases the wiring and order ends up being complex, isn't the Application Layer the wrong place to do that?
For instance, consider the use of case of assembling a very complex synthetically created human (AssembleHumanoid). We have bounded contexts relating to the circulatory system, to the bone structure, the nervous system, ventilation system, coordination, immunological and mental systems and still the sensor system (lol, this was just all made up as you might imagine).
Wiring up all that stuff in the Application Layer feels kinda wrong. The obvious solution seems to be to create a 2nd Domain Layer just for orchestration matters. I've looked up but Vernon's Implementing Domain-Driven Design doesn't directly touch the issue (although he gets near # p531, "Composing Multiple Bounded Contexts").
What are your thoughts on the matter?
I'm right now tackling the same questions as you. My role in my project is architect and we have identified 5 BC's. But we are one team and intend to develop theses BC's within one large application. So our BC's are modules within a larger insurance application where each BC speaks its own ubiquitous language (Treaty, Reinsurance, security, medical risk assessment, premium).
But I have given this a lot of thoughts and I think we'll send updates to other BC through Domain Events. Our client is a MVC site that will consume our service layer. But My intention is that application layer have that kind of granularity so it will manage to perform the main task for the client without letting the client MVC project to coordination to other BC's.
We uses some shared Kernel between BC's but not for communicating. We do use DDD integration pattern where we have reference to other BC through Value Objects. We also have som BC to act like Factory, for example Security BC are creating different user roles for other BC's.
But when it comes to execution of a use case that actually need to to some final task in other BC's , Domain Event comes to rescue.
We are implementing numerous services in our company and running into versioning issues with data contracts. One of the problems we have is that our data contract are also used as the model of the actual application behind the service. I was wondering what approach others have taken in this kind of situation or just service versioning in general. I am aware of the microsoft best practices guide but wanted to see if anybody has any other ideas on how to version.
The first rule of Services, Business Object != Message Object. Basicly, never expose your business objects as data contracts. Or as I like to say, you can't fax a cat. You can send a facsimile of a cat, but you can't send a cat over the wire. Here's a great picture to remind you: http://www.humorhound.com/2009/04/demotivational-poster-youre-doing-it-wrong/
In more modern terms, it is really the MVVM pattern. The view of the model that the domain layer uses is not built for a client, so you have to create a separate model and view for the other layers. Yes it seems like a lot more work, but in the end it is a much easier and better way to build service oriented applications. Versioning is just one of the ways that it makes life easier. The other important thing is that you tend to build models that are geared around how it is going to be used, and you wind up with more explict code (less crazy branching).
The way that we have implemented this is to build a facade layer on top of the business layer.
The facade layer talks to the rest of the world using the objects defined in the data contracts.
The facade layer maps the objects to internal objects before sending the data into the business layer.
This isolates the internal functionality of your system from the objects used in the data contracts.
In my SOA architecture, I have several WCF services.
All of my services need to access the database.
Should I create a specialized WCF service in charge of all the database access ?
Or is it ok if each of my services have their own database access ?
In one version, I have just one Entity layer instanced in one service, and all the other services depend on this service.
In the other one the Entity layer is duplicated in each of my services.
The main drawback of the first version is the coupling induced.
The drawback of the other version is the layer duplication, and maybe SOA bad practice ?
So, what do so think good people of Stack Overflow ?
Just my personal opinion, if you create a service for all database access then multiple services depend on ONE service which sort of defeats the point of SOA (i.e. Services are autonomous), as you have articulated. When you talk of layer duplication, if each service has its own data to deal with, is it really duplication. I realize that you probably have the same means of interacting with your relational databases or back from the OOA days you had a common class library that encapsulated data access for you. This is one of those things I struggle with myself, but I see no problem in each service having its own data layer. In fact, in Michele Bustamante's book (Chapter 1 - Page 8) - she actually depicts this and adds "Services encapsulate business components and data access". If you notice each service has a separate DALC layer. This is a good question.
It sounds as if you have several services but a single database.
If this is correct you do not really have a pure SOA architecture since the services are not independant. (There is nothing wrong with not having a pure SOA architecture, it can often be the correct choice)
Adding an extra WCF layer would just complicate and slow down your solution.
I would recommend that you create a single data access dll which contains all data access and is referenced by each WCF service. That way you do not have any duplication of code. Since you have a single database, any change in the database/datalayer would require a redeployment of all services in any case.
Why not just use a dependency injection framework, and, if they are currently using the same database, then just allow them to share the same code, and if these were in the same project then they would all use the same dll.
That way, later, if you need to put in some code that you don't want the others to share, you can make changes and just create a new DAO layer.
If there is a certain singleton that all will use, then you can just inject that in when you inject in the dao layer.
But, this will require that they use the same DI framework controller.
The real win that SOA brings is that it reduces the number of linkages between applications.
In the past I've worked with organizations who have done it a many different ways. Some data layers are integrated, and some are abstracted.
The way I've seen it most successfully done is when you create generic data-layer services for each app/database and you create the higher level services based on your newly created data layer.
There's been a lot of interest in Service-Oriented Architecture (SOA) at my company recently. Whenever I try to see how we might use it, I always run up against a mental block. Crudely:
Object-orientation says: "keep data and methods that manipulate data (business processes) together";
Service-orientation says: "keep the business process in the service, and pass data to it".
Previous attempts to develop SOA have ended up converting object-oriented code into data structures and separate procedures (services) that manipulate them, which seems like a step backwards.
My question is: what patterns, architectures, strategies etc. allow SOA and OO to work together?
Edit: The answers saying "OO for internals, SOA for system boundaries" are great and useful, but this isn't quite what I was getting at.
Let's say you have an Account object which has a business operation called Merge that combines it with another account. A typical OO approach would look like this:
Account mainAccount = database.loadAccount(mainId);
Account lesserAccount = database.loadAccount(lesserId);
mainAccount.mergeWith(lesserAccount);
mainAccount.save();
lesserAccount.delete();
Whereas the SOA equivalent I've seen looks like this:
Account mainAccount = accountService.loadAccount(mainId);
Account lesserAccount = accountService.loadAccount(lesserId);
accountService.merge(mainAccount, lesserAccount);
// save and delete handled by the service
In the OO case the business logic (and entity awareness thanks to an ActiveRecord pattern) are baked into the Account class. In the SOA case the Account object is really just a structure, since all of the business rules are buried in the service.
Can I have rich, functional classes and reusable services at the same time?
My opinion is that SOA can be useful, at a macro level, but each service probably still will be large enough to need several internal components. The internal components may benefit from OO architecture.
The SOA API should be defined more carefully than the internal APIs, since it is an external API. The data types passed at this level should be as simple as possible, with no internal logic. If there is some logic that belongs with the data type (e.g. validation), there should preferably be one service in charge of running the logic on the data type.
SOA is a good architecture for communicating between systems or applications.
Each application defines a "service" interface which consists of the requests it will handle and the responses expected.
The key points here are well defined services, with a well defined interface. How your services are actually implemented is irrelevant as far as SOA is concerned.
So you are free to implement your services using all the latest and greatest OO techniques, or any other methodology that works for you. ( I have seen extreme cases where the "service" is implemented by actual humans entering data on a screen -- yet everything was still text book SOA!).
I really think SOA is only useful for external interfaces (generally speaking, to those outside your company), and even then, only in cases when performance doesn't really matter, you don't need ordered delivery of messages.
In light of that, I think they can coexist. Keep your applications working and communicating using the OO philosophy, and only when external interfaces (to third parties) are needed, expose them via SOA (this is not essential, but it is one way).
I really feel SOA is overused, or at least architectures with SOA are getting proposed too often. I don't really know of any big systems that use SOA internally, and I doubt they could. It seems like more of a thing you might just use to do mashups or simple weather forecast type requests, not build serious systems on top of.
I think that this is a misunderstanding of object orientation. Even in Java, the methods are generally not part of the objects but of their class (and even this "membership" is not necessary for object orientation, but that is a different subject). A class is just a description of a type, so this is really a part of the program, not the data.
SOA and OO do not contradict each other. A service can accept data, organize them into objects internally, work on them, and finally give them back in whatever format is desired.
I've heard James Gosling say that one could implement SOA in COBOL.
If you read Alan Kay's own description of the origins of OOP, it describes a bunch of little computers interacting to perform something useful.
Consider this description:
Your X should be made up of Ys. Each Y should be responsible for a single concept, and should be describable completely in terms of its interface. One Y can ask another Y to do something via an exchange of messages (per their specified interfaces).
In some cases, an X may be implemented by a Z, which it manages according to its interface. No X is allowed direct access to another X's Z.
I think that the following substitutions are possible:
Term Programing Architecture
---- --------------- ------------
X Program System
Y Objects Services
Z Data structure Database
---- --------------- ------------
result OOP SOA
If you think primarily in terms of encapsulation, information hiding, loose coupling, and black-box interfaces, there is quite a bit of similarity. If you get bogged down in polymorphism, inheritance, etc. you're thinking programming / implementation instead of architecture, IMHO.
If you allow your services to remember state, then they can just be considered to be big objects with a possibly slow invocation time.
If they are not allowed to retain state then they are just as you've said - operators on data.
It sounds like you may be dividing your system up into too many services. Do you have written, mutually agreed criteria for how to divide?
Adopting SOA does not mean throw out all your objects but is about dividing your system into large reusable chunks.