Do the services in a service oriented architecture need to communicate across a network interface? OR can the services sit on the same computer without even touching localhost? If so, are there any examples of this?
Yes you can - service orientation is an architectural style which you can implement in many ways. An example for in memory implementation is OSGI standard see this presentation for example
Related
My company has a .NET project which serves following use cases
It listens on a WebSocket Port with certificate based client authentication.
It listens on another WebSocket Port with authorization header based client authentication.
It listens on a TCP Port with certificate based client authentication.
On the above three ports different set of client devices are connected.
Now my company wants to convert this application in .NET Core so that this can be deployed on Linux servers to save the deployment cost. As an architect I am thinking in the direction of adopting microservices architecture along with migrating the application in .NET Core. So I am thinking that the above application can be break down into three microservices based on the above use cases.
AFAIK microservices architecture means breaking down your application into smaller services which serves a particular use case. So breaking this complete application into three different microservices is correct or not.
My organization is very new to micro services architecture.I just want to know that whether this thinking is correct or not as per architecture.
Thanks in advance for your help.
Generally I'd try to break things down based on business domains (or business capabilities) instead of technical reasons.
A good place to start might be reading about domain driven design and bounded contexts - see here - there's some good further reading at the end of that link.
Yes you are thinking in right direction.
Here are my suggestion-
you should go for .NET Core and Docker for implementing your Microservices in a better way.
There can be multiple cases when you will go for docker container in this scenario-
1: Run the same image in multiple containers
2: Manage different Containers
3: Run the same image in multiple environments
4: Tag and Run image with different versions
And other reason to go for micro services with docker-
Microservices are smaller in size
Microservices are easier to develop, deploy, and debug, because a fix only needs to be deployed onto the microservice with the bug, instead of across the board
Microservices can be scaled quickly and can be reused among different projects
Microservices work well with containers like Docker
Microservices are independent of each other, meaning that if one of the microservices goes down, there is little risk of the full application shutting down.
You do more research on the same and easily go for micro services architecture.
This may not be answering your question, but I thought it could be useful, especially in light of the fact that your organization is very new to micro-services.
I would recommend to carefully evaluate the advantages and especially disadvantages (complexity) that micro-services architecture introduces.
Just a few examples of things that you will need to think about are log aggregation, communication between services (sync vs async), E2E and integration tests, eventual consistency, etc. Obviously you may end up not having to deal with some of these, but all of them do become a lot more complicated with micro-services.
There should be good business justification to take on the additional complexity (=cost).
Microservices shouldn't be measured on how small enough but how autonomous and independent they are. Microservices are great to be designed around business and domain context and mentioned in details Identifying domain boundires
Since you are starting to build microservices in .Net core why not consider severless microservices ? You have plenty on options in major clouds (AWS,Azure) to build serverless microservices. Serverless are quicker to build and you get generous free tier and you don't have to manage clusters. Is there specific reason you would want to use Kubernetes? you can read more about cloud native and servlerss here Design Cloud native and Serverless
Can I use SOA and three-tier in one application? Using SOAP to connect for external services, using MQ and Spring MVC. I have an application server and server for the database.
Yes, it seems that they are very different things.
There is a vast array of different SOA implementation styles, you can do it in so many ways. One is to have services talking to APIs over http where the APIs in question are written in a 3 tier style.
You can also have an event driven architecture where messages are passed on a message bus or a queue or some sort, the services reading and writing to those queues can be written in a three-tier style.
To sum up yes you can have SOA and three-tier in the same architectural solution, one does not exclude the other.
Does this help your decision on how to structure your service design and how to structure the wider solution architecture?
I study SOA and webservices for a science paper. My state of knowledge is, that every SOA architcture needs a service broker.
Webservices are concrete implementations of a SOA, so do they have a service broker after? For example I create a webservice in asp.net which returns "hallo world" By Creating it, do I create a service broker too?
Don't let fool you by answers which are copy paste from Wikipedia :-)
Webservices are concrete implementations of a SOA
This assumption/statement is wrong. At least there is no direct relationship between SOA and webservices. SOA is an architectural paradigm where a webservice is a concrete technology (stack) based on WSDL and its result, the SOAP-protocol. Nothing more. Webservices may help to establish loosely coupled service landscape, which the SOA paradigm expects. But you could also build up a SOA landscape with other technology stacks (self-written hacks, RMI, even based on REST for instance).
Repository
The thing is: When you start building up your SOA-landscape, you (or others) will code services (i.e. webservices) where your service will have a technical contract (WSDL, WADL, ..) as a base for the implementation. Your clients will ask for it and you want it to store somewhere. This somewhere is usually a service repository. You could develop your own one, use the UDDI-standard or just buy one of products by the big vendors (IBM, TIBCO, Oracle etc).
Broker
A message broker within the SOA context is some piece of software, which supports the decoupling of the connected partner systems. Commonly it's called ESB (enterprise service bus). Also one of the goals of the SOA paradigm is, that the services can be used by anyone (reusability). Therefore you don't want to connect your services by P2P-connections (aka spaghetti architecture) - just imagine that one of the service participants changes it's hardware/IP: this would be a nightmare for all the connected partner systems. That's why the ESB was invented which acts between the service consumer and the service provider.
Typically, these ESB-products support a lot of technologies or -stacks/APIs like HTTP, JMS, REST etc.
Source: I work with a self-claimed SOA landscape and thousands of different (web-)services for a big company for a long time now.
A Web service is a set of related application functions that can be programmatically invoked over the Internet. Businesses can dynamically mix and match Web services to perform complex transactions with minimal programming. Web services allow buyers and sellers all over the world to discover each other, connect dynamically, and execute transactions in real time with minimal human interaction.
Web services are self-contained, self-describing modular applications that can be published, located, and invoked across the Web.
A network component in a Web Services architecture can play one or
more fundamental roles: service provider, service broker, and service
client.
Service brokers register and categorize published services and provide search services. For example, UDDI acts as a service broker for WSDL-described Web services.
What is the difference between "SDN Platform" and "SDN Controller Platform"? These two indicate the same things? Could someone please explain this to me?
There is not much literal difference between these terms, and usually they are referred interchangeably. SDN Controller Platform is actually the controller software that takes care of entire network manageability.
The controller is said as a platform, as this gives the programmer the flexibility to add specific modules (for e.g., a routing module which takes care of routing only multicast packets using some very different routing algorithm) and run them on the controller. A controller when used without any specific modules, essentially sends all packets to everywhere (well, it depends on the controller implementation also). The controller is a platform where you are expected to do stuff and make your network behave the way you want.
And sometimes SDN Platform is used for SDN Infrastructure which includes topology, switches, one or more controllers and so on. Essentially describing the whole network infrastructure.
What you need to know is SDN components, like controller, switches, protocols etc.
I dont see a exact difference between two terminologies you have mentioned .
Briefing SDN Platform simply denotes the seperation of Data plane and Control Plane . I know this can be confusing . But think it this way when you seperate the brain of a switch and put it in another layer ..
Generally SDN consists three layers (from top)
1)Applications -- Consists of Network Applications eg: FW,IPsec etc..
NB API --- no defined Standard yet
2)Control --- consists of Controller
SB API --- This is where OPENFLOW is used
3)Infrastructure --- consists of network devices eg:Switches
The Control Layer connects these two layes using NB API and SB API's
SDN simply gives advantage to network admin to configure multiple network devices .
Using a SDN Controller they can configure multiple network devices at a single place
Hope this helps :D
From software perspective, the term 'platform' emphasises on how a software would be used as the enabler for other applications.
A SDN contoller can be any application which pushes policies to the underlying network. SDN platform on the other hand, should provide extended tools, APIs and hooks to facilitate running 3rd party applications on top of it.
SDN is one of the best open-source platform for developing the projects. SDN platform is just nothing but the networking platform which provides us with numerous benefits to work on topologies. It gives a option to the user to install any controller of their choice and work on it.
SDN Controller platform is the SDN that provides a base platform for different number of controllers onto it. They work on API. SDN Controller platform architecture differs for the different controllers.
I am analysing various technologies in asp.net for better usage to have all it benefits(such as code reuse, avoiding time consumption by knowing technology usage etc) . currently working with wcf implementation . where will i be using it more effectively ? any suggestions would be appreciated
thank you
You'll be using WCF in scenarios where you need to transport data between logical layers in different physical layers.
For example, a client-server application that should stream data from the server to the client and viceversa.
Or a web application that exposes a Web Service API.
It's all about simplifying socket programming over TCP, UDP and other protocols on top of these like HTTP and SOAP.
If you need a networked solution, WCF is one of best ways of easly acquire good results in less time, and gain a configurable and easy to deploy, easy to host n-tier program.
WCF is a programming model that allows the developer to create distributed systems that follow SOA.
If you are looking at a system which needs to be loosely coupled and if you as a developer want to control the flow of data between layers to a great extent then a WCF service is the one for you.
take a look at Wrox's Professional WCF Programming if you could. you will get a good know how
`Dinesh