|
Home > Archive > BizTalk Server General > June 2004 > BizTalk,Notification Services, Shaerpoint
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
BizTalk,Notification Services, Shaerpoint
|
|
| Mike Lopez 2004-06-08, 7:59 am |
| Hello.
I'm in the process of re-architecting our internal systems and am looking to
better utilize the latest MS products (which we have but don't use) and
other technologies (such as XML, SOA, and related). We are a Win2000 (soon
2003), Active Directory, SQL Server 2000, Exchange 2003, IIS, and "legacy"
system shop. One of my main goals is to eliminate home-grown software and
replace it with MS products.
I'm trying to get a handle on the various Microsoft products and the
different roles that they play in an enterprise setting.
In particular I'm curious as to how BizTalk, Notification Services, and the
Sharepoint services (WSS/SPS) would work together in such a setting, and how
they compliment each other (if they in fact do).
Can someone shed some light on the roles these products play in an
enterprise setting?
One more question if I may: Is it overkill to implement BizTalk for usage in
our internal systems, sort of in an EAI type role?
Thanks in advance,
Mike
| |
| Nick Malik 2004-06-09, 11:00 am |
| Notification services is a communication structure that uses the
Publish-Subscribe model of message management to handle the forwarding of
messages to people who are interested in them. This is similar to Biztalk's
model, but quite different in many ways.
First off, Notification Services is primarily targeted toward end user
technologies to receive the messages. This means connected devices of any
kind (handhelds, pagers, phones) as well as various other communication
technologies (SMS, SMTP). There is no reason that a notification can't also
go to Biztalk for routing. Note that the concept behind Notification
Services is NOT reliable messaging (where every message counts) but rather
the reduction in searching and the improvement in "information velocity."
Biztalk is an EAI tool, so if you have internal systems (whether MSFT,
Another vendor, or homegrown...) that survive your cleansing, and those
systems need to communicate, then Biztalk is an excellent tool for it.
Messages in Biztalk are delivered reliably (once and only once). They are
for business-critical content. There is support for workflow connections,
business rule management, and enterprise single-sign on (cross platform
credential correlation). The space is very different than Notification
Services.
Biztalk is not all that cheap, so make sure you know what you want to
accomplish in your integration to be able to justify it's cost. Don't just
use it to connect two systems and stop there. Biztalk is more than capable
of hosting a large number of connections between various systems. Is BTS
overkill? That depends. It depends on how your legacy apps are developed
or how they communicate, and how much data has to move. If you move 10
transactions a month, it's wild overkill :-) On the other hand, if you move
> 1 Million messages a month, as Microsoft does to run their own business,
Biztalk is an excellent choice. Somewhere in the middle is the rest of us.
Biztalk requires you to take advantage of some enterprise architecture
principles. See my article:
http://www.ftponline.com/vsm/2004_0...tments/guestop/
Sharepoint is an excellent framework tool for hosting sites that make
information and content available. Basically, Sharepoint is the "intranet
killer." A few days with Sharepoint will give a developer enough knowledge
to replace most or all of the functionality (and probably much of the "look
and feel") of your internal intranet site. The upside is that you can
easily set up the ability teams and groups to create and manage their own
information-sharing sites without the need of programming resources.
Biztalk 2004 needs to make some information available, so it does so by
configuring a Sharepoint site. You can also connect Sharepoint with any
information source, like SQL Server. This means you could tie Notification
Services to inform users to visit the Sharepoint site where information is
being made available by SQL Server, whose transactions are sourced in your
Accounting system and transmitted via Biztalk.
Note: the BTS-required implementation of Sharepoint is not exclusive. You
can easily create other sharepoint sites on the same sharepoint server that
you use to meet Biztalk's needs.
I hope this helps,
--- Nick Malik
Biztalk Bum
"Mike Lopez" <MichaelLopez@Emmerel.com> wrote in message
news:u26DOUUTEHA.3512@TK2MSFTNGP12.phx.gbl...
> Hello.
>
> I'm in the process of re-architecting our internal systems and am looking
to
> better utilize the latest MS products (which we have but don't use) and
> other technologies (such as XML, SOA, and related). We are a Win2000 (soon
> 2003), Active Directory, SQL Server 2000, Exchange 2003, IIS, and "legacy"
> system shop. One of my main goals is to eliminate home-grown software and
> replace it with MS products.
>
> I'm trying to get a handle on the various Microsoft products and the
> different roles that they play in an enterprise setting.
>
> In particular I'm curious as to how BizTalk, Notification Services, and
the
> Sharepoint services (WSS/SPS) would work together in such a setting, and
how
> they compliment each other (if they in fact do).
>
> Can someone shed some light on the roles these products play in an
> enterprise setting?
>
> One more question if I may: Is it overkill to implement BizTalk for usage
in
> our internal systems, sort of in an EAI type role?
>
> Thanks in advance,
>
> Mike
>
>
| |
|
| Wow, thanks Nick. I really appreciate the extensive answer.
I will have a look at your article.
Thanks again,
Mike.
"Nick Malik" <nickmalik@hotmail.nospam.com> wrote in message
news:d9Fxc.678$eu.133@attbi_s02...
> Notification services is a communication structure that uses the
> Publish-Subscribe model of message management to handle the forwarding of
> messages to people who are interested in them. This is similar to
Biztalk's
> model, but quite different in many ways.
>
> First off, Notification Services is primarily targeted toward end user
> technologies to receive the messages. This means connected devices of any
> kind (handhelds, pagers, phones) as well as various other communication
> technologies (SMS, SMTP). There is no reason that a notification can't
also
> go to Biztalk for routing. Note that the concept behind Notification
> Services is NOT reliable messaging (where every message counts) but rather
> the reduction in searching and the improvement in "information velocity."
>
> Biztalk is an EAI tool, so if you have internal systems (whether MSFT,
> Another vendor, or homegrown...) that survive your cleansing, and those
> systems need to communicate, then Biztalk is an excellent tool for it.
> Messages in Biztalk are delivered reliably (once and only once). They are
> for business-critical content. There is support for workflow connections,
> business rule management, and enterprise single-sign on (cross platform
> credential correlation). The space is very different than Notification
> Services.
>
> Biztalk is not all that cheap, so make sure you know what you want to
> accomplish in your integration to be able to justify it's cost. Don't
just
> use it to connect two systems and stop there. Biztalk is more than
capable
> of hosting a large number of connections between various systems. Is BTS
> overkill? That depends. It depends on how your legacy apps are developed
> or how they communicate, and how much data has to move. If you move 10
> transactions a month, it's wild overkill :-) On the other hand, if you
move
> Biztalk is an excellent choice. Somewhere in the middle is the rest of
us.
>
> Biztalk requires you to take advantage of some enterprise architecture
> principles. See my article:
> http://www.ftponline.com/vsm/2004_0...tments/guestop/
>
> Sharepoint is an excellent framework tool for hosting sites that make
> information and content available. Basically, Sharepoint is the "intranet
> killer." A few days with Sharepoint will give a developer enough knowledge
> to replace most or all of the functionality (and probably much of the
"look
> and feel") of your internal intranet site. The upside is that you can
> easily set up the ability teams and groups to create and manage their own
> information-sharing sites without the need of programming resources.
>
> Biztalk 2004 needs to make some information available, so it does so by
> configuring a Sharepoint site. You can also connect Sharepoint with any
> information source, like SQL Server. This means you could tie
Notification
> Services to inform users to visit the Sharepoint site where information is
> being made available by SQL Server, whose transactions are sourced in your
> Accounting system and transmitted via Biztalk.
>
> Note: the BTS-required implementation of Sharepoint is not exclusive. You
> can easily create other sharepoint sites on the same sharepoint server
that
> you use to meet Biztalk's needs.
>
> I hope this helps,
>
> --- Nick Malik
> Biztalk Bum
>
>
> "Mike Lopez" <MichaelLopez@Emmerel.com> wrote in message
> news:u26DOUUTEHA.3512@TK2MSFTNGP12.phx.gbl...
looking[vbcol=seagreen]
> to
(soon[vbcol=seagreen]
"legacy"[vbcol=seagreen]
and[vbcol=seagreen]
> the
> how
usage[vbcol=seagreen]
> in
>
>
|
|
|
|
|