Overview of SeeBeyond for the BizTalk professional
The SeeBeyond e*Gate integrator is the core of the platform. The e*Gate Integrator enables the flow of information by providing connectivity to applications and datastores across a network. You can loosely think of them as a BizTalk 2006 Application than encompasses all the different artifacts. e*Gate is based on a distributed architecture with an open design that deploys load balancing options. e*Gate processes events according to user-defined business logic and integrates business processes between applications, ensuring end-to-end data flow into back-office systems.
The record structures of messages (called Events in SeeBeyond) that are transferred to and fro are called an "Object Type Definition" (OTD). OTDs are created from source types and can represent any record type, e.g. XML, BAPI, Flat File, Relational row, WSDL, etc. You can think of them as the canonical type definition used by the platform - or schemas in the BizTalk World. The OTD is a Java class. It does all the marshalling/unmarshalling to these various formats.
e*Way are key components of an e*Gate and provide application connectivity and data processing such as business collaborations, transformation logic, and publish/subscribe. They comprise of an executable and a configuration file. You can think of e*Ways as a combination of adapters and ports and their binding information. e*Way connections are analogous to BizTalk ports.
e*Ways have “External Slice” components which is analogous to the communications adapter and the “Work Slice” which can be thought of as an application adapter and some business logic.
Both BizTalk and SeeBeyond support wide accepted standards like XML, XSD, WDSL, SOAP, BPEL4WS and are geared towards messaging and loosely coupled integration. While the integration goals are the same, SeeBeyond has taken a different architectural approach than BizTalk. For example, SeeBeyond does not have a central MessageBox where all messages are delivered and which acts as the subscription engine (although it does have smaller and more numerous Intelligent Queues). SeeBeyond does not insist on XML conversion of Flat File messages (through a pre-processing disassembler).
SeeBeyond eBusiness Integration Suite
The SeeBeyond eBusiness Integration Suite includes the following components and sub-components:
· e*Gate Integrator:
· e*Way Intelligent Adapters
· IQ Intelligent Queues
· Business Object Brokers (BOBs)
· e*Insight Business Process Manager
· e*Xchange Partner Manager
· eSecurity Manager
· e*Index Global Identifier
A one to one comparison of artifacts will probably of much greater help:
| Architectural Parallels between BizTalk and SeeBeyond | |
| BizTalk | SeeBeyond |
| Messaging / routing | Collaboration (data routing) |
| Schema | Structure |
| BizTalk NT Service | E*Gate Registry Service |
| Host Instances | Participating hosts in a Control Broker |
| BizTalk Host | Registry Host |
| BizTalk Administration Console | E*Gate Enterprise Manager GUI |
| Group Hub / Health and Activity Tracking | E*Gate Monitor GUI |
| MessageBox | IQ (Intelligent Queue) datastore – different from MessageBox and is a very loose parallel |
| Immutablity of messages | Events are mutable even inside a IQ |
| Adapter | E*Way |
| Send and Receive Ports | E*Way Connections |
| BOB (Internal e*Gate component used for load balancing) | |
| BizTalk Application | E*Gate |
| Binding file (very loose analogy) | Schema (The parameters and relationships between e*Gate components) |
| Orchestrations | E*Insight BPM (Business Process Manager) |
| Pipelines | (no equivalent) No distict pre-processor artifact, although pre-processing can be impleted in code |
| Visual Studio IDE | SeeBeyond uses its own IDE unlike BizTalk which uses the common .NET IDE Visual Studio. Although SeeBeyond can be coded in J2EE, it does not provide Developer Tools that can be installed as plug-ins for standard IDEs like the Eclipse, Jbuilder, Java Studio Creator, etc. |
| Pub/sub managed by MessageAgent from the MessageBox | Events are published by Collaboration. The Subscription is by the EventType and the Publisher. |
| Business Rules / Policies | Property file – can be changed at runtime. Rules xan also be in the database |
| (no equivalent) – although Group Hub can add more MessageBoxes | IQ Manager controls IQs |
| Content Based Routing | Eventy Types / Collaboration Rules |
| Trading Partner Management | e*Xchange Partner Manager |
| Implemented in .NET Security infrastructure, PKI certificates | eSecurity Manager |
| Business Activity Services | e*Index Global Identifier (e*Index) |
| No direct analogy – implemented in BizTalk Group / Clustering | Business Object Broker (BOB) |
| BTS Management Database | e*Gate Registry |
| Port | E*Way Connnection |
Technical Parallels between SeeBeyond and Biztalk
Having discussed migration approaches, we want to highlight another challenge/dilemma that can come in the way of getting a quick start on the migration effort. The challenge is ability of a BizTalk trained team to be able to quickly understand the parallels between SeeBeyond and BizTalk.
Given this challenge and dilemma, we decided to dedicate a section to discussing these parallels and draw some analogies between the concepts, features, technologies and artifacts of the BizTalk and SeeBeyond platforms.
The best way to learn is by example. For the BizTalk architect or developer attempting a migration project - the first look into the SeeBeyond world is confusing and ambiguous – because the familiar concepts and artifacts they are familiar with in BizTalk are missing or fused with another feature. For some there are simply no parallels at all. There is little or no documentation available in this area on the internet and one has to rely on assistance from experts.
Please note that many parallels are mostly loose analogies to help the BizTalk developer gain a newcomer’s familiarity with SeeBeyond. Since the architecture of both platforms is different, drawing parallels between both is a hazardous task, fraught with shoe-horning and over-simplification. We have attempted it nevertheless - on the grounds of giving the migration team a first look / toehold into the world of SeeBeyond and dispel some of the fog surrounding it. Caution is advised against literal interpretation of these parallels – and no technical implementation based on it is recommended. A deeper and more thorough understanding of SeeBeyond Technical Architecture and concepts is advised before the migration project is undertaken.
In order to do the parallels justice, it is perhaps advisable to discuss what are the key components that make up the SeeBeyond suite and how they tie together
Posted in: Software Software Programming| Tags: Microsoft WCF BizTalk BizTalk Migration BizTalk Server EAI integration solutions Microsoft Biztalk SeeBeyond Technical ParallelsTechnical lessons in BizTalk Migration
1. Although SeeBeyond Collaborations can be translated to BizTalk Orchestrations, it makes better sense to separate an implementation into Orchestrations for business processes, Maps for data transformation, Business Rule policies for business logic, and Pipelines for low level message pre-processing. In a SeeBeyond implementation, the Collaboration is the main executive module where most logic resides - and all these sub-tasks are mixed together creating a delirious “code cocktail” we have witnessed first-hand. In BizTalk such collaboration can be cleanly split into functional modules which are easier to maintain.
2. Data conversion. Type system mismatch between Java and .Net, date and time formatting can be sources of subtle errors. For example, in Java the default DateTime string formatting is different from neutral culture formatted DataTime string in the .NET Common Type System. SeeBeyond code compare dates as strings which is culture specific in .Net, so it’s better to switch to a DateTime object.
3. Message size. In SeeBeyond messages are binary structures and strings. But all flat file and native messages entering BizTalk are converted into XML – blowing up their size 3 to 5, even 10 times! When these are mapped they are held in memory as is the transformed message – which is equally large perhaps. This can easily lead to performance problems due to memory pressure. One should pay close attention to the message size. Since messages in BizTalk are immutable developers may create duplicates in the orchestrations which will add to the memory overhead. Instead the BizTalk developer should chunk up the message into smaller (physical) sizes – as BizTalk is highly parallel and is best optimized for processing a high throughput of light-weight or medium-weight messages with remarkable speed – but the reverse (heavy messages and low throughput) is not true.
4. SeeBeyond’s data structures map pretty well to .Net typed DataSet. This fact can be used when converting component logic from Java to .Net. Entire structures can be mapped to a typed dataset which makes case for straightforward code conversion. There is a difference thoough – nullable types. .NET DataSet supports DbNull and this should be taken in account.
5. Centralized logging and tracing is critical in this type of mission. Microsoft Enterprise Logging Block or Log4Net library can help to tackle this task.
6. Sometimes it makes far more sense to engineer the logic in .NET components than BizTalk. Just because it’s a migration exercise does not mean BizTalk is a natural choice. A .NET library with a BizTalk wrapper can do the trick in many cases – do try to think out of the box when evaluating design.
7. Proper encoding should be used for data both in xml as well as in flat file formats. If this is not taken care of, it may result in output data mismatch and can lead to multiple test cycles and rework.
8. Automated test scripts also play a major role in making things easier since you must be prepared for many cycles of verification and overload testing.
Posted in: Software| Tags: Microsoft WCF BizTalk BizTalk Migration BizTalk Server EAI integration solutions Project Management