Bryan, We aren't using a single model - we have XML schema for all sorts of data items. For example, we have one schema for "customer", another for "PO", etc. Some are simple, and others are very complex, depending on what it is we are modeling and sending around between systems. The XML db itself just runs on another server. We use it mainly to persist messages that need to be aggregated before being sent out in B2B exchanges with our customers.
We should definitely meet up for beers sometime. It would be a shame not to being that we're in the same city. -Rob On Apr 7, 9:27 am, "Bryan Hogan" <[EMAIL PROTECTED]> wrote: > Hey Rob, > > Thanks for your information. It is great that many of the packaged ESBs > have this capability built in. It seems to be a godsend that someone > has made a product out an ESB. > > You're not trying to use the same model for all your entities are you? > I don't think that is possible. From your post it seems that your XML > db sits in your ESB is that correct? If so doesn't that seem like a > hub-and-spoke architecture? > > Your staging integration approach is what I am doing now. I massage, > validate and transform the data through a service in a lot of cases. It > seems that is similar to what you are doing with your POJO but instead > I'm using a POCO. ;-) > > The governance part is still something I haven't grasped completely yet. > I would love not to have to build it myself. > > You're absolutely right that this is fun. Hell if you ever feel like > talking about it over a beer, I'm right down the road. > > -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf > > Of Rob Brooks-Bilson > Sent: Thursday, April 03, 2008 7:41 PM > To: CFCDev > Subject: [CFCDEV] Re: architecture question: communication between > applications > > Bryan, > > Each of our ESB's act independently, allowing the one in the > philippines to serve local requirements that don't involve corporate > or shared data. At the same time, the local ESB can act as an > extension of the corporate ESB when we need to communicate between the > two. They can also be configured such that if the main ESB goes down, > the other ESB can assume it's duties. Most of the commercial ESBs > have this capability built-in. If you go with something like MULE, > you'll probably have more work to make this happen. > > As far as data model goes, the approach we've taken is to create > schema for the various entities we're moving across the ESB. For > example, we have a canonical model for customer, WIP transaction, PO, > Die Release, etc. There are still a lot of areas we don't have > canonical models for, but we're adding new schema as we need them. > The schema are independent of any of the database structures where > data may come from, or where it may end up - what's important is that > you capture all of the data that is available/could be required for > the entity you are modeling. Take a customer for example. System A > may only need customer name and customer number, while system B needs > those fields as well as address, city, state, country, etc. All of > those elements need to be part of the schema that you define. > > All of the work that we've done actually started from external B2B > integration and has worked itself back into the rest of the > organization. In our case, we participate in RosettaNet, which > provides standard XML formats (and more) for transaction types that > are specific to the electronics industry. These schema represent the > data format that our customers expect to receive from our systems. > Our internal systems don't store data in the same format, so what we > do is this: Data from source systems is first converted into our > canonical format, based on transaction type and temporarily stored in > an xml database. When it's time to send to a customer, we pull the > data from the xml db and transform it into the RosettaNet specific > format (which almost never is really standard), then the data is sent > on to the customer. We also have the same process run in reverse, > where we get customer data in RN format, transform it to our canonical > format before storing it in our xml db (most times), then transform it > again for our internal systems, whether they be SAP or our > manufacturing execution systems. > > The way to actually connect a DB to your ESB really depends. In some > cases, our ESB will reach directly into a DB (usually staging tables) > and extract the data it needs for a message. We prefer it when > systems push data to the ESB, but that isn't always possible in our > environment. In the case where we pull data directly, it's done using > JDBC. In our case, we created a generic POJO that does the > extraction, and it simply becomes a step in a "sequence" or "flow". > > For governance, there is really two types that come into play - design > time, and runtime. What you are talking about regarding availability, > etc. is handled by runtime governance. You don't want to build this > yourself unless you have to. There are decent systems out now that > handle this (Software AG has a good one, as does Amberpoint). Most > governance solutions include UDDI, but the directory is really only a > minor part of their overall functionality. It can be difficult to > wrap your brain around all the SOA governance, but once the lightbulb > goes on, it gets easier. Both SAG and Amberpoint regularly offer > webcasts and sometimes local seminars on SOA Governance. I suggest > checking them out for some free info on exactly what they offer and > the problems they are trying to solve. Eventually you'll get to the > point where you realize that services alone are only part of the story > and what's actually more important is that you treat them as > manageable resources (sounds like this is what you are saying), where > each service has an SLA, security, auditability, versioning, etc. > > I hope this helps. If you have more questions, keep them coming. > This is fun ;-) > > -Rob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
