tag:blogger.com,1999:blog-29701096.post2828665534706020407..comments2023-10-30T08:55:18.553+01:00Comments on SOA and EDA: A Federated Service Bus InfrastructureJack van Hoofhttp://www.blogger.com/profile/10073941747649739657noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-29701096.post-12735498617905394922010-06-30T05:48:16.767+02:002010-06-30T05:48:16.767+02:00Hi, i'm really interested in this post...I wan...Hi, i'm really interested in this post...I want to know more about "A Federared Service Bus Infrastructure".<br /><br />Thats exactly what I was searching in this time... <br /><br />Thanks!!!home for sale costa ricahttp://www.costa-ricarealestate.com/noreply@blogger.comtag:blogger.com,1999:blog-29701096.post-23027842769063511892009-11-21T08:21:56.486+01:002009-11-21T08:21:56.486+01:00This comment has been removed by the author.Anonymoushttps://www.blogger.com/profile/13750296861408964040noreply@blogger.comtag:blogger.com,1999:blog-29701096.post-34854585536581628412009-04-27T17:14:00.000+02:002009-04-27T17:14:00.000+02:00No, I don't think I am architecting for my own ple...No, I don't think I am architecting for my own pleasure.<br /><br />My approach as an IT-architect is always to look for the commonalities, especially with regard to infrastructural matters, because you just want infrastructure to be a commodity by definition. (See how the Internet - with the cloud computing initiatives - including all of it's standards is evolving at the moment). Of course you may create industry-specific patterns and deviations if appropriate, but eventually technologies tend to converge and offer ultimate flexible to support every kind of business. E.g. PC-motherboards are equal whether you run Linux of Windows. And governments use the same kind of networks as financial institutions or any other type of company. The business is made "upon" the technology (makes use of it); the business is not made "by" the technology (except for the companies that have technology in their product-portfolio as a product to be sold in contrast to merely use technology to run their business).<br /><br />If you design a specific infrastructural solution with the current business requirements in mind, you will run into problems once the business changes or once your competitors take benefit of external commodity providers.<br /><br />Using systematic commonalities at the infrastructural level make your business more agile to unforeseen or radical changes. <br /><br />I get the same water and electricity in my company as any other company is getting it -for the sake of flexibility and costs reduction.<br /><br />-JackJack van Hoofhttps://www.blogger.com/profile/10073941747649739657noreply@blogger.comtag:blogger.com,1999:blog-29701096.post-25402389827900002022009-04-27T16:00:00.000+02:002009-04-27T16:00:00.000+02:00Jake,
Taking your point you would suggest a cooki...Jake,<br /><br />Taking your point you would suggest a cookie-cutter approach ? I doubt that that would fit in the real world.<br /><br />A business requirements driven solution ? Yes. Otherwise you are architecting for your own pleasure.<br /><br />Keep in mind - the solution I referred to was more domain driven. Services are categorized and distributed accordingly, as to functional and non-functional requirements incl SLA's. Then they are mapped to an infrastructural solution ... which may be hierarchical, but also could mean a different approach.Peter L. Gratzernoreply@blogger.comtag:blogger.com,1999:blog-29701096.post-19506123108782296962009-04-27T15:09:00.000+02:002009-04-27T15:09:00.000+02:00@Peter,
I'm not quite sure how the structure will...@Peter,<br /><br />I'm not quite sure how the structure will work out if you take the business requirements as a starting point to model an infrastructural layer. <br /><br />What are the effects if the business requirements change? Are you going to redesign the infrastructure? I prefer a more systematic approach to design an infrastructure that is agnostic to business requirements. Only then real agility can be offered to the business.<br /><br />-JackJack van Hoofhttps://www.blogger.com/profile/10073941747649739657noreply@blogger.comtag:blogger.com,1999:blog-29701096.post-17001597872656281242009-04-27T14:42:00.000+02:002009-04-27T14:42:00.000+02:00Jack,
Not sure if there is an easy answer to the ...Jack,<br /><br />Not sure if there is an easy answer to the topic. As architects and part business analysts it is our role to translate business requirements into solutions. Putting a solution aka a hierarchical bus model ahead of the requirements is in my view a not a proper direction to address a problem space. As the hierarchical model probably fits a lot of bills, in my view you should come from a business understanding, extrapolate an enterprise wide domain(and not data !!) model and distribute the Services in respect to an organizational fit.<br /><br />As a structure will form, a hierarchical model may well be the solution, though it could also mean that you have to establish several sub-domain busses communicating in a more horizontal, network oriented fashion.<br /><br />Bottom line - the application of an architectural approach should be driven by the business requirements, to a portion reflected in a domain model. Important hereby is, that the domain model is maintained and changes over time reflected in the Service portfolio and associated architecture. Do you agree ?Peter L. Gratzernoreply@blogger.comtag:blogger.com,1999:blog-29701096.post-22115030448379002032009-04-22T13:09:00.000+02:002009-04-22T13:09:00.000+02:00@Peter L. Gratzer,
Indeed, things may get very co...@Peter L. Gratzer,<br /><br />Indeed, things may get very complicated when you are faced with multiple dimensions. This is one reason more the strive for structured solutions. <br /><br />You might create hard boundaries between the divisions and apply instances of the model within these divisions.<br /><br />What's your suggestion?<br /><br />-JackJack van Hoofhttps://www.blogger.com/profile/10073941747649739657noreply@blogger.comtag:blogger.com,1999:blog-29701096.post-63711266940908348372009-04-22T12:43:00.000+02:002009-04-22T12:43:00.000+02:00On a short note: looking at the approach it seems ...On a short note: looking at the approach it seems to fit well for a functional oriented business, but what kind of approach would you consider if you are faced with a divisional or matrix organization ?Peter L. Gratzernoreply@blogger.comtag:blogger.com,1999:blog-29701096.post-19587560833746213352009-04-10T16:43:00.000+02:002009-04-10T16:43:00.000+02:00Hi Shekhar,Besides of exposing and calling service...Hi Shekhar,<BR/><BR/>Besides of exposing and calling services the concept exists of publishing and consuming messages. This distinction is essential in the discussion of domain architectures. In a COTS-environment you will rather publish and consume messages to and from the environment then exposing internal services to be externally called. In an ideal situation these messages represent pure business events.<BR/><BR/>In fact my idea is not to orchestrate lower level services (child-level), but make use of generic higher level services (parent-level) when you compose a processes at a certain level. <BR/><BR/>See also a <A HREF="http://soa-eda.blogspot.com/2006/11/how-eda-extends-soa-and-why-it-is.html" REL="nofollow">previous post</A>.<BR/><BR/>-JackJack van Hoofhttps://www.blogger.com/profile/10073941747649739657noreply@blogger.comtag:blogger.com,1999:blog-29701096.post-79987808069319037372009-04-10T10:18:00.000+02:002009-04-10T10:18:00.000+02:00When dealing with COTS Business Applications like ...When dealing with COTS Business Applications like eBiz Suite, CRM etc. does it make sense to expose their internal service to the domain bus and orchestrate them when the process is collocated and encapsulated within, I mean sits within those product. <BR/><BR/>I understand that these vanilla capabilities (of the COTS products) are hardly suitable for use unless they are customized but does that mean we should expose them to domain bus and orchestrate them to develop domain specifc processes? <BR/><BR/>In my opinion,mainly in cotext of COTS application service, unless there is a situation wherein domain specific processes themselves are dependent on other domain services to realize them and/or these pre-ordained services need to be orchestrated in a different manner practically there is no need to pull them in a domain bus and orchestrate them. But then the question is whether it should be dealt with using a Domain bus or an Enterprise bus.Himanshu.Shekharhttps://www.blogger.com/profile/05480775432786739331noreply@blogger.comtag:blogger.com,1999:blog-29701096.post-88634885112902561002009-04-08T16:31:00.000+02:002009-04-08T16:31:00.000+02:00It's definitely not simple ;) and I am not sure I ...It's definitely not simple ;) and I am not sure I understand you correctly in some points.<BR/>Basically, I think we can build (orchestration) processes at the domain and corporate levels (not at the application level here, we expose atomic services to the domain bus).<BR/>I see domains as organizational departments, encapsulating the specific business domain functionality. We can expose services (orchestration processes) from that domain to the corporate bus if they have enterprise wide value. If not they will be contained in their domains (FIN, CRM, etc).<BR/>For departments to call other departments services in a context-agnostic way we can make use of a Canonical Data Model (CDM) that represents Business Objects enterprise wise, aiming for service reuse.Unknownhttps://www.blogger.com/profile/05098361284411011394noreply@blogger.comtag:blogger.com,1999:blog-29701096.post-74435573503754776502009-04-08T16:25:00.000+02:002009-04-08T16:25:00.000+02:00This comment has been removed by the author.Unknownhttps://www.blogger.com/profile/05098361284411011394noreply@blogger.comtag:blogger.com,1999:blog-29701096.post-26014785271746714812009-03-31T18:59:00.000+02:002009-03-31T18:59:00.000+02:00Hi Hugo,Thanks for your comments. With regard to S...Hi Hugo,<BR/><BR/>Thanks for your comments. With regard to SAP modules belonging to different business domains, you hit the complex challenges in defining domains. <BR/><BR/>If you define the domain-buses in terms of information domains (which is ideal from an application point of view), there is only one logical SAP-FIN or SAP-CRM module which maps respectively to the FIN-domain or CRM-domain. There may be a multi-tenant or multi-instance implementation to separate between organizational user groups (business domains), who make use of these FIN- or CRM-processes. These processes are living in the FIN-bus or CRM-bus.<BR/><BR/>If, on the other hand, you define the organizational departments as domains (which usually is practice) you expose the SAP-modules as enterprise-wide services living in the corporate bus to be accessed by the domain processes in the domain buses. In this case the modules should be context-agnostic (characteristic of a service in an SOA), which means all departments may generically make use of it. Of course, in this case, you may create business oriented instances of the processes, but you must be aware of moving away from the reuse aspect of SOA (which may be an adequate trade-off).<BR/><BR/>You see, in practice things are more complex then our SOA guru's generally would like us to believe ;-)<BR/><BR/>Does this answer make any sense?Jack van Hoofhttps://www.blogger.com/profile/10073941747649739657noreply@blogger.comtag:blogger.com,1999:blog-29701096.post-65844974623523368152009-03-31T15:30:00.000+02:002009-03-31T15:30:00.000+02:00One application can belong to multiple domains. Ex...One application can belong to multiple domains. Example: Different SAP modules belong to different business domains: Finance, CRM, etc.<BR/>So we should split the end-applications in business oriented instances.<BR/>Do you agree?Unknownhttps://www.blogger.com/profile/05098361284411011394noreply@blogger.comtag:blogger.com,1999:blog-29701096.post-86186271833256521982009-03-31T15:05:00.000+02:002009-03-31T15:05:00.000+02:00I agree/have been putting these same ideas in plac...I agree/have been putting these same ideas in place for a while now. You can have the high way and the secondary roads working together.<BR/><BR/>Love the 'try lasagna' joke ;)Unknownhttps://www.blogger.com/profile/05098361284411011394noreply@blogger.comtag:blogger.com,1999:blog-29701096.post-19258557641384285692009-03-29T18:03:00.000+02:002009-03-29T18:03:00.000+02:00Makes sense. When i discussed this with an ESB ven...Makes sense. When i discussed this with an ESB vendor some time ago, they called this pattern Big Bus/Little Bus. The Little Bus would be the domain level bus, the Big Bus the Enterprise Bus.eelconoreply@blogger.com