Content Integration ArchitecturesNovember 16, 2005

AgendaEnterprise Content Integration IntroDefinitionsStandardized Content ClientsContent CachingContent BridgeEnterprise Services BusCase Study Summary

WHY Enterprise Content IntegrationEnterprise Application Integration (EAI) + Voluminous Enterprise Content Repositories __________________________________Enterprise Content Integration (ECI)

ECI Defining continuedWeb Services Open standards UDDI, WSDL, SOAP, and HTTP. All are managed by standard bodies like W3C and OASIS.Enterprise Information Integration (EII)Enterprise Content Integration is practically interchangeable with EII but when we refer to ECI know that the solution is content driven not just Information driven.

Content ClientsWays to access Content RepositoriesJSR-170 WEB-DAVXML-RPCJDBC/ODBCRMI/COM+

Content CachingCentralized copy of contentContent is usually pushed to the cache.ETLSynchronized (i.e.. rsync)FTPNot the data source of record for the content that it servesFocuss on high performance production delivery of content.

Content BridgePluggable repositoriesLoosely coupledBusiness Change Management

Content MonitoringWorkflowFederated ViewsMetadata Warehouse

Enterprise Service Bus (ESB)FeaturesContent Based RoutingContent EnricherGuaranteed DeliveryMessage BrokeringService RegistryEvent-Driven ConsumersMessage ChannelsMessage Translator

Governance FeaturesReportingControl BusWire TapSmart ProxyVersioningSecurity

ESB

ESB Use CaseA partnering company sends an order to the ESB.The ESBs Event Endpoint receives it and decrypts the messageThe endpoints pipe then authenticates the message producer via WS-Security policiesThen a filter inspects the content and figures out there is a registered pipeline for this type message and forwards the message.The second pipelines first filter translates customer supply codes to out companies supply codesThe pipes next filter adds metadata to the messageThe pipes last filter sends the message to the order fulfillment endpoint and consequently in the order fulfillment application

Case Study Unnamed Government DepartmentFor many years several dispersant agencies have provided interrelated very detailed information.Congress mandates to give the citizen a single website to view all the content.50k + publications are released a year by these Agencies.7 different websites contain silod query mechanismUtilizing similar but not the same search criteria values

Case Study ECI Solution

SummaryVariety of Connectors to Content RepositoriesFiner grain control of ContentCachingContent abstracted from the repositories to extend capabilities of content productionBridgingUnifying content repositories to the enterpriseEnterprise Service BusConnecting your Enterprise Application to your Enterprise Content

SummaryThis presentation is available at www.anexinet.com/events/kmworld05

Any Questions?

Thanks for having Us!

Now that Enterprise Application Integration (EAI) has become mainstream, a large volume of content remains stored in various repositories across enterprises. With this, many corporations are looking to share their content with other enterprise-wide repositories and applications. Both EAI and Enterprise Content Integration (ECI) solutions allow applications to communicate with each other. However, ECI provides more options, patterns, and architectures to consider. During this presentation, I will illustrate the benefits of ECI and four different architectures that corporate IT managers can leverage in their content integration strategies. XML-RPC runs over http and can allows access to complex XML based data structures.RMI and COM+ are low level ways for applications to make distributed, Over the Wire calls.

Synchronized using various utilities not unlike my favorite rsyncLoosely coupledness plays well with Technology Modernization and basic change management.The enterprise service bus is jammed packed with Integration best practices and associated patterns. Most ESBs are configurable and fairly easy to stand up inside an organization. But dont be confused with standing up and configuring the ESB application and making the ESB usable in your enterprise. A lot of hard work will go into modeling message flows and connecting endpoints into the application.

One basic premise in an ESB is that ESBs work with endpoints, messages, and channels. A message is basically content with instructions that is sent by an message producer. All consuming endpoints are registered with the ESB through the Service Registry. Endpoints can be consumers of messages as well as producers of messages and most are both. Messages flow through the ESB through Message Channels.

The ESB gives users the ability to dissect the content in the message. This dissecting of the content allows us to route the message based on specific values. Dissecting the Content also allows us the ability to enrich, translate, and basically cleanse values in a messages.

Since so much can happen in an ESB Governance features are required. -Reporting Message History and Message History-Versioning What does an ESB version if it doesn't directly host content? Another ESB feature, not listed above, is pipes and filters. Pipes and filters basically manage and manipulate content. Pipes are basically channels between filters. Filters are where some of the real power of the ESB come from. Filters are configurable components that allows users to implement servicing and business rules.READ SLIDE.#2 this is a Smat Proxy#6 like the Partnering Companys internal customer id.Oh yeah, at every step of the way the ESB tracked each transaction and decision.