BizTalk Server and SOA Software Together, Part I

[Series Links: Part I / Part II / Part III / Part IV]

Recently, the company I work for purchased a web services management platform solution from SOA Software. This post starts a short series where I will highlight the key features of the platform, and, how to integrate BizTalk with this solution.

SOA Software provides us with that “last mile” web services capability set that should help my organization realize our vision of a truly enterprise SOA. Specifically, SOA Software provides us with four key functions:

  • Centralized management, including automatic service discovery
  • Fully UDDI 2.0 compliant service registry (UPDATE: UDDI 3.0 compliance as well)
  • Application of service “policy” via configuration
  • Full-featured monitoring and customized alerting

In this first post, I’ll do a very high level overview of each of those functions.

Centralized management, including automatic service discovery
Each of our web servers will have a SOA Software “discovery” agent installed which detects when new web services are deployed to the box. The supported application servers include Websphere, Weblogic, Tomcat and IIS. So this plays very well in a Microsoft, or non-Microsoft shop. Once a web service has been discovered, it can be centrally managed. “Managing” a service can mean applying security policies, establishing service level agreements, apply access/deny rules, and more.

Fully UDDI 2.0 compliant service registry (UPDATE: UDDI 3.0 compliance as well)
It’s nice that SOA Software provides us a service registry out of the box. No need to purchase and integrate another company’s registry solution. The registry has a fairly rich “search” capability where I can search for service by name, usage, category and more.


What are categories? Once a service is managed, you can group the service using user-defined categories. Much nicer than having a registry that just shows a dump of every service with no way to organize them.

Application of service “policy” via configuration
While you could potentially do without the previous two features (even though it makes life significantly easier), the SOA Software Policy Manager service is where you really get your money’s worth. Without TOUCHING the code or configuration files of a deployed service, you can apply a “policy” to that service. Because each service is hosted on a web server with a SOA Software management agent, all service requests can be intercepted. SOA Software acts as an intermediary between the service client and service provider. A service policy may include:

  • message logging
  • authentication
  • compression/decompression
  • encryption/decryption
  • validation
  • much more …


Those are examples of “management” policies. I’ll also show you “SLA” policies, and more in the later post. Each method of a given service can have a different policy attached. I can’t stress how cool this stuff is. When someone builds a service, they don’t have to do anything special for this service management capability. All of it occurs at the management point, not development point.

Full-featured monitoring and customized alerting
A robust monitoring module is so important if you want to evaluate service usage trends in your organization. I can capture the payload of the SOAP messages coming in and out of the services. This includes the ability to see the services before/after policies have been applied. The view below shows my message after a SAML token has been applied.

I can also see various reports about service response time, usage and more. So far, that is just passive reporting. I have to go query for data to discover a problem. What if I have a SLA set up, and NEED to be very proactive about service interruptions or problems? You can subscribe to alerts already configured, or, create your own. I can build an SLA Policy to ensure that if response time goes above a certain amount, or the number of SOAP faults exceeds an acceptable amount, then send me an email message.

In the next few posts, I’ll show more details about these key subsystems. Finally, I’ll show how BizTalk can call one of these SOA Software-managed services. The service *caller* requires a bit of code (in order to inject the headers necessary to conform to the policies), but SOA Software has made it fairly straightforward.

Technorati Tags: ,

About these ads


Categories: BizTalk, General Architecture, SOA

1 reply

Trackbacks

  1. Geir Morten Allum's MS application platform hvor, hva, når, hvorfor, osv... : ESB Guidance August 2007 (CTP3) Release og SOA Software governance for BizTalk Server

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 264 other followers

%d bloggers like this: