BizTalk, From Hub/Spoke to ESB

Question

 

Hi,

 

  In your opinion, what do you think about running BizTalk 2006R2 as ESB?

 

  What features of ESB is founded in Vitria, WebLogic, Tibco, BEA, and Web Methods and what is not founded?

 

  In your opinion, do you think that the ESB Guidelines by Microsoft is enough to run a full ESB solution?

 

Thanks,

Firas

Answer 1

BizTalk definitely has its roots as an EAI tool.  If you look at how industry analysts define ESB capabilities, you get:

• Message transformation
• Message routing (often on subject/itinerary or content)
• Quality of service and reliable delivery
• Message validation
• Environment/application adapters
• Support for a variety of communication patterns (pub/sub, sync or async, etc)
• Service aggregation
• Rich web services support

There are of course more (and less) things that a given vendor offers. And some folks would probably argue that my list above doesn't include what they consider "core" ESB stuff.  For my company, we use BizTalk as our ESB.  It meets our criteria and business need, and we don't have a pressing need for some of the additional features offered by other vendors.

 

"Full ESB solution" is open to interpretation.  Seems like its best to look at what you need in your environment, and consider the platform and feature set most important to you versus going with the vendor who shouts "ESB" the loudest.

 

Answer 2

I agree with Richard.

 

I would add to the list:

 * unified message format

 * unified error handling

 

but fully agree with conclusion.

 

"ESB Guidelines by Microsoft" is good to consultants trying to "sell" project with bigger budget.

In reality it is like communism. It works well for big, standardized processes. It is rigid and hard to change. It works for mature companies and processes where you know all steps and formats.

 

Answer 3

Thanks guys for your information

Answer 4

Surely the major factor is decentrilization, something biztalk at present cannot provide.

 

It will always be hub and spoke. For example, we cannot move the transformation service away from the bizTalk runtime. We cannot create a seperate routing framework. Are just 2 examples.

 

I do not think people realise that what they discuss is just standard hub-spoke. it is only when we can fully distrubute the system in any way and dynamically plug into the architecture do we have an ESB.

 

I don;t think MS can do this at present... but the future may be interesting?

 

TM

 

Answer 5

etones wrote:

Surely the major factor is decentrilization, something biztalk at present cannot provide.   It will always be hub and spoke. For example, we cannot move the transformation service away from the bizTalk runtime. We cannot create a seperate routing framework. Are just 2 examples.   I do not think people realise that what they discuss is just standard hub-spoke. it is only when we can fully distrubute the system in any way and dynamically plug into the architecture do we have an ESB.   I don;t think MS can do this at present... but the future may be interesting?   TM

 

Not sure the decentralization is in the ESB feature list at all. Of course if we have such list

Answer 6

Thank you guys for your participation,

 

But you know guys! I don’t think that BizTalk2006R2 is ready to be run as a full ESB. I think i can't accept to sell half solution to my customers!

 

ESB Feature list in my opinion:

 

There are new concepts that are found just in ESB , they are:

 

1-     Districted Mapping, Receiving, and sending – this is partially covered by WCF

2-     Enforcing loosely coupled pattern, BizTalk is fixable to choose what pattern you want.

3-     SOA, BizTalk and Microsoft are great here.

4-     Enterprise Dashboard and Tracking, for the enterprise level I think HAT is not enough at all, BAM needs a lot of development and this feature must be supported out of the box.

5-     Flexibility & Expandability & Fault Recovery, it’s really easy to span BizTalk to run over many server, but I think the problem is from the SQL that can be run just on one server! Even though the SQL active-active installation is not recommended. Comparing that with Oracle that can be run over many servers stimulatingly to share the database load over the server farm.

6-     Controllable Security, I think BizTalk is great here.

7-     Enterprise level administration, I think MMC apps and ADM is more than enough for that.

 

 

At the end, I think ESB guidance is not enough to operate BizTalk as ESB!

 

-Firas

 

 

Answer 7

Firas,

 

See http://www.theserverside.net/tt/talks/videos/ScottWoodgate/interview.tss?bandwidth=dsl , interview with Scott Woodgate.

 

He mentioned "...Enterprise Service Bus is a term that's really been surfacing probably in the last year or so and you haven't heard a lot of noise from Microsoft on enterprise service bus and so, one of the things we are doing here at TechEd is really being a little clearer on enterprise service bus. What is Microsoft's story there? And the first thing I want to say is, if you're a developer, architect or customer and you've been considering enterprise service bus because you have been talking to one of key analysts like Gartner or one of our competitors, then Microsoft can absolutely offer enterprise service bus capabilities. The combination of BizTalk Server and web services stack today offers that and then BizTalk Server and Indigo in 2006 timeframe really compete the web services stack. ..."

 

