Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I was looking for differences b/w SOA and Microservices architecture style
and found a good link https://www.infoq.com/articles/boot-microservices
It Says:
As a successor to "Service Oriented Architecture" (SOA), microservices can be categorized in the same family of "distributed systems", and carry forward many of the same concepts and practices of SOA. Where they differ, however, is in terms of the scope of responsibility given to an individual service. In SOA, a service may be responsible for handling a wide range of functionality and data domains, while a general guideline for a microservice is that it is responsible for managing a single data domain and the corresponding functions around that domain.
Please help me to understand :
The meaning of single data domain (recommended for microservice).
is it saying that a separate Microservice has to be build to manage a single domain/entity (and associated/composite domain/entities with this single domain/entity). Becasue if this case, then there will be many(~20 to ~50) microservices even to implement a basic functionality (enterprise) application
Edit:
I have gone through the link Difference between Microservices Architecture and SOA, but it explains, that it is same on the first two tenets, and different on 3rd point (in SOA, Services share schema and contract, not class), but that is SOAP contracts, but then what is the difference b/w SOA (with REST) vs Microservices (which is mostly with REST)
Adding to what Sean had said, microservices are what people started to call APIs when SOA had started to being put to use in many companies. The rise of Domain-driven design has also led to the increase in usage of the term. In the industry right now, there is absolutely no difference between the two, people call it as they seem fit.
You are right when you said that you will end up with many micro-services when you follow the philosophy in principle. In my opinion, be it SOA or microservices, abstraction to independent services should depend only on the use-case, how the services are going to be deployed and how many teams are going to work on those in parallel. There is also an increasing cost to network bandwidth if the services are deployed across hosts (though containers and DC/OS frameworks are solving this problem now). If it is fast-changing service, having lots of moving parts, then breaking down a big service into microservices would make sense. Otherwise I would avoid premature optimisation and have the functionality packaged into a single (or a few big) services.
I think that this is a matter of interpretation:
I'd argue that in SOA a service is not a physical process (windows service/app domain) but a logical boundary... and the same rules apply in SOA and Microservices in regards to the smallest autonomous component. they own (the technical authority and data owners meaning they are the only one component that can change the state of that piece of data) of a collection of one or more domain properties/fields.
Now at runtime, I'd argue that if you don't need to distribute you process, then you can deploy them all in the same process (later when you need to scale, distribute your components to achieve better performance)...
Make sense?
I found a good explanation done by Microsoft :
Microservices derive from SOA, but SOA is different from microservices
architecture. Features like big central brokers, central orchestrators
at the organization level, and the Enterprise Service Bus (ESB) are
typical in SOA. But in most cases, these are anti-patterns in the
microservice community. In fact, some people argue that “The
microservice architecture is SOA done right.”
Regarding your question about the "domain", to my view, and I believe it is a main characteristic for Microservices: A Microservice should manage its own functional domain and data model.
Let's say you have a products catalog application within your company. You probably would not like to have many other applications hitting the catalog persistence layer and abstracting (again) the catalog model as it would harden the model refactoring / evolution. Probably it would cause concurrency issues between these applications preventing the catalog application to be scaled
Instead you would probably prefer to maintain a single catalog application, which would expose web service APIs (such as REST endpoints) consumed by other applications.
I've read this comment in this other related question "Microservices = SOA - ESB". Indeed, ESB are incompatible with this microservices characteristic: "Smart endpoints and dumb points" which means that when a microservice needs another one as a dependency, it should use it directly without any routing logic / components handling the pipe.
Finally, you could take a look to this cheat sheet based on a Martin Fowler introduction to Microservices video.
SOA is different from micro service.
SOA is feature base and it needs a message service middle ware for interactions between the components. To save you some lengthy theory, let me use some software i worked with recently as illustration.
There is a finance solution i worked with of recent. The solution was broken down into two sub solution that communicate with each others.
The first one is called Fusion Banking Trade Innovation(FBTI) while the other is called Fusion Banking Corporate Channel(FBCC). These solution were developed by separate team and sold as different solution but work together as a single solution. FBCC cannot be used without FBTI. FBCC is what the customer interact with(client interface) while FBTI is the admin dashboard that the bank interact with.
Communication between the two features is achieved using a message service middleware like IBM Message queue(MQ). FBCC send message to the queue and is being picked by FBTI and that is their channel of communication.
Micro service on the other hand is task based. The interactions between components is made possible through a web service. I will used a solution called Prestashop ecommerce solution as illustration.
When you download prestashop, all the functionalities is divided into separate module e.g if you want to change the banner of the home page, there is a module for it. There is a module for navigation bar alone and is different from module for footer. There are more than 300 modules for the solution. There are also modules like Manage Products, Categories, Shopping Cart etc. see fig below
The modular nature of this solution has provided an avenue for other prestashop partner to develop different modules that could replace those default modules in prestashop i.e you can buy another module from a partner to replace default modules like cart, shipping calculator.
In conclusion, SOA concept is majorly used for interaction between two or more solutions while micro service concept is used for interaction between two or more tasks within a solution.
A SOA service is all about componentization on service level.
A Microservice is all about functional composition on service level.
They are two different solutions for different problems.
One of the key benefits provided by Onion architecture is the ability to swap out "infrastructure" elements, such as "Data Access, I/O, and Web Services" (http://jeffreypalermo.com/blog/the-onion-architecture-part-3/).
Jeff says in his post from 2008 that "the industry has modified data access techniques at least every three years".
Does anyone have an example of a reasonably large project where Onion architecture was used and swapping out of key infrastructure elements was subsequently undertaken?
I'm interested to understand:
How common is this scenario, in general?
My instinct tells me that while "data access techniques" may be modified every three years, changes to actual infrastructure for running solutions, which would allow this benefit to be realised, may be a lot less frequent?
What were the conditions were that the solution was operating under originally?
What caused the change in the underlying infrastructure?
Are there lessons to be learned about the practical implications of changing infrastructure in this way, which may allow us to refine original implementations of the Onion architecture?
I'm interested to hear whether there were unexpected changes required beyond just replacing the infrastructure component and implementing the same interface. For example, did the new infrastructure require new arguments to be passed to previously defined methods e.g. SaveOrder(int ID) -> SaveOrder(int ID, bool AllowSiblings, bool SiblingCreated) when moving from a Relational to NoSQL DB model.
Did the implementation of this architecture + rework to migrate to new infrastructure significantly decrease the total effort required, if compared to a traditional, coupled approach?
Do developers find coupled, hard-referenced code easier to write and debug than loosely coupled, indirectly referenced code, but the eventual payoff for infrastructure changes makes this worth it?
Well, IMHO, the primary intent of such architecture style (Hexagoanl, Ports&Adapters, Onion …) is that it allows you to focus on your domain, how you will deliver value instead of focusing first on UI, frameworks or storage issues. It allows you to defer such decisions.
As Jeffrey says, the ability to swap out "infrastructure" elements is a nice side effect of such architecture style. Even if you will not switch from one RDBMS to another every 6 months, it’s quite reassuring knowing that it would be possible doing it without pain, though.
Rather than thinking about changing your storage mechanism on a regular basis or as you said “swapping out of key infrastructure elements”, just think about third parties services that you’d plug to your system. Those are eager to change on a regular basis; you would also switch from one provider to another. This is quite a more common scenario we are used to face with on a more regular basis. In this particular case, the domain behavior won’t change, the interfaces will stay the same, you won’t have to change a single line of code into your core domain layer. Only the implementation made somewhere in your infrastructure layer might have to change. That’s a another noteworthy benefit from that kind of architecture!
Please read this nice Uncle Bob article about Clean Architecture where he explains why the ability to defer critical infrastructure decision is really cool!
--- EDIT ---
Could you provide an example of where you have swapped out a third party service?
We have tons of examples where we switched from one provider to another (from payment providers to live feeds providers or whatever provider). The business stays the same, the domain behaviors are still the same. Changing a provider should not have any kind of impact on your business. You don’t have to change the way your business work, where the value really is, just because you change from one provider to another, it makes no sense. Isolating your domain behaviors in an independent core layer, with no dependencies on any third parties libraries, frameworks or provider services, definitely help you to deal with changes.
I have the feeling that you’re trying to convince yourself whether to go with Onion. You might be on the wrong track only thinking about migrating to new infrastructure related stuff (db, third parties stuff...). Focus on your domain instead. Ask yourself if your domain is complex enough to require such an architecture style. Don’t use a bazooka to kill a fly. As Simon Brown says: "Principles are good, but make sure they’re realistic and don’t have a negative impact"!
If your application is quite small, with no complex business domain, go for classic n-tiers architecture, that’s ok; don’t change things just for the sake of it or just because of any buzzword. But also keep in mind that an isolated core business layer without dependencies, as in Onion architecture, might be very easy to unit test!
Now for your additional questions:
Did the implementation of this architecture + rework to migrate to new infrastructure significantly decrease the total effort required, if compared to a traditional, coupled approach?
It depends! :-) In tightly coupled applications as soon as there’s a new infrastructure element to be migrated, there is little doubt that you’ll surely have to modify code in every layers (including the business layer). But if this application is small, quite straightforward, well organized with a descent test code coverage, this shouldn’t be a big deal. Now, if it’s quite big, with a more complex business domain, it might be a good idea to isolate that layer in a totally separate layer with no dependencies at all, ensuring that infrastructure changes won’t cause any business regression.
Do developers find coupled, hard-referenced code easier to write and debug than loosely coupled, indirectly referenced code, but the eventual payoff for infrastructure changes makes this worth it?
Well, ask your teammates! Are they used to work with IOC? Remember that architecture design and choices must be a team decision. This must be something shared by the whole team.
I am trying to understand the definitions in this document.
http://www.opengroup.org/soa/source-book/ontologyv2/service.htm
Their definitions of service, service interface and service contract are either unclear or seem different from what I normally encounter.
Service:
“A service is a logical representation of a repeatable activity that
has a specified outcome. It is self-contained and is a ‘black box’ to
its consumers.”
Lets say I have a WCF project and it has two Operations
StoreFront
+GetPrice
+AddToCart
The definition says "a repeatable activity". So is the service StoreFront? Or do I have two services (GetPrice and AddToCart).
Service Contract:
Has an "effect" class. Is the effect "return price" and " added to cart" ?
From the same article:
“A capability offered by one entity or entities to others using
well-defined ‘terms and conditions’ and interfaces.” (Source: OMG
SoaML Specification - my italics)
This is in my opinion a preferable defnition than the one talking about "repeatable activities".
The key word in the definition is capability. Capability refers to Business Capability which is a carry-over from the BPM industry, but in an SOA context refers to a business domain with distinct boundaries.
So from this definition we can surmise that services should be exposed or should operate within a business capability/process boundary. This leads us towards the idea (from the principals or tenants of SOA) that services should be autonomous within well defined boundaries.
In your example, you are asking
So is the service StoreFront? Or do I have two services (GetPrice and
AddToCart)
The answer to that as always is "it depends". However, generally Pricing (GetPrice) would belong to a different business capability to Ordering (AddToCart). Additionally, the operations differ in some other important ways:
GetPrice is a read operation, while AddToCart is a write operation.
GetPrice is a synchronous operation, while AddToCart could very well be asynchronous
So from these we should probably assume that they are two different services from a business perspective.
This assumption has some radical repercussions. If they are two services, then according to SOA they should be autonomous. Meaning that we should be looking to minimize coupling between the services in every possible way, so that as much as possible they can be planned, developed, tested, built, deployed, hosted, supported, and managerd as separate concerns.
Another repercussion is that when you physically separate services to this extent, how can you show this stuff together to your users? They may be different capabilities but they still need to work together on the screen.
Additionally, from a back end perspective Ordering needs to know about Pricing data, otherwise how can order fulfillment happen? If you've separated the database into two, how can the Checkout service know how much stuff costs, what discounts to apply, etc?
I have posted about this stuff before, so please feel free to have a read. I would recommend reading the excellent article on Microservices by Lewis and Fowler also.
Closed. This question needs to be more focused. It is not currently accepting answers.
Closed 9 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Can someone explain in plain english what is SOA all about? I hear SOA here, SOA there but I cannot understand exacly what it is and what is used for. Was it some simple concept and later evolved into something huge or what?
All documents, including wiki are a bit abstract or maybe I'm an idiot and don't get it. Is there an idiot's guide on this?
What exactly is there behind these three letters?
SOA is a new badge for some very old ideas:
Divide your code into reusable modules.
Encapsulate in a module any design decision that is likely to change.
Design your modules in such a way that they can be combined in different useful ways (sometimes called a "family" or "product line").
These are all bedrock software-development principles, many of them first articulated by David Parnas.
What's new in SOA is
You're doing it on a network.
Modules are communicating by sending messages to each other over the network, rather than by more tradtional programming-language mechanisms like procedure calls. In particular, in a service-oriented architecture the parts generally don't share mutable state (global variables in a traditional program). Or if they do share state, that state is carefully locked up in a database which is itself an agent and which can easily manage multiple concurrent clients.
You might find this article (What is SOA? - SOA and Web Services Explained ) helpful.
A little teaser:
SOA is a style of architecting applications in such a way that they are composed of discrete software agents that have simple, well defined interfaces and are orchestrated through a loose coupling to perform a required function.
There are 2 roles in SOA- a service provider and a service consumer. A software agent may play both roles. SOA is not an entirely new concept – however, this article mainly focuses on SOA as implemented with web services.
I see many answers explaining a Service Oriented Architecture (SOA) using even more advanced words and technical terms. I'd like to give a shot at explaining it for the layman, using an analogy in plain english.
But first a description of a SOA
SOA could be described in three layers as seen in the picture below. On one side we have the Provider and on the other side we have the Consumer, separated by a Bridge where the two sides communicate.
The consumer uses a number of Applications necessary for it's business and the provider uses Components that provide these applications with information. They communicate through a set of Services using a common architecture.
The analogy
Imagine a house on the country side, that in many ways is part of a larger community, like a city or town. The city has it's own complex systems for providing water and electricity, handling sanitation, providing transportation and other utilities. The House is the consumer in this model, the City (or community) is the provider and the pipes, sewers, powerlines, optical fibers etc. is the Infrastructure in which they communicate.
This model could loosely be compared to a SOA. The people in the house uses a number of different "applications" like radiators, computers, toilets, lamps, underfloor heating, bathtubs etc. These applications don't care how the city generates the water, creates the electricity or handles the waste as long as it works. The components of the city are generators, water pumps and sanitation areas. It provides the house with all these needs but it's up to the house to use it in what ever way it sees fit.
I hope this gave at least someone a better picture of a SOA.
Let's assume you have four cooks. In SOA, you assume they hate each other, so you strive to let them have to talk to each other as little as possible.
How do you do that? Well, you will first define the roles and interface -- cook 1 will make salad, cook 2 will make soup, cook 3 will make the steak, etc.. Then you will place the dishes well organised on the table (so these are the interfaces) and say, "Everybody please place your creation into your assigned dishes. Don't care about anybody else.".
This way, the four cooks have to talk to each other as little as possible, which is very good in software development -- not necessarily because they hate each other, but for other reasons like physical location, efficiency in making decisions etc.
It also means you can recombine the dishes (services) as you like. For example, you might just use the dessert to service a cafe, or just take the soup and combine it with a bread you bought from another company to provide a cheaper menu, or let other restaurants use your salads to combine with their dishes, etc.
One of the most successful implementation of SOA was at Amazon. Because of their design, they could re-package their whole infrastructure and sell it as Amazon Web Service.
*This is only one aspect of SOA.
SOA is an architectural style but also a vision on how heterogeneous application should be developped and integrated. The main purpose of SOA is to shift away from monolithic applications and have instead a set of reusable services that can be composed to build applications.
IMHO, SOA makes sense only at the enterprise-level, and means nothing for a single application.
In many enterprise, each department had its own set of enterprise applications which implied
Similar feature were implemented several times
Data (e.g. customer or employee data) need to be shared between
several applications
Applications were department-centric.
With SOA, the idea is to have reusable services be made available enterprise-wide, so that application can be built and composed out of them. The promise of SOA are
No need to reimplement similar features over and over (e.g.
provide a customer or employee service)
Facilitates integration of applications together and the access
to common data or features
Enterprise-centric development
effort.
The SOA vision requires an technological shift as well as an organizational shift. Whereas it solves some problem, it also introduces other, for instance security is much harder with SOA that with monolithic application. Therefore SOA is subject to discussion on whether it works or not.
This is the 1000ft view of SOA. It however doesn't stop here. There are other concepts complementing SOA such as business process orchestration (BPM), enterprise service bus (ESB), complex event processing (CEP), etc. They all tackle the problem of IT/business alignement, that is, how to have the IT be able to support the business effectively.
SOA is acronym for Service Oriented Architecture.
SOA is designing and writing software applications in such a way
that distinct software modules can be
integrated seamlessly with high degree
of re-usability.
Most of the people
restrict SOA as writing client/server
software-web-services. But it is too
small context of SOA. SOA is much
larger than that and over the past few
years web-services have been primary
medium of communcation which is
probably the reason why people think
of SOA as web-services in general
restricting the boundaries and meaning
of SOA.
You can think of writing a database-access module which is so independent that it can work on its own without any dependencies. This module can expose classes which can be used by any host-software that needs database access. There's no start-up configuration in host-application. Whatever is needed or required is communicated through classes exposes by database-access module. We can call these classes as services and consider the module as service-enabled.
Practicing SOA gives high degree of
re-usability by enforcing DRY [Don't
repeat your self] which results into
highly maintainable software.
Maintainability is the first thing any
software architecture thinks of - SOA
gives you that.
As far as I understand, the basic concept there is that you create small "services" that provide something useful to other systems and avoid building large systems that tend to do everything inside the system.
So you define a protocol which you will use for interaction (say, it might be SOAP web services) and let your "system-that-does-some-business-work" to interact with the small services to achieve your "big goal".
I would suggest you read articles by Thomas Erl and Roger Sessions, this will give you a firm handle on what SOA is all about. These are also good resources, look at the SOA explained for your boss one for a layman explanation
Building a SOA
SOA Design Pattern
Achieving integrity in a SOA
Why your SOA should be like a VW Beetle
SOA explained for your boss
WCF Service Performance
what tends to happen in large organizations is that over time everything is either monolithic or disparate systems everywhere or a little of both. Someone eventually comes in and says we've got a mess. Now, you want to re-design (money to someone) everything to be oriented in a sort of monotlithic depends on who you pay paradigm but at the same time be able to add pieces and parts independently of the master/monolith.
So you buy Oracle's SOA and Oracle becomes the boss of all your parts. All the other players coming in have to work with SOA via a service (web service or whatever it has.) The Oracle monolith takes care of everything (monolith is not meant derogatory). Oh yeah, you got ASP.NET MVC on the front or something else.
main thing is moving things in and out of they system without impact and keeping the vendor Oracle SOA, Microsoft WCF, as the brains of it all. everything's all oop/ood like, fluid, things moving in and out with little to no impact, even human services, not just computers.
To me it just means a bunch of web services (or whatever we call them in the future) with a good front end. And if you own the database just hit the database and stop worrying about buzzwords. it's okay.
Only one suggestion:-
Read SOA Concepts, Technology and Design by Thomas Erl.
It has very beautifully given the details about SOA in plain English and with case studies.
Well You see.. SOA stands for Service Oriented Architecture.... In simplest words, you write a piece of code that is very generic i.e. it does some thing that can be used in a lot of applications ... may be something like a address book or may be a calculator. and you launch this code on the IIS. So you provide a service through your code. So you are a service provider. Now someone wants to use a similar code then he does not have to write the code again. He simply uses your code maybe through a web service. Hence he becomes a service consumer. Hence making a program using such services is called SOA. And the loose coupling is there as the service provider and consumer may be interacting even if they are using diff programming languages.
Hope you understand.
from ittoolbox blogs.
The following outlines the similarities and differences to past design techniques:
• SOA versus Structured Programming
o Similarities: Most similar to subroutine calls where parameters are passed and the operation of the function is abstracted from the caller - e.g. CICS link and execute and the COBOL CALL reserved word. Copybooks are used to define data structure which is typically defined as an XML schema for services.
o Differences: SOA is loosely coupled implying changes to a service have less impact to the consumer (the "calling" program) and services are interoperable across languages and platforms.
• SOA versus OOA/OOD
o Similarities: Encapsulation, Abstraction and Defined Interfaces
o Differences: SOA is loosely coupled with no class hierarchy or inheritance, Low-level abstractions - class level versus business service
• SOA versus legacy Component Based Development (CBD) - e.g. CORBA, DCOM, EJB
o Similarities: Reuse through assembling components, Interfaces, Remote calls
o Differences: Wide adoption of standards, XML Schemas vs. Marshaled Objects, Service Orchestration, Designing for reuse is easier, services are business focused vs. IT focused, business services are course grained (broad in scope)
• SOA (for integration) versus Enterprise Application Integration (EAI)
o Similarities: Best practices (well defined interfaces, standardized schemas, event driven architecture), reusable interfaces, common schemas
o Differences: Standards, adoption, and improved tools
Reading the responses above, it sounds to me that SOA is what developers (good ones at least) have been doing from day one.
It could also stand for "Struct of Arrays" (as opposed to "Array of Structs") which is a common topic in parallel (especially SIMD) programming, but I'm guessing that's not what you mean here!
SOA is a buzzword that was invented by technology vendors to help sell their Enterprise Service Bus related technologies. The idea is that you make your little island applications in the enterprise (eg: accounting system, stock control system, etc) all expose services, so that they can be orchestrated flexibly into 'applications', or rather become parts of aggregate enterprise scoped business logic.
Basically a load of old bollocks that nearly never works, because it misses the point that the reasons why technology is the way it is in an organisation is down to culture, evolution, history of the firm, and the lock in is so high that any attempt to restructure the technology is bound to fail.
Have a listen to this week's edition of the Floss Weekly podcast, which covers SOA. The descriptions are pretty high level and don't delve into too many technical details (although more concrete and recognizable examples of SOA projects would have been helpful.
A traditional application architecture is:
A user interface
Undefined stuff (implementation) that's encapsulated/hidden behind the user interface
If you want to access the data programmatically, you might need to resort to screen-scraping.
SOA seems to me to be an architecture which focus on exposing machine-readable data and/or APIs, instead of on exposing UIs.
SOA or Service-Oriented Architecture is a software architecture pattern in which applications or systems are constructed from underlying (and usually distributed) software services that conform to a specific set of characteristics, namely:
Interface, Policy and Contract based
Location transparency
Autonomous
Abstract
Reusable
Composable
Stateless
Discoverable
Extensible
Loosely coupled
The primary goal of SOA is sofware development agility, i.e. the ability to respond the change easily, and cheaply, thus allowing businesses to rapidly respond to changing markets.
Services are typically (but by no means exclusively) implemented as web services, i.e. they operate over the ubiquitous web HTTP protocol, and are implemented either using XML-based SOAP or the lightweight (and more popular) REST paradigm.
Depends on who you are!
If you're an business owner, SOA is a solution to increase your incomes and business agility. If you're an entreprise architect, SOA is a way to draw nice and clean piece of software on a blank canvas. If you're an architect SOA is the solution to design loosely coupled services over an integration platform, to just plug services into outlets. If you're a developper SOA is a programming paradigm where a service is in the center of the design and the code.
You should read 100-SOA-Questions [pdf]
Cheers
Service Oriented Architecture (SOA) is a software architectural style that builds applications as a collection of pluggable parts, each of which can be reused by other applications.
Let's suppose I have a large middleware infrastructure mediating requests between several business components (customer applications, network, payments, etc). The middleware stack is responsible for orchestration, routing, transformation and other stuff (similar to the Enterprise Integration Patterns book by Gregor Hohpe).
My question is: is it good design to put some business logic on the middleware?
Let's say my app A requests some customer data from the middleware. But in order to get this data, I have to supply customer id and some other parameter. The fetching of this parameter should be done by the requesting app or is the middleware responsible for 'facilitating' and providing an interface that receives customer ids and internally fetches the other parameter?
I realize this is not a simple question (because of the definition of business logic), but I was wondering if it is a general approach or some guidelines.
Apart from the routing, transformation and orchestration, performance should be kept in mind while loading middleware with functional requirements. Middlware should take a fraction of the entire end-to-end transaction life time. This can be achieved only by concentrating on the middleware core functionalities, rather than trying to complement the host system functionalities.
This is the "Composite Application" pattern; the heart of a Service Oriented Architecture. That's what the ESB vendors are selling: a way to put additional business logic somewhere that creates a composite application out of existing applications.
This is not simple because your composite application is not just routing. It's a proper new composite transaction layered on top of the routing.
Hint. Look at getting a good ESB before going too much further. This rapidly gets out of control and having some additional support is helpful. Even if you don't buy something like Sun's JCAPS or Open ESB, you'll be happy you learned what it does and how they organize complex composite applications.
Orchestration, Routing and Transformation.
You don't do any of these for technical reasons, at random, or just for fun, you do these because you have some business requirement -- ergo there is business logic involved.
The only thing you are missing for a complete business system is calculation and reporting (let us assume you already have security in place!).
Except for very low level networking, OS and storage issues almost everything that comprises a computer system is there because the business/government/end users wants it to be there.
The choice of 'Business Logic' as terminoligy was very poor and has led to endless distortions of design and architecture.
What most good designers/architects mean by business logic is calculation and analysis.
If you "%s/Business Logic/Calculation/g" most of the architectural edicts make more sense.
The middleware application should do it. System A should have no idea that the other parameter exists, and will certainly have no idea about how to get it.