ESB, Service Implementation and the Return of the EJB

Discussions

News: ESB, Service Implementation and the Return of the EJB

  1. For organizations serious about pursuing an SOA (Service Oriented Architecture), knowing the strengths and weaknesses of your development organization is important to improving the process. This article helps evaluate the application's and implementation teams' readiness for SOA.
    SOA within most organization's architectures is really at a stage where Web (HTTP) servers were in the early days of internet-style computing. In those days, architects were trying to find ways to use Web servers either for serving static pages or basic reporting. In a similar fashion, today's architects are introducing Web services either for looking up reference data or other basic computing constructs. To look at SOA any different than the other distributed object models previously mentioned is a rookie mistake. Technological advance in computer technology is much more fluid than it appears in that a new technology in many cases borrows from and improves on an existing related technology. The new feature within Web services is that it is a distributed technology engineered for the Internet. Essentially, there are application requirements where SOA makes senses and application requirements were it is inappropriate.

    Threaded Messages (33)

  2. From the article:
    Technological advance in computer technology is much more fluid than it appears in that a new technology in many cases borrows from and improves on an existing related technology.
    I wish that was the case! In general I am sick of articles equating SOA to the SOAP thingies using HTTP(S) transport and talking about horrors of DCE. I would say that if it took 2 years for author to get productive with DCE I think he should not be doing software development, much less teaching about SOA.
  3. To look at SOA any different than the other distributed object models previously mentioned is a rookie mistake.
    This statement is not just a rookie mistake, it's an ignorant one. SOA is not about distributed objects or web services. In fact, it was developed as a solution to the scalability problems that distributed objects have especially when communicating with clients. If you did EJB or CORBA objects that were designed and behaved as objects, you ended up with numerous fine-grained objects and minimal value calls including getters and setters. With the same technologies using the SOA style, their methods would not be object methods but use case realizations. In other words, instead of implementing the sequence of calls to various objects or components on the client side, you implement those sequences (use cases) on the server side and make one call instead of many from the client. The same approach, the SOA style, can be applied or not using any distributed technology. We’ve used it in the RPC days, with Tuxedo, CORBA, EJB’s and web services. You can do it with DCOM for God’s sake. You can also choose not to use the SOA style with these technologies. In the case of CORBA and EJB’s you’d have distributed components which can be necessary and useful, but in my opinion should be restricted to intra-application, inter-server communications. Services work better when you are communicating with clients and other applications. The trade off is that services are not as reusable as component or objects because they are coarse grained and targeted to specific use cases. However, that is not a problem if you build them as component collaborations or orchestrations because the components are or should be inherently reusable. Knocking out a new service from an existing library of components should be a piece of cake. Other than that I agree with the notion that software does not advance as quickly or as dramatically as marketing would have us believe. Java, Ruby, C#, J2EE, .NET, SOAP, et al have not changed the laws of physics or the hardware architectures or even the operating systems. (They changed on their own pace, but are still von Neumann.) These software technologies and methods have not changed the relative speeds of registers versus L1 and L2 cache versus main memory versus disks and networks. The truth is I cannot think of a single major new idea in software that was conceived after 1980 and is in production today.
  4. To look at SOA any different than the other distributed object models previously mentioned is a rookie mistake.


    This statement is not just a rookie mistake, it's an ignorant one.
    I completely agree. Furthermore, the article gets -1 points for using words such as "neophyte".
  5. The truth is I cannot think of a single major new idea in software that was conceived after 1980 and is in production today.
    I can't resist taking the challenge. I guess it depends what you mean by major changes but: 1) HTML and XML? Both from SGML which I think came out in 1980. 2) Or the World Wide Web (1991 more or less) seems to be me to qualify, as does 3) Message Oriented Middleware (1992) – MQSeries and the like. 4) CTM – (EJB, COM, CORBA etc. - Maybe not popular on TSS at the moment but certainly still widely used and very much in production). Hard to put a date on this but the composite ORB and TB monitor products I think started to emerge in the late 1990's. Or how about hard disk audio recording? MP3? Software sequencers...... The other significant shift, though I suppose you could argue that its origins are in the 1970s is to interpreted languages/managed code and object orientation. Java had a pretty big impact here, as did Visual Basic of course. And scripting languages for Applications (MSOffice and VBA had a pretty huge impact here).
  6. Charles, Your examples are all implementations of concepts first espoused and described before 1980. They are not themselves the major concepts or inventions of which I speak. Software since 1980 has primarily refined and brought to fruition things that were “invented” before 1980. XML, HTML and SGML are just hierarchical markup languages - tagging schemes. They implement a concept that was around years before. SGML did not appear out of nowhere. The World Wide Web is an innovation - combining known concepts and technologies in a new way. It was the first wildly successful combination of these concepts, but it didn't invent new ones. MOM is an implementation of older concepts. In fact, before MOM we had "MOM construction kits" such as what Tuxedo System/Q did/does. The concept is to send a message to a queue to be picked up by someone else. Operating systems did that internally in the 1960's. IPC? Mailboxes? It's old computer science. Knuth probably documented it in his classic series. Components are robustly packaged objects. The first OO language was Simula, circa 1967. Smalltalk was fleshed out in the 1970's with the first popular distribution being Smalltalk 1980. Component technologies are implementations that use or support these and other software engineering concepts (modularization, encapsulation, interface contracts, etc.) from long before. They are innovations, not inventions in terms of computer science. MP3 is an implementation of file compression - old news. Hard disks and recording bit streams on them have been around since at least the 1960's. What is different between a bit stream that represents audio versus text or number? The computer hardware cannot tell. The thing is that there has been a long lag time between what the computer scientists think up and prototype and commercial implementations that harness their ideas. If you want to see the far future, join ACM and IEEE and read their journals. Pretty dry stuff, but in there are the kernels of the future. I did graduate work on algorithms and data structures over 25 years ago. The ones I studied began showing up in mainstream commercial RDBMS, data warehouse and data mart products only in the last 8 or 9 years. One of the reasons for this lag is that the price/performance of hardware and foundation tools (compilers, etc.) has to get to a point where the ideas are economically feasible to implement and use on a broad scale. There also has to be sufficient demand for a solution that requires a particular invention. I did OO for a number of years for prototypes, but it wasn't until the 1990's that it became feasible for me to use an OO language in a major commercial system. OO began taking off after the convergence of a number of things including: major waterfall/structure analysis project failures leading to an interest in incremental and iterative development, increased demand for GUI’s (which are harder to write without OO or components), better compilers and faster cheaper hardware, and a significant shift in the relative cost of labor versus hardware. Higher relative labor costs increased interest in reuse and flexible and adaptable architectures and designs.
  7. The truth is I cannot think of a single major new idea in software that was conceived after 1980 and is in production today.
    Just for the sake of arguing... Microkernels?
  8. The truth is I cannot think of a single major new idea in software that was conceived after 1980 and is in production today.

    Just for the sake of arguing... Microkernels?
    According to Wikipedia, Carnegie-Mellon began working on the Mach microkernel in 1984. That seems to indicate that the concept was already around making it likely to have been espoused before 1980. Reading their article further they state that Mach evolved from the earlier Accent kernel project - work that was underway by 1979! Kernels of course are much older (UNIX was created in 1969) - so microkernels just extend that concept. If you read some history, it is amazing to see how much in computer science that we still use today was worked by 1960, much less 1980. To paraphrase some famous guy whose name (and exact quote) escapes me, we all stand on the shoulders of giants.
  9. SOA is not really a new idea. It wasn't the brainchild of a few engineers sitting around trying to think of the 'next big thing' ala EJB. SOA is the natural progression of decades of trial and error in building heterogeneous distributed architectures. It's not a technology. It's a design strategy.
  10. Irresponsible[ Go to top ]

    Dear Lord... aside from stating "Some organizations are better prepared for an SOA than others" this pile of drivel couldn't possibly have been LESS informing. Saying that organizations that have experience with DCOM are ready for SOA is akin to medical malpractice. The author obviously hasn't seen the piles of useless service-like code that most companies put out these days. In fact, I'd go the other way and state I'd rather work with an organization with NO service experience than one that's been screwing it up for several years. It's easier to implement good practices from the beginning than it is to convince people they need to unlearn masochistic design tendencies.
  11. just for fun...[ Go to top ]

    I would like to stress test such an architecture. I would like to see how many servers it needs to handle 100 or 200 simultaneous connections. As a senior project manager, I have been asked several times to work on projects with bad response times. The kind of projects that can not go live because they are not able to meet the load requirements. And you are asked to find a "magical" solution that will avoid to throw all the project. Like "put some more servers" (that is not an effective solution). We are all the same : we are interested in new and hype things, always trying to use the best technology. But if we want to build some robust solutions, delivered on time, we must keep it simple. And I wonder if ESB is a mature enough to go on production.
  12. Re: just for fun...[ Go to top ]

    But if we want to build some robust solutions, delivered on time, we must keep it simple.
    I totally agree. I am huge proponent of ESB in general and have been for quite a while. However, the pattern/style/promise has been used by more than one vendor (and one in particular) to telegraph (aka marketeering) internal development while forward selling gazillions of dollars worth of "integrated stack" licenses (yeah right ;-). There are lots of ways to slice the pie, obviously, however IMO when the focus isn't on the inside and the inside isn't pretty, exposing it to the outside gets uglier and uglier. I think in general we have made huge gains in how we as a community are thinking about simplification on the inside, coding without direct binding to anything distributed, and partitioning/abstracting the services and interactions within a single process/VM. However, I don't have as much confidence once we leave a box and start thinking about the interaction between more than one VM. We are really early still, even as projects like Mule/Open ESB/Service Mix/Apache CXF help spread the word in the os world.
  13. Seems that any man and his dog with a bit of time can write an article that generates arguments - not about positions within a subject but within the accuracy, knowledge, precision, matureness of the author or the article itself. Are there no 'filters' within this site ? most of the articles are OK - when they stick to talking to delivery technology. When talking about frameworks & architectures, most people -like in this example- jump from the high-level business concept (SOA) to the low-level (HTTP/EJB) - which is not good as it just generates more confusion!
  14. misses the bigger mistakes[ Go to top ]

    One of the biggest SOA mistakes is to view services as silos or pieces of functionality that share no common code or functionality with other services. In this view, everything is extremely decoupled. Services need to call other services to get lookup data, relational integrity is implemented in code, and the end result is many fine grained services that perform poorly and are difficult to maintain. In my opinion, the proper view of services is as an integration layer on top of plain old component architecture. The services are facades into the existing components. With this view, the service can store lookup and needed data in its schema. The database performs referential integrity and performance is calculated as the existing performance characteristics of the components plus processing the overhead of marshaling and serializing objects over the transport. This also allows components to call other components in the native and optimized technology of the component instead of being forced to use XML and SOAP which are extremely inefficient intra-process communication methods. The system would only incur the cost of being a webservice at the integration points. In my opinion, many of the SOA woes originate from using the silo view of services. I don’t think experience with distributed technologies is a precursor to successful SOA implementations. I also see this silo view a lot more in the .NET community than the java. Also SOA does not equal webservices. SOA can be implemented over any transport medium.
  15. One of the biggest SOA mistakes is to view services as silos or pieces of functionality that share no common code or functionality with other services. In this view, everything is extremely decoupled. Services need to call other services to get lookup data, relational integrity is implemented in code, and the end result is many fine grained services that perform poorly and are difficult to maintain.
    This is not true. What you are describing is what someone with a poor understanding of SOA might do. SOA extends component-based (not as in component technologies like EJB, but components as in robustly package objects) architecture. Services can and often should share components. Components are the reusable building blocks of SOA. Components collaborate to realize use cases as service operations. In SOA, components do call other components even when distributed. Services are primarily for the edges – communications with clients and other domains or applications. You’ve described a case where someone over-used services. I agree with what else you’ve said though.
  16. Let me amend what I just wrote. Services are also units of work, so internal to an application or domain they make sense (versus distributed components) when you're components are not co-located and you don't need transaction flow. However, the technologies you use to implement your services is dependent on other considerations. I would always restrict my use of web services to the edges. (EJB, CORBA, DCOM, Tuxedo and other distributed technologies can all be used to implement services just as web services can. It's the design style, not the technology that makes it a service or not.)
  17. In SOA, components do call other components even when distributed. Services are primarily for the edges – communications with clients and other domains or applications.
    I may be misunderstanding what you are saying here but one of the core principles of service-orientation (according to some literature) is that services should be autonomous i.e. they should not depend on other services. In practice this can be costly so it's not a strict rule but a goal. One of the (numerous) misunderstandings about service-orientation is that a service should be a wrapper around an existing silo. If you have 2 silos involved in an 'enterprise' application you will have at least two services. This doesn't resolve any issues, it just adds another point of failure. A service should be independent from the underlying systems is uses to execute it's tasks. I think that the three of us may be saying the same thing here but just don't realize it because of the confusion surrounding SOA terminology.
  18. In SOA, components do call other components even when distributed. Services are primarily for the edges – communications with clients and other domains or applications.


    I may be misunderstanding what you are saying here but one of the core principles of service-orientation (according to some literature) is that services should be autonomous i.e. they should not depend on other services.
    There is a difference between the service being autonomous at run-time and sharing code. Services don’t share the same instance of a component, but they can, do and in many cases should share components – the code not the instance. Also, that reinforces my point about using components as your building blocks, not services. A service that delegates its core functionality to other services is not autonomous is it?
    One of the (numerous) misunderstandings about service-orientation is that a service should be a wrapper around an existing silo. If you have 2 silos involved in an 'enterprise' application you will have at least two services. This doesn't resolve any issues, it just adds another point of failure. A service should be independent from the underlying systems is uses to execute it's tasks.
    I‘ve run into that misconception too. Someone whose name I cannot recall calls that SOI (service oriented interfaces), so I’ve been using that term to describe the slapping of service facades on silos. It’s helpful for integration during the transition in that it keeps your new stuff from having to engage the legacy stuff in legacy ways, but it doesn’t make the silos SOA.
    I think that the three of us may be saying the same thing here but just don't realize it because of the confusion surrounding SOA terminology.
    I agree about the agreement and the terminology confusion.
  19. In SOA, components do call other components even when distributed. Services are primarily for the edges – communications with clients and other domains or applications.



    I may be misunderstanding what you are saying here but one of the core principles of service-orientation (according to some literature) is that services should be autonomous i.e. they should not depend on other services.


    There is a difference between the service being autonomous at run-time and sharing code. Services don’t share the same instance of a component, but they can, do and in many cases should share components – the code not the instance. Also, that reinforces my point about using components as your building blocks, not services. A service that delegates its core functionality to other services is not autonomous is it?
    Services do share instances with each other. To not do so would eliminate the ability to cache and take advantage of other desirable technologies.
  20. Maybe your services do , but the guidelines I've always seen and tried to adhere to say they should not share instances of the same component. Of course, we are talking not about instances of the same service (which can share component instances) but about instances of different services. Also, aservice, in common SOA parlance (e.g. as used in WSDL) is the end point, not its individual operations. So, a service end point may have multiple operations and may also have multiple instances all of which can share components and component instances. However, different services (end points) can share components but not component instances. Otherwise they would not be autonomous. So much for theory, I guess one question would be "is the database instance and its cache a shared component?" Another might be "is a middle tier object cache manager a shared component?" It can be reasonably argued that they are, but personally I don't consider them components within the context of the autonomy guidelines. I would say that the session is the component from the service's point of view and that is not being shared. The same argument would allow multiple services to run in a single application server, but would require that they be deployed in separate EARs (with independent classpaths). Perhaps the guidance should be clarified to only include application components and not infrastructure components. I'd be interested in where others draw the line.
  21. Maybe your services do , but the guidelines I've always seen and tried to adhere to say they should not share instances of the same component... However, different services (end points) can share components but not component instances. Otherwise they would not be autonomous.
    OK, I hadn't read this sentence before. "A service must be autonomous" autonomous regarding another service I guess. What is the reasoning behind this assertion?
    The same argument would allow multiple services to run in a single application server, but would require that they be deployed in separate EARs (with independent classpaths). Perhaps the guidance should be clarified to only include application components and not infrastructure components. I'd be interested in where others draw the line.
    Which guidance are you following? I come from a (sorta) EAI background, so thinking on services deployed on a single node sounds a little uncommon to me. Javier
  22. There is a difference between the service being autonomous at run-time and sharing code. Services don’t share the same instance of a component, but they can, do and in many cases should share components – the code not the instance.
    Would you mind to elaborate why two services don't share an instance of the same component? My understanding of a service: a system's capability, not the interface used to access that capability. So under this definition a service can have several "ports" or expose several interfaces. According to this view a component is an implementation of a system's capability.
    Also, that reinforces my point about using components as your building blocks, not services. A service that delegates its core functionality to other services is not autonomous is it?
    What keeps me of using a service as a building block if it makes sense? Perhaps I'm misunderstanding, and you are not suggesting to use always just components as building blocks, in the opposite extreme of someone who thinks just services are the building blocks. Javier
  23. There is a difference between the service being autonomous at run-time and sharing code. Services don’t share the same instance of a component, but they can, do and in many cases should share components – the code not the instance.


    Would you mind to elaborate why two services don't share an instance of the same component?
    It has to do with the concept of autonomy, but also statefulness. (Statefulness being when a single instance of something is keeping some state for use across multiple invocations.) The alternative is to store the state in a cache or database where it can maintained by multiple instances of the responsible component or service. In a sense this is delegating statefulness to the cache manager or dbms which are infrastructure. In my book, that is the dividing line. It’s O.K. Services should represent a partitioning of responsibilities in the enterprise. (Remember, we are talking about SOA services which are the endpoints, not their operations which is what you invoke.) If two services are sharing the same instance of component, they aren’t autonomous. There can be side effects which would violate the contract of the interface. The only reason multiple services would have to share a component instance would be because they are sharing state. Service instances should also be stateless. Services should receive the information they need about state beyond what they are managing themselves in request or response messages exchanged with other services their own components. There should not be multiple services responsible for maintaining the same state. (There should also never be multiple components maintaining the same state.) Assuming you really have to be stateful - despite the bottlenecks it creates, you would want to ask why you have created two separate services that share state instead of combining them into one. If the state you are sharing is related to a business function (versus infrastructure such as security), you should really question your design. For example, participant services in a workflow do not keep the workflow state. Another service or engine does that. Each of the services that participates in the workflow only knows what is in the incoming message and in their view of the data model. Whatever they need to know about the workflow state they either receive directly from the request or as a reference to look up in a cache or database. They should not normally be stateful at all and they should each execute units of work. Obviously this is not always clear cut and you have persisted state (database or middle tier cache) which may have to be shared, but it is an important design driver. If multiple services are delegating to the same component the reading and writing of some state, is the component still a component or does it now qualify as a service? Well, if the component is writing to a cache or database, then you did not need to share component instance so it can remain a component. If the component is stateful, then why? Give me an example where this is absolutely necessary. We are talking about services, not the presentation layer which can be more conversational.


    My understanding of a service: a system's capability, not the interface used to access that capability. So under this definition a service can have several "ports" or expose several interfaces. According to this view a component is an implementation of a system's capability.

    Also, that reinforces my point about using components as your building blocks, not services. A service that delegates its core functionality to other services is not autonomous is it?

    Components have interfaces and ports too. That is where these things originated from. They look very much like services except components are objects designed for reuse whereas services are designed more for scalability. You will find some components that can be wrapped as services (one component method = one service operation), but many do not result in good services by themselves because they are too fine grained. Reusability correlates to specialization and granularity. Services were created as a solution to the poor scalability of distributed objects (and components). The reason distributed objects do not scale well is that the same fine granularity that makes them reusable also results in you having to make more calls to more objects in order to accomplish a unit of work. A service bundles all that up into a single operation that is invoked by a single call - a use case. Fewer calls on the network relative to the work being performed. It is fairly typical for the overhead of a network call to exceed what is required to do the actual work. Remember all of you EJB and CORBA fans, when I say services scale better than objects or components, I am not talking about the technology you are using, just the design style. In other words, EJBs and CORBA objects that are designed as services do more work with less overhead than finer grained EJBs and CORBA objects, so they scale better in distributed environments.
    What keeps me of using a service as a building block if it makes sense? Perhaps I'm misunderstanding, and you are not suggesting to use always just components as building blocks, in the opposite extreme of someone who thinks just services are the building blocks.

    Javier
    Nothing, if it makes sense. However, that should not be the design goal of your services. If you make it a practice to create services that are building blocks, i.e. designed for reuse, you won’t have services, you’ll have components. Only at the higher, major process level will you find services being orchestrated into processes. At the lower levels, components are orchestrated into use cases. If you find yourself breaking up your services or service operations so they are more reusable, stop yourself.
  24. My first attempt was to quote the post, but I soon realized that was a challenge beyond my capabilities. Mainly because the discussion spans from architectural styles down to database and cache and I found it really immense. In the midway between a renewed "Timeless way of building" and "aria fritta" Guido
  25. Re: misses the bigger mistakes[ Go to top ]

    I may be misunderstanding what you are saying here but one of the core principles of service-orientation (according to some literature) is that services should be autonomous i.e. they should not depend on other services.
    Why? I've read the opposite. Cf. Enterprise SOA by Dirk Krafzig, Karl Banke, Dirk Slama. For example, if I have a data service, what keeps me of using it as a building block? What principle is broken? What are the motivations for that principle? Javier
  26. that was my point. Viewing services as silos is a mistake.
  27. Re: misses the bigger mistakes[ Go to top ]

    We use ESB and have the following scenario: Client calls ESB but missing 1 piece of information. ESB gets the request and calls a service to get the missing information, and then route the request to the intented target service. This seems like service calling another service to provide the final result. What would be the best way to accomplish this? Ask the client to fill the missing information before going to ESB? Ask the target service to fill the missing information by directly calling the other service or going through the ESB again? Making the other service a component and ask the target service to call it? This doesn't seem to be right. Please help. I don't know how to avoid the problem of a service composed of other services in this case.
  28. Re: misses the bigger mistakes[ Go to top ]

    We use ESB and have the following scenario:

    Client calls ESB but missing 1 piece of information. ESB gets the request and calls a service to get the missing information, and then route the request to the intented target service.

    This seems like service calling another service to provide the final result. What would be the best way to accomplish this? Ask the client to fill the missing information before going to ESB? Ask the target service to fill the missing information by directly calling the other service or going through the ESB again? Making the other service a component and ask the target service to call it? This doesn't seem to be right. Please help. I don't know how to avoid the problem of a service composed of other services in this case.
    I understand your confusion and I've had the same kinds of questions. I'm relaying this recommendation from a source named Thomas Erl: http://searchwebservices.techtarget.com/tip/1,289483,sid26_gci1165286,00.html (see links at the bottom) Specifically here: http://searchwebservices.techtarget.com/tip/0,289483,sid26_gci1192369,00.html One thing that he says here is that the cost of purely autonomous services is high and may not be feasible. From what you describe, it doesn't sound too terrible. I also feel that what we call services can actually be a pure composite of services via service orchestration. That is, if you are not actually using the service inside the other service but using some top level control to call the two services, you maintain decoupling between the two services while still using them together. Finally, if you can just call the underlying code that provides the missing info without calling the service, you might want to do that instead. Honestly, I'm not sure I completely grasp the importance of service autonomy as well as I should. I feel this source is authoritative but in the end you have to make the choice an deal with the consequences. Neither Thomas Erl, myself or pretty much anyone here is going to help you fix things if this advice doesn't work for you down the road.
  29. The problem I have with Erl is that he doesn't seem to have any development background so he fails to distinguish between components and services. (In fact he seems to ignore components.) He seems to have services everywhere and at every level which is not practical, necessary or desirable. I don't recommend him to implementors at all.
  30. The problem I have with Erl is that he doesn't seem to have any development background so he fails to distinguish between components and services. (In fact he seems to ignore components.) He seems to have services everywhere and at every level which is not practical, necessary or desirable. I don't recommend him to implementors at all.
    I didn't get that at all from what I have read. What I understand him to say is that services are not the norm but are at a very high-level. For example: ...Both of these principles bring us back to the required use of the service contract. It is the content of this contract that determines what is and is not abstracted. It is through the design of this content that we can determine how generic and reusable the non-abstraced parts actually are. This raises the need to truly view the design of a service as an investment. Building service-oriented solution logic is almost always more expensive and more time consuming because considerations need to be taken into account that go beyond immediate tactical requirements. An appreciation of what service-orientation is intended to accomplish is therefore useful in justifying this investment. http://searchwebservices.techtarget.com/tip/0,289483,sid26_gci1179915,00.html This to me says very strongly that services should not be used at every level and that you shouldn't even create them if you don't understand the purpose. I believe at some point he states that having services for everything is exactly the wrong thing to do but I could be mis-attributing that. I can't really comment on his technical background.
  31. My impressions have come from what I've seen in Erl's book and from what some his disciples around here keep attributing to him. When I try to explain to them the importance of components and CBA as the foundation of SOA, they look perplexed. All they want to talk about is services. Based on what you say you've seen, maybe the confusion results from what he didn't say more than from what he did. Erl strikes me as being a business architect more than a technical architect.
  32. My impressions have come from what I've seen in Erl's book and from what some his disciples around here keep attributing to him. When I try to explain to them the importance of components and CBA as the foundation of SOA, they look perplexed. All they want to talk about is services. Based on what you say you've seen, maybe the confusion results from what he didn't say more than from what he did. Erl strikes me as being a business architect more than a technical architect.
    That may be the case. I feel that at least in the context of my employer, our services should be driven by the business needs. I think driving them from technical needs is backwards and results in the Silo-service problem we have already discussed. Perhaps Erl's writing are targeted at the business reader. I actually don't look to these writings as a technical guide or resource. To me, the value is defining things in a way that makes it possible to have a meaningful discussion. Business types, who know from their recent issue of CIO magazine that we should be doing SOA are often the hardest to talk to. Personally, I think your difference with Erl on this is with terminology. He is classifying different types of services layers some of which would map to component layers in your terminology. Personally, I prefer your terminology but perhaps there's a reason he doesn't use it if he means to target the less technical reader. I'm not saying his writings are law, I just find them to be a good starting place. I don't follow anything blindly. I'm not sure I agree with everything he says. But as a framework for discussion, I think he does a good job of defining the basic concepts involved.
  33. Re: misses the bigger mistakes[ Go to top ]

    We use ESB and have the following scenario:

    Client calls ESB but missing 1 piece of information. ESB gets the request and calls a service to get the missing information, and then route the request to the intented target service.

    That seems like a workable solution to me, but I do prefer to keep the ESB clean and let the clients or services gather the information needed to make the initial request. I think that would be acceptable if the information enrichment occurs in the adapter of the bus and not other areas. (so the adapter would gather the missing piece of information as it creates the canonical message) Having the client get the information seems like the cleanest approach and doing it in the adapter is clean enough. Enriching information in the service layer or below(top being presentation layer and bottom the data layer)is a little more tricky. Let me clarify a couple things. ESB is complementary, but different from SOA. SOA is about decoupling functionality and exposing course grained pieces of business functionality to heterogeneous systems. ESB is about how those coarse grained services call and interact with each other. SOA is about designing services that can be used by any system irregardless of implementing technology. ESB is about getting those services to talk with one another and it's easiest with the loosely coupled service oriented architecture. I also don't believe a component has to be a separate class from a service. A service can be created by simply decorating an existing component. This is what it sounds like you have. So you wouldn't need to create a new component, you already have one. So if the missing information is in another service you created, you can call the servicing component directly using JNDI or what ever technology you're using(even simply creating a new object or calling static methods directly) to fulfill the needs of SOA. If you're going for an ESB, then you may want to route every call through the bus to mask the routing of the service invocation and get all the other ESB goodness. If the missing piece of information is in a service you have no control over, or you want the ESB to route this call for you, or the other options aren't viable, then I would call the service over the bus from the needed component. The secret sauce is not including the third party service contracts in the same jar as the service contracts you create and own. That way you can create a dependency between your service implementation(aka component) and the third party or ESB services without also creating a circular dependency between your own service implementations and service contracts. So you would end up with jars like the following. common.jar - contains canonical messages and other common stuff myServiceContracts.jar - just the interfaces to the services you own. It depends on common.jar ESBServiceContracts.jar - just the interfaces to the services you don't own or want routed on the bus. It depends on common.jar myServiceImplementations.jar - the implementation of services you own. It depends on all of the above. To be totally pure, you could create separate jars for every service interface and create dependencies for the ones your using or implementing. I find this to be overkill and creates too many dependencies to management. So I'm willing to trade cleanness for easier management. So in summary, for the service layer approach... If you want an ESB or have no control over the services, I recommend routing all calls through the bus to abstract locations and get aggregation, enrichment, and all the other ESB features. If you're just going for SOA, it's acceptable to call a needed service directly from the component without going over a transport or integration platform. So why would I create a service oriented architecture and not an ESB? The more distributed systems I have, the more I am pushed to an ESB. ESBs scale better and are easier to manage than point to point or hub and spoke integration strategies. So the more things I need to glue together, the better an ESB looks. I hope this helps.
  34. pfft!.. what a neophyte!!