I'm thinking about his words several years. Everytime when the ESB is resuscitating I see a lot of sales blah-blah-blah and a little technology information. Why?

 

I takes several years to study many BizTAlk features, to make it works for good.

ESBs on the BizTalk base: 

are more complex and more RIGID. They could be used in small niche areas.

ESB is like Communism.

You could make all people work in the same manner and put on the same clothes. Do you want it?

You could make all messages have the same format and follow the same rules. Do you want it?

 

BizTalk is flexible in each joint. Following some architectural decisions we could make BizTalk working like any others ESB on market.

 

ESBs not on the BizTalk base: If they are more simple then BizTalk, let see...

 

 

 

Answer 8

 

http://msdn.microsoft.com/en-us/library/ms978583.aspx - kind of "official view by MSFT" what the Service Bus is.

 

Answer 9

Thank you Leonid  for your great feeds

Answer 10

 

 Microsoft is so commited to having BizTalk as an ESB that they have the ESB guidance that shows you how to implement most of features above with BizTalk.

 The next version of ESB guidance is going to be released together with BizTalk R3 and I assume it will address a few other features still missing from the ESB guidance.

 I don't believe decentralization is a major ESB requirement, at least not when compared to dynamic routing, transformation services, etc. Besides, moving the transformation service to the end points might mean that each endpoint might need to know how to integrate with each of the other endpoints.

Answer 11

For those of you in the UK you might be interested to know that the next session of the UK SOA/BPM User Group in October will have a session about the ESB Guidance package for BizTalk.

 

If your interested in coming along find out more here: http://sbug.org.uk/events/default.aspx

 

Answer 12

Hi Michael,

 

  Thank you to mention the event. I would love to come, but I doubt that I can make it.

 

  Would you please provide more materials after the event?

 

Thanks,

-Firas

Answer 13

The Esb Guidance actually includes these two features: a ws that ask biztalk to do transformations (without hitting the msgbox) and a resolution framework that allows routing/processing of messages to be made according to configurations stored in one of 5 repositores (rules, uddi, etc.).

 

If you check the Wikipedia definition of ESB, you'll find about 90%+ coverage of ESB features in BizTalk Server.

Answer 14

Hi, I want to add some goals for ESB Guidance with BizTalk Server 2006 R2, and it might be helpful:

The main goal for Microsoft ESB Guidance is to support a loosely coupled messaging architecture. This can be handled by:
1- Providing itinerary-based service invocation that supports lightweight service composition at the time of message publication.The Itinerary mechanism dynamically resolves service endpoints and mediation requirements, and routes messages using a registry or the rules engine.
2- The ESB Guidance support dynamic resolution of endpoints and maps using the Microsoft ESB Guidance Resolver and Adapter Provider Framework.

Here is a webcast about ESB Guidance

https://www112.livemeeting.com/cc/microsoft/view?id=BTSBAG-112&pw=35DKTQ

If anyone need how the itineraries and messages work in BizTalk using ESB Guidance, please send me, I applied some examples, And I think it will be helpful to share.

cheers,

Zaki

Answer 15

> I don't believe decentralization is a major ESB requirement, at least not when compared to dynamic routing, transformation

> services, etc

Possibly, but to quote David Chappell:

"However, integration brokers are usually highly centralized and monolithic in nature. The ESB provides these integration capabilities as individual services that can work together in a highly distributed fashion, and can be scaled independently from one another."

Answer 16

colinjack wrote:

> I don't believe decentralization is a major ESB requirement, at least not when compared to dynamic routing, transformation > services, etc Possibly, but to quote David Chappell: "However, integration brokers are usually highly centralized and monolithic in nature. The ESB provides these integration capabilities as individual services that can work together in a highly distributed fashion, and can be scaled independently from one another."

 

As I know there is nothig in Service Broker about "centralized and monolithic". It is just pattern and there could be different implementations, and nothing wrong with decentralized and nonmonolithic" SB.

The same about ESB.

Let me know if I lost something.

Answer 17

Hi Firas

 

The materials from our UK event are at the below link:

http://sbug.org.uk/media/p/129.aspx

 

Answer 18

BizTalk as an ESB from InfoSys: http://infosysblogs.com/microsoft/2006/09/biztalk_as_an_esb_2.html