Does anybody have an idea what SOA Governance is all about? What is the difference (or correlation) between SOA Governance and IT Governance? and How can it be applied using SOA platforms available in the market?
Can a project built on SOA platform be successful without applying SOA Governance? How? I am talking here from a practical point of view.
At its most basic, SOA Governance is about managing services. At its most base level, you might think about topics such as:
Managing the version of services - Service 1.0 is currently deployed, but now we've deployed Service 1.1. How do we redirect clients from the old service to the new one?
Giving services a lifecycle: a service is in 'development'. Now it's completed and been QAed, we'll want to transition it to 'production'. We need to have a way to add metadata to the service to indicate that - what if we want to remove our development services but keep our production ones running?
Obviously there are others - there is no hard-and-fast governance solution for any environment. The degree to which governance is necessary is a hot topic of debate.
Disclaimer: I work for IBM as a WebSphere consultant so my thoughts are influenced by that and the IBM product most often suggested as an answer to the above questions, WebSphere Service Registry and Repository.
SOA governance is a subset of IT governance where you focus on defining, delivering and enforcing IT governance rules using SOA. It is also organization wide, otherwise it is practically pointless except as an exercise.
IT Governance which is a subset of Corporate governance and should have at least a policy of providing Business Value in things that the company does.
Here's an example:
Provide Business Value (corporate policy)
by providing consistent quality of service (corporate policy)
by providing metrics for each procedure (IT governance)
by providing transaction times for each service operation (SOA governance)
As you drill down things get more technical and actually easier to enforce.
SOA/IT/Corporate governance is basically analogous to the law makers (those who define the rules), the judge/police (those who enforce the rules), the rest of us (those who deliver within the rules).
"have an idea what SOA Governance is all about?..."
Andrew Ferrier's response answers this question pretty well. Like any other asset (if you look at services that way), services governance is about controlling the asset. It's similar to code management except on an enterprise level and generally by the business. Access control, versioning, ownership, etc... are all concepts in this space.
"Can a project built on SOA platform be successful without applying SOA Governance?"
That will depend upon your definition of success. However, if you mean can you successfully deploy SOA into an enterprise without governance (with little to no regard on how the service will be managed after it's in production), the answer is a resounding "Yes". Just be aware that at some point in the future, a deployed service in an enterprise WILL eventually be discussed with respect to re-use, accessibility, and ownership (to name a few). That's where governance comes in and you will have to do it manually.
First, let's figure out What is Governance?
Governance is the process of ensuring that an organization's resource are utilized in a manner in which they contribute to the fulfillment of an organization's goal and it is done in a transparent and measurable manner.The resources can include both people , processes or other physical infrastructure.At the heart of Governance is the concept of controlling how decisions are made.There are a number of different types of Governance:
Corporate Governance
IT Governance
Architecture Governance
SOA Governance
SDLC Governance
Why has Governance become important?
The past decade has brought to light several corporate scandals that highlight the pitfalls when decisions are made without transparency and accountability. As an example in the late 90s the corporate IT departments initiated a number of IT projects based on the whimsical notion of staying on the bleeding edge without any clear motivation on how these projects would contribute to the business.
What are the building blocks of Governance?
Precepts
People
Processes
Metrics
To find more about what is SOA Governance, Please find this post.
References
Prentice.Hall.SOA.Governance.Governing.Shared.Services.On-Premise.and.in.the.Cloud.Apr.2011.ebookmf.com
SOA Governance in Action
Service-Oriented Architecture(SOA) Governance for the Services Driven Enterprise
See Service Oriented Architecture and SOA Governance for help.
Service-Oriented Architecture (SOA)
governance is a concept used for
activities related to exercising
control over services in an SOA. SOA
governance can be seen as a subset of
IT governance which itself is a subset
of Corporate governance. The focus is
on those resources to be leveraged for
SOA to deliver value to the business.
SOA needs a solid foundation that is
based on standards and includes
policies, contracts and service level
agreements. The business is expected
to be able to use services to build
and change the organisations business
process quickly. To do so, a degree of
granularity in the services available
will be required. Consequently an SOA
increases the need for good governance
as it will help assign decision-making
authorities, roles and
responsibilities and bring focus to
the organisational capabilities needed
to be successful.
Being an employee of a large enterprise, our SOA governance approach stewards the usage of internal standards such as leveraging a common message format, ensures that all WSDL produced meets security standards such as ensuring that all attributes have regular expressions attached to them for validation and aligns with our strategic business architecture.
SOA Governance can also be two-tiered. Often you spend your time on its internal aspects, but SOA was also meant to address these issues among partnered organizations that may be under entirely separate corporate/government "tents."
Internal stadnards must bend to the will of the larger Community, at least at points of interconnection.
From a practical point of view...
Does anybody have an idea what SOA Governance is all about?
It involves:
Defining design standards and governance infrastructure for services (e.g., SOAP and REST services). The governance infrastructure is mainly a service registry.
Establishing roles, responsibilities, and processes regarding the lifecycle of services. Example: a service custodian is responsible for adding a description of a new service to the service registry; a schema custodian will enforce the canonical schema design pattern.
Establishing a SOA Governance system, which is in practice a document with all governance directives. The document should be approved by upper mgmt (e.g., CIO).
What is the difference (or correlation) between SOA Governance and IT Governance?
IT governance is broader and spans from procurement of workstation to training software developers. SOA governance focuses on software services, such as SOAP and REST services. IT governance should encompass SOA governance, if the organization has adopted SOA.
How can it be applied using SOA platforms available in the market?
Platforms that support the development and execution of "SOA services" are necessary, of course, for creating and running SOAP and REST services. But the fact that you're creating SOAP or REST services doesn't mean you're following service orientation. Likewise, using ESBs or orchestration servers doesn't mean you're doing SOA the right way. Successful SOA is not only about technology, but also about governance and architecture (understanding and applying service orientation principles and SOA design patterns).
Can a project built on SOA platform be successful without applying SOA Governance?
Yes, it can! The main goal of SOA governance is to enable long-term benefits due to reuse, interoperability, standardization and other nice properties of services across applications. SOA governance helps your organization to have enterprise focus rather than application focus.
Related
they have many common features. but how the difference?
MOM allow asynchronous while SOA does not, this is the only difference?
SOA, Service Oriented Architecture, is an architecture that defines how to structure access to business information between different applications. In a nutshell, usually, one application needs something done with a piece of information (may it be an orderfile or anything else) that application has a need. Another application may be able to do the corresponding processing of that piece of information, hence it has a capability. The first application then Consumes the Service of the second application, which Provides the Service (no matter the underlying technology, which can be anything such as JMS, HTTP/SOAP, HTTP/REST, EMail, FTP, etc.). To make this work, a Contract between the first application and the Service has to be defined which clears such things out as Message Format (XSD or similar), Protocol (HTTP/SOAP? JMS?) etc.
MOM, Message Oriented Middleware, on the other hand is just a family of software/middleware platforms. They are actual implementations, and not a high-level concept like SOA. They can be used to implement a SOA architecture, an Event Driven architecture or other architectures. Usually, MOM enriches a set of applications with asynchronous messaging where a MOM server stores and forwards the messages. Often things such as transactions, guranteed delivery, fail-over, loose coupling and load balancing are built into MOM implementations. Examples of MOM are IBM WebSphere MQ, Apache ActiveMQ, RabbitMQ, JBoss HornetQ, etc.
Message oriented middleware (MOM) is a type of technology where as SOA is a type of architecture. Even though a lot of people think about web-service when they talk about SOA, you can use MOM to implement it as well (in fact in many cases that's the better option)
What are the differences between service orchestration and service choreography from an intra-organization point of view.
Basic technologies (such as XML, SOAP, WSDL) provide means to describe, locate, and invoke services as an entity in its own right. However, these technologies do not give a rich behavioral detail about the role of the service in more complex collaboration. This collaboration includes a sequence of activities and relationships between activities, which build the business process. There are two ways to build this process: service orchestration and service choreography.
Service orchestration
Service orchestration represents a single centralized executable business process (the orchestrator) that coordinates the interaction among different services. The orchestrator is responsible for invoking and combining the services.
The relationship between all the participating services are described by a single endpoint (i.e., the composite service). The orchestration includes the management of transactions between individual services. Orchestration employs a centralized approach for service composition.
Service Choreography
Service choreography is a global description of the participating services, which is defined by exchange of messages, rules of interaction and agreements between two or more endpoints. Choreography employs a decentralized approach for service composition.
The choreography describes the interactions between multiple services, where as orchestration represents control from one party's perspective. This means that a choreography differs from an orchestration with respect to where the logic that controls the interactions between the services involved should reside.
Service orchestration: you put together several services by a fixed logic. This logic is described at a single place. You can imagine a team of people with a manager doing micro-management. The manager precisly tells what, when and who should do. The team members do not care of the entire goal of the job, the manager combines the outputs into a single deliverable.
A practical example is a BPEL process. BPEL process contains the logic, can invoke several services and combine their responses into a single service response.
Service choreography: the decision logic is distributed, with no centralized point. You can imagine a home, where everybody aims for the common good and works pro-actively without micro-management. Or you can imagine a human body, where different members are interdependent and work for the common goal.
A practical example is event driven processing, where an agent is activated by an event and does its job. All the agents make a system together. There is no centralized logic.
Choreography possibilities may go farther beyond orchestration as it is more aligned with the real world.
My opinion is that we do not need to distinguish much between these two, as we need to focus on the business logic. Where a single point of logic does the job, we do orchestration. Where a problem cannot be covered by a centralized logic, we are forced to choreography anyway. That is why we often come accross orchestration in IT, whereas choreograhy remains more an academical concept and a subject for research. And very often we do choreography without actualy knowing it, as in the real world.
Since the thread is old but still writing to it for those who will stumbled here in search of this question as I did. This is much debated question in Service-oriented architecture (SOA) which needs much cleaner explanation for beginners.
Orchestration: Executable Process
Used in private business processes
A central process (which can be another Web service) takes control of
the involved Web services and coordinates the execution of different
operations on the Web services involved in the operation
The involved Web services do not "know" (and do not need to know)
that they are involved in a composition process and that they are
taking part in a higher-level business process.
Only the central coordinator of the orchestration is aware of this
goal, so the orchestration is centralized with explicit definitions
of operations and the order of invocation of Web services.
Choreography: Multi-party Collaboration
Choreography, in contrast, does not rely on a central coordinator.
Rather, each Web service involved in the choreography knows exactly
when to execute its operations and with whom to interact.
Choreography is a collaborative effort focusing on the exchange of
messages in public business processes.
All participants in the choreography need to be aware of the business
process, operations to execute, messages to exchange, and the timing
of message exchanges.
Choreography vs. Orchestration
From the perspective of composing Web services to execute business
processes, orchestration is a more flexible paradigm and has the
following advantages over choreography:
The coordination of component processes is centrally managed by a
known coordinator.
Web services can be incorporated without their being aware that they
are taking part in a larger business process.
Alternative scenarios can be put in place in case faults occur.
Services can be distinguished between atomic services and services composed of other services. Such compositions are called "orchestration". Sometimes workflow, sometimes business process. For instance, BPEL is an orchestration language, but calls itself "business process execution language".
There is no requirement that services need to be hierarchically composed. That means, two services may talk to each other. The protocol running between them is called "choreography". It may be two services, but usually, there are more than two services involved. Each service in a choreography may be seen as orchestrator of the partner services. Each service taking part in a choreography may be realized as orchestration/workflow/process.
An orchestration shows the complete behavior of each service whereas the choreography combines the interface behavior descriptions of each service.
A good scientific article distinguishing choreography, interface behavior, provider behavior, and orchestration is the following one:
Dijkman, R. & Dumas, M. Service-oriented Design: A Multi-viewpoint Approach International Journal of Cooperative Information Systems, 2004, 13, 337-368
Andrei and others did a good job explaining what is orchestration and what is choreography. For the software architect choosing between these two alternatives, it is also important to compare them with respect to different qualities.
Orchestration pluses over choreography
Reliability: Orchestration platforms have built-in support for error handling and transaction management (compensating transactions). In choreography, custom-developed workflow and error handling tends to be more error-prone. Also, choreography is often event-driven and much of the processing is asynchronous. Therefore, choreography may require undo/correction events that add complexity to the solution.
Modifiability: Creating and changing process workflows and complex service compositions is easier in the visual BPM tools found in orchestration platforms. You gain in "process visibility".
Choreography pluses over orchestration
Performance: Orchestration incurs a performance overhead due to workflow script interpretation and the additional layer of the orchestration platform itself.
Cost: Choreography does not require additional middleware or language, which have associated learning curves and governance burden.
EDIT
An orchestration solution might introduce a SPOF if the orchestrator element doesn't employ a mechanism for high availability. Thanks #Deepak por pointing this out in a comment.
Orchestration is useful when you have control over all the actors in a process - when they're all in one domain of control and you can dictate the flow of activities. This is of course most often when you're specifying a business process that will be enacted inside one organisation that you have control over.
Choreography is a way of specifying how two or more parties - none of which has any control over the other parties' processes, or perhaps any visibility of those processes - can coordinate their activities and processes to share information and value. Use choreography when coordination across domains of control/visibility is required. You can think of choreography, in a simple scenario, as like a network protocol. It dictates acceptable patterns of requests and responses between parties.
Another way to look at Service Orchestration vs. Choreography:
- Service Orchestration: Around a Business Domain.
- Service Choreography: Among multiple Business Domains.
I'd say choreography is well suited internally for highly decentralized organizations. You won't need a central business process executor. This facilitates independent growth and development by each of organization sub-units.
(I subscribe to this interpretation of orchestration vs. choreography question:
http://geekexplains.blogspot.com/2008/07/ways-of-combining-web-services.html)
One can use both choreography and orchestration is the same system as we have done in our product. Various actors performing various tasks dispatched to them are choreographed by the event pub/sub system via events they generate. For example, when a prime mover carrying a container arrives at a warehouse, that event, which is subscribed by the warehouse manager app, prompts the warehouse manager to activate the resources to unload the cargo.
But when exceptions happen, such as the forklift to carry the load breaks down, that event starts an orchestration engine (a workflow processor) to orchestrate the task for various actors as per the exception handling workflow to handle the exception.
In orchestration, there is a conductor and there are instrument players. Players play according to how conductor conducts. If conductor is replaced, the harmonic expression will be different i.e. it is still the same play (service) but with a different outcome. For example, to provide a financial arrangement proposal, the orchestration service will conduct by asking (invoking) each player (entity or utility service, e.g. credit check) to play (return results or adjust/update its playing) according to conductor's template (business rules).
In choreography, there is a choreographer and there are groups of dancers. Choreography is a direction, but each group of dancers is autonomous in how to realize that direction.
Both orchestration and choreography are two philosophies of process formalism at large scale, i.e. collaboration spaces. A collaboration space is a formal representation for an industry, for example health industry, food industry, automotive industry or ... . So you should have some service providers at small scale able to speak some language of communication before you decide to orchestrate them or use choreography to supply some demand meaningful to end-consumer.
Orchestration typically follows what has been famous as middleware in distributed systems. Some good tooling examples within IT industry can be Juju, Zapier IFTTT. You have centralized control, auditory, modification and trouble shooting over services you consume.
Choreography is more decentralized than orchestration in the sense that it accepts more autonomous collaborators. For example bitcoin network is a collection of service providers called nodes which collectively provide a Defi service namely distributed ledger functionality to its service end-consumers. But this does not have any centralized authority in charge, and there is no total-view over whole network. There is just a consensus machanism that if respected candidate service provider joins the network and participate in end-consumer service provision. Anywhere you need to attack trusted third party and its side effects such as corruption, an orchestration would not suffice.
Again any collaboration among actors in any industry can be subjected to orchestration or choreography, so I hope limiting examples only to IT industry is not misleading.
Also I can add, naming suggests analogy between the two and stage performance. In an orchestra, every instrument player is harmonized with other team members if he/she follows the single conductor. On the other hand analogous to stage dancing in choreography there is no conductor, each stage dancer only harmonize himself/herself with his/her partner (better if spoke as peer), with no single point of harmonization leadership. But still both present harmonization to viewers.
I am curious if it even makes consider BizTalk for the implementation of a pub/sub messaging architecture (basically what you can do with NServiceBus or MassTransit is all I really need). My manager tends to want to stick with frameworks provided directly from Microsoft and so as part of my due diligence as to which one to use I need to give a good set of pro/cons for both sides. Any guidance would be greatly appreciated!
One of the major cons of a Broker is that it is very difficult to version and upgrade. You would have to stop the flow of messages to upgrade a particular endpoint(s). A Service Bus allows endpoints to be autonomous and be upgraded independently.
Then there is a difference in terms of scale. With a Broker the tendency is to scale those up(vertical) versus a Service Bus which is built for scaling out(horizontal). You would also have to make the Broker highly available through some sort of HA setup(clustering usually). This combined with the cost of software to do so can become pretty cost prohibitive.
NSB in particular will be offering a paid support model so if your manager is nervous about not having someone on the other end of the line when something goes wrong, you can buy into support.
Biztalk is a broker and is more suited for EAI within the boundaries of different business services. A servicebus is fundamentally different. A comparison can be found here:
http://docs.particular.net/nservicebus/architecture/nservicebus-and-biztalk
If you can share some of your requirements I might be able to give some more guidance.
It's important to note that BizTalk is a server product for Enterprise Application Integration (EAI -- as Andreas mentioned). It's more involved and complicated than a framework.
Microsoft does have the Enterprise Service Bus Toolkit available to use within BizTalk, so that you can call your BizTalk environment your ESB. What they consider "ESB" may not be what you consider ESB. You can take a look at their ESB Toolkit page (http://msdn.microsoft.com/en-us/biztalk/dd876606.aspx), but it includes things like:
Dynamic (i.e., at run-time) message
transformation and translation.
Message routing can be content-based, itinerary-based, or context-based, and determined at run-time.
Of course, the publish-subscribe pattern is not the same thing as using a service bus.
BizTalk does do pub-sub well, whether or not you use the ESB Toolkit. It's extremely simple to publish a single message to the BizTalk "Message Box", and have the message routed to any and all subscribers. The pub-sub solution means that BizTalk acts as a broker, but this helps guarantee that messages do not get missed, and all messages are tracked. A BizTalk pub-sub solution has built-in extensibility points that allow us to add, change, or remove endpoints without impacting the rest of the solution.
All that being said, your requirements may not dictate extensive message reliability, monitoring, and tracking, so it could be that BizTalk is not the best fit for you. It is a large investment, and since the product can do so many different things all at once, it can be daunting at a first glance.
A new book was just published call Applied Architecture Patterns on the Microsoft Platform, which covers much of this. One of that book's authors, Richard Seroter, also published SOA Patterns with BIzTalk Server 2009, which would be essential reading if you do decide to go with BizTalk for your company.
I'm with Andreas on this - BizTalk is generally more suited to 'value add' integration and business process management, rather than ESB type activity. BizTalk is good at:
BPEL
Long Running / Compensated Transactions
EAI
Brokering / Mapping
Protocol changes (MQ to WCF, Flat File to SAP etc)
EDI, RFID
However, efforts have been made to use BizTalk as a service bus, notably the ESB Toolkit
I am looking into architectural patterns, Enterprise Services Bus (ESB) precisely. Upon reading this article Enterprise Integration, and with little to no experience I am wondering if BizTalk has is a ESB or is it just a EAI (Hub/Spokes or Bus)?
I found this NServiceBus and Biztalk, describing BizTalk as a central message broker.
Taking other ESB frameworks into account (NServiceBus and Rhino Service Bus). These frameworks have no central point to process messages.
Is Biztalk a EAI rather than an ESB?
Many thanks
BizTalk is punted by Microsoft as having ESB capabilities - see the BTS ESB toolkit
However, the term 'ESB' covers a very broad field, and there is a lot of subjectivity about an exact definition of an ESB. IMHO there are weak points in BizTalk's claim to be comprehensive as an ESB (in a > 2010 definition of the term).
BTS originated in the Hub-and-Spoke EAI era, before ESB became widespread.
BTS is more suited toward asynchronous processes than synchronous processes - latencies will vary depending on load on the system, throttling state, etc.
BTS is cumbersome when it comes to ease of versioning of services and schemas (new deployment is needed)
BTS is cumbersome when it comes to management of MANY services (e.g. Using BizTalk as a facade for all 5000 of your corporate SOA / Web Services will be painful)
FWIW we have found BTS a good fit for:
all of our synchronous and asynchronous EAI (i.e. formalized integration contracts between major LOB systems, and with trading partners), and the large number of adapters assists with integrating a wide number of protocols.
For Business Process and Business Monitoring capabilities
Addressing transactional and delivery reliablity - Biztalk has capability to retry, tracking and resumption of Suspended messages, which is useful over unreliable networks or when it comes to integration with unreliable systems.
Update, with some further comparative experiences
BTS is very centralised - ultimately, even a multi-server BizTalk cluster / group is dependent on Sql-Server. Queue based ESB products tend to be more decentralised (logically and physically), so loss of a few endpoint or queue servers should not pull the whole enterprise down.
Many queue based ESB's are built on open source technologies, with an eye on avoiding single vendor lock-in
Many contemporary ESB's seem to take a commodity-computing approach to scale out. Scaling out with products like BizTalk can become expensive.
On the plus side, the monitoring and administration capabilities of commercial offerings like BTS should not be underestimated - make sure any ESB you are considering has adequate auditing, instrumenting, retry, and diagnostic (WMI / SNMP / SCOM etc) capabilities - you'll need a dashboard to monitor the health of your bus, and there is nothing worse than not knowing where a message went. Here, centralisation administration and diagnosis is a plus.
BizTalk is a messaging and workflow orchestration platform, on which you can build ESB behaviours and capabilities. To make this easier, and standardise ESB implementation on BizTalk, Microsoft released the BizTalk ESB Toolkit - a set of guidelines, patterns and code.
The concepts of EAI and BPM have been around for a while, so there are many companies that have leveraged BizTalk to create solutions to these problems. Companies that host a full ESB on BizTalk server are far fewer, and adoption has certainly slowed in the advent of WCF/WF/NServiceBus and, of course, Azure Service Bus.
So in summary, BizTalk out of the box is nether EAI or ESB, but can do both with a number of developers applied to the problem.
By "EAI or ESB" I'm assuming you wanted to know if BizTalk follows the Hub&Spoke or the Bus architecture.
From an architecture patterns perspective, integration solutions roughly fall under one of the two patterns-
The Hub and spoke:
This involves a centralized message broker sending out messages to various receivers, while all the senders send their messages only to this broker.
Thus neither the senders nor the receivers need to be aware of each other.
This is typically what many people refer to as EAI (although it is absolutely possible to implement an EAI solution that follows the BUS pattern).
Solutions following this pattern are easy to develop and administer. All the routing logic is centrally managed at one place - in the hub.
But as you would have guessed, this has a glaring drawback - single point of failure. If the hub crashes everything comes to a halt. Also, this model doesn't scale very well.
BUS:
Enterprise Integration solutions developed around this pattern are generally referred to as ESB. There is no intelligent central authority here. All senders publish their messages on the bus. The receivers need to be intelligent enough to determine which messages are intended for them and take them off the bus.
Thus the senders and the receivers need only be aware of the bus. But here the routing logic is spread across the receivers so there is no single point of failure. Also this model is highly scalable. However such solutions are quite complex and difficult to administer.
Coming to the question which pattern does BizTalk follow- it is a hybrid of both these patterns.
the Hub-like appearance is very obvious with its centralized Messaging Engine, and a central MessageBox database. This gives one the simplicity and ease of administration which is typical of the hub approach.
But if you look at the BizTalk architecture, one can have a Host with its Host Instances spread across multiple servers. It is also possible to have the different BizTalk databases like MessageBox, Tracking, Ent SSO etc. configured on different servers. This makes BizTalk solutions more scalable and tolerant to faults than the run-of-the-mill hub implementations - which is a behavior usually attributed to the bus approach.
Hope this answers your question.
BizTalk is certainly an ESB. EAI is more of a loose concept - BizTalk can certainly be deployed to support EAI, and it can also do a lot more.
BizTalk is more than an ESB but certainly fits the bill. This link is a little old, but answers your exact question.
EDIT: Here is a more-recent MS link that gets into specifics of implementation.
BizTalk can be used as both EAI and ESB.
As for ESB, the BizTalk server architecture is publish-subscribed, a single message can be published to the messagebox which acts as the messaging backbone bus. That message can be received by one or more destination systems that are subscribed to that message. Of course there more capabilities and features that you can get by using BizTalk server like the mapper tool and the use of pipeline components for example.
For use as EAI, BizTalk offers you orchestrations that manage the business logic, LOB(Line of business) adatpers to connect to systems(also legacy), mapper tool, rules engine, and a lot of what you need in order to integrate the different systems in or outside your company.
Absolutely! Biztalk comes from an EIS background, which makes perfect sense for ESB as an infrastructure backplane for service-oriented architectures that span hybrid technical platforms.
At a previous company we chose Biztalk in preference to the IBM ESB product for reasons of functionality and lower cost.
It is Microsoft, so you get what you pay for, but still well worth looking into.
Biztalk Server withot "ESB Toolkit" Is not an ESB.
Because of the following:
Is a contract first, need to build you message types first.
Need to Plan the whole scenario first to minimize the impact of changes.
Changes requires Deployment which increases downtime.
Regarding to your qustion, Yes BizTalk Server is EAI Product
I agree with most of what's said here. It's a stretch to pitch BizTalk as an all inclusive EBS solution even with the EBS toolkit.
To address a couple points made here ...
•BTS is more suited toward asynchronous processes than synchronous
processes - latencies will vary depending on load on the system,
throttling state, etc.
BizTalk hosts with unchanged defaults are not ideal for a low latency. But those hosts are meant to be tuned. Out of the box configuration is not suitable for any situation where throughput is needed. In my experiences of walking into an organization where BizTalk has been shunned there is always an untuned single host setup sitting in the middle of it. It is somewhat analogous to making tables in a dbms with no indexes, getting performance issues and saying the dbms itself sucks.
•BTS is cumbersome when it comes to ease of versioning of services and
schemas (new deployment is needed)
Like with any development platform you need to have a deployment strategy. If schemas have version in the namespace you do not need to redeploy anything. A new version maybe deployed without taking anything down.
As far as the service endpoints are concerned BizTalk can host web services without the use of IIS (BizTalk can use HTTP.SYS to host just as IIS does). To host an inprocess service in BizTalk is merely a matter of importing a binding which can be done without stopping anything in BizTalk. In those end points you can implement versioning as well (like http:.../thing/v1, http:.../thing/v2, etc.).
Anyway ~5 years have passed I'm sure you have hit a conclusion before now :)
BizTalk can do both ESB and EAI, depends how you design your biztalk applications.
I have been looking a lot at SOA recently. Isn't CORBA exactly the same thing as SOA?
In addition to the fact already mentioned, that SOA is an architecture, and CORBA a specific implementation.
CORBA doesn't implement SOA
the main difference is that CORBA is Object Oriented or Component Oriented and SOA is Service Oriented
The main technical difference (in my opinion) is that in SOA you pass messages (or data objects) and in CORBA you can pass generic objects (which can have methods)
so although you can implement SOA using CORBA (by limiting you self to a subset of the functionality), the standard way of using CORBA isn't service oriented.
The difference between CORBA and SOA is that CORBA is a specific technology, whereas SOA is a style of architecture.
SOA as a concept has been around for years, but was only more recently named as such. There are many technologies that can be said to implement SOA - either completely, or aspects of it. CORBA could be said to be one of them, although the term wasn't around when CORBA was created.
CORBA certainly implements are large part of the SOA surface area, but I don't think you could say it does so completely (whatever that means). SOA can be a bit vague.
While there is no "official" definition of SOA, part of the point of it is to decouple the various services from each other. This includes possibly decoupling the implementation (platform and technology) used in the service. As an example if one exposes a service via WebServices, any client be it java/python/.Net etc... could consume this service - but utilizing a RPC/remote procedure call framework will often tie you into a particular platform/implementation in order to call the service.
Corba does offer some of what SOA promises, but is at best a subset of what SOA is "meant to be"
The main difference though is that SOA is a general architectural concept, while Corba is a technology implementation of the RPC/Remoting concept
Not really. SOA is an architectural style while CORBA is a particular technology with which you can implement SOA.
CORBA and SOA are both architectures. It is wrong to say CORBA it is an implementation. It is not. It is an architecture, a vision of systems build with objects. SOA is also an architecture, a vision of systems build with services. They both are ways to organize your systems as a collection of either objects or services. There are specific implementations for CORBA as well as for SOA.
They are both technologies. They both give you receipts and recommendations for structuring your systems and for managing complexity. There are tools developed by third parties to support these technologies for both of them.
The objects in a Common ORB Architecture (CORBA) provide services so you can think of a translation between Service Oriented Architecture (SOA) and Common ORB Architecture. They are not the same thing, but one can imagine implementing a software system with either the one or the other, making them, from a certain point of view, equivalent.
They are not the same thing in the same way as Object Oriented Programming and Structured Programming or Functional Programming are not the same thing, although one could use any of the above mentioned programming styles to implement a certain functionality.
They are inherently different because one depends on the technology (CORBA) and the other doesn't.
CORBA is an open standard developed by the OMG (Object Management Group) for the use ORB (object request broker) middleware with a great focus on interoperability (software platforms, hardware platforms and programming languages).
SOA is a style of software design where services are provided to the other components by application components, through a communication protocol over a network. The basic principles of service-oriented architecture are independent of vendors, products and technologies.
I had the same doubt as you because the definition of SOA is too broad and I can see many concepts of CORBA can be mapped naturaly to SOA's terminology. For example in CORBA, clients (objects) ask to servers (also objects) to do some work through a communication protocol over a network. Moreover CORBA implementations provide general services like logging and event support. I think this link summarizes the relation between CORBA and SOA:
The first service-oriented architecture for many people in the past was with the use of Object Request Brokers (ORBs) based on the CORBA specification. The CORBA specification is responsible for really increasing the awareness of service-oriented architectures.