Discussions

News: Demand High for Java Pros that Can Build 'Business-Savvy' SOAs

  1. During 2005, demand will be huge for Java developers and architects that can build SOA apps that 'connect-the-dots' between IT practices and business goals. Execs at SAP share insights about how F500 firms are looking at a "flexible" Enterprise Service Architecture that blends the best mission-criticality of Java/J2EE with low-cost, flexible ways to modify/update business apps to meet those pesky -- always changing -- business goals.

    In this technical look at what F500 IT shops are looking for, SAP execs
    explain:
    * How Java developers are architects can play a much bigger role in creating a more flexible software architecture for business;
    * The real goals behind cost-containment in software (HINT: It's not just about cutting IT budgets); and *How F500 demand for a new software approach that lets business execs quickly leverage existing software for new projects will spell huge upside for Java/J2EE developers and architects that think outside the container.

    Full Story:
    http://www.idevnews.com/IntegrationNews.asp?ID=156

    Threaded Messages (22)

  2. same thing for PeopleSoft...
  3. SOA[ Go to top ]

    On paper, it all sounds very nice - loosely coupled enterprise services, composite applications made up of enterprise services but sometimes I wonder if people are going overboard with these ideas.

    For example, I have a client who maybe taking this even-driven, loosely coupled mantra to new levels - they are planning to use an architecture where the interaction between the presentation layer (Servlets/JSP) and the business logic layer(EJBs/POJOs) is via a Message Bus/synchronous MQ/JMS request-reply model. So, controller servlets, after parsing the request will drop off XML messages (yikes!) to an MQ queue and block waiting to get a response back from the back end. Meanwhile, the message will travel to a message bus which will route it to an 'appropriate' back end system and reroute the response similarly on the way back. Apparently this will 'decouple' the presentation layer from the back end API dependencies. They have plans of being able to 'reuse' presnetation layer with different backend systems and apparently a message bus mediating between presentation layer and business logic layer would give them that flexibility but I can't help feeling that goal may be a bit impractical.

    I keep wondering what this model will do to the latency of the system, specially when you have so many message hops - imagine the messages making their way into the bus, out of it (possibly with transformation) and into the backend and all this time the user at the browser is waiting for that hourglass to go away! And not to mention that unnecessary marshaling/demarshaling of Java<->XML.

    Anyone has come across this type of architecture anywhere?
  4. Collossal Failure ahead[ Go to top ]

    This is what happens, I guess, when people get carried away. Yes, I have worked a place where they attempted something more insane. They took incoming web requests converted them to XML, mapped them to a serialized corba service that was stored in LDAP to call a backend process. And as you can imagine it was a complete failure. Fortunately for me I didn't have to work on that project.
  5. SOA[ Go to top ]

    Hi Drew,

    I have seen this type of architecture couple of years ago during the webservices frenzy times. I was asked by upper level management to use Tibco IB and webservices for connecting servlets in our portals with our business service facades(SLSBs in Weblogic). Interestingly both Servlets and EJBs were deployed on Weblogic. Eventually we did load and scalability test and eventually convinced them what a teribble architectural approach it was. But I think that was just taking this webservices and ESB mantra too literally. Common sense should be used for the approprateness of technologies.

    What SAP is saying in ESA sounds very similar to what BEA has been saying in the PDD(process driven dev.). You use webservices and XML to reuse your existing resources to build a composite enterprise application as reusable process. That does not mean use webservices to communicate between Servlets and EJBs. If you have multiple technologies in your enterprise, say credit processing in C++, Inventory management in COBOL and order processing in Java, use webservices as a common integration approach between them to create a composite app. SAP netweaver supports ESA. Similarly BEA's WLI provides similar architectural approach also. I am sure there are many other vendor's providing similar architectures in their tools too.

    Thanks.

    Bijan
  6. SOA[ Go to top ]

    Well, thankfully there has not been any talk of sending SOAP messages back and forth, at least not yet :-)

    And I have another fundamental problem with this kind of messaging approach - you lose control over the transactional boundaries which would be relatively easy to handle with 2pc in a synchronous RPC style interaction. There are already talks about situations where one message coming out of presentation layer will be split up into different messages going out to different backend systems...once these messages are dequeued at the backends you have lost any 2pc capabilities the application server, JDBC drivers and the resource managers would have given you in a straightforward RPC scenario. I shudder to think about handrolling a compensation based tx management framework now...
  7. SOA[ Go to top ]

    There is no problem with this approach if:
    1. The back end system (as in a different enterprise application) + Front end do not have to be in a transaction

    2. The front end has some type of DBMS/datastore to store the data (for operational purposes)

    3. The most important thing here is that there has to be a very good reason for the front end NOT to be able to talk directly to the backend enterprise app

    Just my 2 cents.........
  8. SOA[ Go to top ]

    On paper, it all sounds very nice - loosely coupled enterprise services,

    Agreed. Probably one of the most unsignificant buzzword these days !
    Loosely coupled = weak type checking = messages being "skipped" by processors who can't understand them...
    Please someone tell me what's the point in calling a service for... nothing !!!
    composite applications made up of enterprise services

    Well, that makes more sense. COP is finally something we all do (EJBs, etc.).
    I don't have problems in building modular, *component*-based applications. But once again a *component* is slighly different from a "service".
    What they talk about make me think of old Pascal units or C headers ! If WebServices are there only to provide plain procedural wrappers (and that's more or less what they are), then why would anyone choose this ? Encapsulating logic in *functions* is something we now know... and usually try to avoid (put all this in *objects*) !
    but sometimes I wonder if people are going overboard with these ideas.

    Well, WSs mood is all about this IMHO (see the thread
    http://www.theserverside.com/news/thread.tss?thread_id=31673
    ). This technology *is* basic and allows yet a very few things. This must be the simplest middleware on the market ! The noise around it is abnormal IMHO. And I'm not alone thinking this...
    they are planning to use an architecture where the interaction between the presentation layer (Servlets/JSP) and the business logic layer(EJBs/POJOs) is via a Message Bus/synchronous MQ/JMS request-reply model.

    Isn't this hectic ?
    Java on one side, Java on the other, and XML in the middle ????
    Apparently this will 'decouple' the presentation layer from the back end API dependencies.

    True. But awful IMHO !
    You can change the back-end, the front-end still compiles.
    But think one "participant" transforms the message (or sends it) in a way that others can't understand it ?
    How errors can be handled there ?
    I like the fact that "components" are bound to ther components through the contract. This is the basis of OOP. Ya know, encapsulate your stuff...
    Where is the contract is that architecture where untyped messages circulate between protagonists ??
    It has none :-/
    They have plans of being able to 'reuse' presnetation layer with different backend systems

    Well, you can use a Swing app as a front end to any EJBs or remote objects... until they have the same contract. Same considerations apply here I think... It works if and only if the presentation layer understands the "loosely coupled" messages. And there's no way to know that other than at run-time (good debug hours in perspective ;-P).
    and apparently a message bus mediating between presentation layer and business logic layer would give them that flexibility but I can't help feeling that goal may be a bit impractical.

    Well, you can do it IMHO, but this does not bring any improvement !
    Once again, from a front-end tier, one could "switch" back-end "implementation" (non contract change) with regular EJBs, CORBA Objects or RMI if they implement the same interface(s)... just like the client does not care if the beans are CMP or BMP, etc.
    Their stuff is similar, but you don't have compile-type strong type checking like you'd have in RMI or CORBA... So you only know if it's OK when your client tries to send XML to/receive XML from the mediator...

    Fingers crossed...
    Launch app...
    Go and get a coffee while it tries parsing huge text data for nothing...
    Get back and see it failed (not how of course !).
    Spend hours to finally find the bug : there's a mistake in an XML doc somewhere, the DTD has changed !

    Is this the next-generation software architecture ?
    I don't think so.
    I keep wondering what this model will do to the latency of the system, specially when you have so many message hops - imagine the messages making their way into the bus, out of it (possibly with transformation) and into the backend and all this time the user at the browser is waiting for that hourglass to go away! And not to mention that unnecessary marshaling/demarshaling of Java<->XML.

    Instead of passing Java over RMI... What a waste (both in terms of semantics and performance btw) :-)
    Anyone has come across this type of architecture anywhere?

    Never seen that. Hope I'll never have to put my hands in such stuff !
    "Does anone know where my f*ckin' message is ??? You got it ?"
    :-)

    Cheers

    Remi
  9. SOA (rules of thumb for async EDA)[ Go to top ]

    Drew --
    [... async / EDA ...] I keep wondering what this model will do to the latency of the system, specially when you have so many message hops - imagine the messages making their way into the bus, out of it (possibly with transformation) and into the backend and all this time the user at the browser is waiting for that hourglass to go away! And not to mention that unnecessary marshaling/demarshaling of Java<->XML.Anyone has come across this type of architecture anywhere?

    There are two distinct considerations that are getting mixed here. First, there's the question of the value of the abstraction, i.e., does this approach make the system simpler to build, extend, and maintain? Second, there's the question of whether the system performs adequately at runtime.

    Next, if the answer to the first question is an emphatic yes, then there are two things to do. First, take the initial marketecture and start asking questions to be sure that any assumptions are validated by requirements or by strategic architectural directives. (You may or may not have the ability to question those directives.) Next, take the architecture (defined as min(max(strategy,requirements),marketecture), build a prototype, and invest effort to resolve any performance bottlenecks that are identified after the prototype is tested. All performance bottlenecks are imaginary until seen in production, and experience will tell you that the ones you expect will not be the major offenders on a first pass. (That said, asynchronous architectures are typically better for throughput than for latency, so a requirement for sub-subsecond latency should lead to a very shallow initial prototype.)

    As for having seen this type of asynchronous, event-driven architecture, I see it on a daily basis...
  10. SOA (rules of thumb for async EDA)[ Go to top ]

    Paul,

    <
    Even-driven, maybe, asynchronous, no! The architecture I talked about is a pure synchronous request/reply model where the message producer, after producing the request message blocks waiting for the reply message to show up in the reply queue. Remember, you have to make that guy at the browser wait till he sees a page coming back. Incidentally this model also takes the sheen out of that 'loosely coupled' claim because the producer in this case *does* care if the consumer is up or not.

    In general, I agree with you that there are two concerns here - one is the flexibility of no direct dependence between the PL and the BL and the other being the more implementation related performance concern. While it is true that some bottlenecks may only be imaginary it is always a good idea to keep well known performance patterns(or more appropriately, anti-patterns) in mind when you come up with an architecture though things may vary from system to system. I'm not sure about the latency part until we run some tests but XML<->Java deserialization/serialization between two Java based systems is something I am wary of waiting and seeing if it does bite me in the rear come production time.

    But I can see where you are coming from, being a process execution and service orchestration vendor ;-)
  11. SOA (rules of thumb for async EDA)[ Go to top ]

    Drew --
    But I can see where you are coming from, being a process execution and service orchestration vendor ;-)

    Guilty as charged for being a little biased.
    Event-driven, maybe, asynchronous, no! The architecture I talked about is a pure synchronous request/reply model where the message producer, after producing the request message blocks waiting for the reply message to show up in the reply queue.

    Absolutely, and this is OK. I'm only trying to make the point that this is synchronous from the perspective of the remote client and the endpoint that's connected to the bus. (There are a good number of ways to design that client's contract with the bus, depending on how you want to do it...) Even in a traditional web application, there's a good chance that you're unknowingly blocking for the database, blocking for connection pools, etc. It's only in this particular case that you're directly aware of the asynchronous nature of things. (That said, the blocking should be cleanly separated from the client implementation -- making it simple to develop clients is the goal, after all!)
    I'm not sure about the latency part until we run some tests but XML<->Java deserialization/serialization between two Java based systems is something I am wary of waiting and seeing if it does bite me in the rear come production time.

    All of the usual advice about serialization applies if you find that it's the bottleneck. You might want to prototype with JAXB or JIBX and then consider a more specific solution if performance turns out to be an issue. You can also consider SOAP or not depending on the requirements for the other clients and the future evolution of the system, or if you have problems in one place, you could look at a lazy approach for mapping between Java and XML or XML and Java that is the responsibility of the receiving client in each case.
  12. Even-driven, maybe, asynchronous, no! The architecture I talked about is a pure synchronous request/reply model where the message producer, after producing the request message blocks waiting for the reply message to show up in the reply queue. Remember, you have to make that guy at the browser wait till he sees a page coming back. Incidentally this model also takes the sheen out of that 'loosely coupled' claim because the producer in this case *does* care if the consumer is up or not.
    Hmm...
    1. Obtain input from the user, and submit it to web front app.
    2. Web front app starts a new service thread in which it updates database/sends a message/does other backend task
    3. After service thread is started, web front app immediately responds with redirect
    4. Client is not synched to the server anymore, it is redirected to the location where the results are (or will be, after database/message queue/whatever finishes its work)
    5. Client loads the result and waits until it is available ASYNCHRONOUSLY FROM ORIGINAL REQUEST

    This pattern looks familiar... ;)
  13. SOA (rules of thumb for async EDA)[ Go to top ]

    Its important to use the right technologies and methods for for your particular Application archtecture requirements. Some of the disaster projects listed above sound like EDA anti-patterns. The problem is technologies and architecture styles often get embraced for the wrong reasons (usually because they are touted as the silver bullet to solve our enterprise needs). Most of you here are talking about web-app request/response scenarios where EDA isn't that effective unless you can parallelise various chunks of work to process the request. If each bit of processing is dependent on the previous you may as well choose RPC as you'll cut out the overhead of XML de/serialisation.

    However, RPC doesn't work well with application integration because there is no allowance for what I call 'the contract addendum' Where an application being integrated needs more information than what is currently exposed by your remote API. In order to allow this application to integrate with your exisiting infrastucture you have to alter existing interfaces making the integration strategy brittle. By decoupling your applications via a message architecture, you are saying that the message format on the bus is the contract between your applications. This is far more flexible as you can add additional contact information to message that is only used by applications that need it, whilst not affecting the other applications.

    EDA also works well in business process, workflow and orchestration applications where events may be passed around many applications and services before reaching a final destination, that may well trigger further events. The importance of decoupling here is paramount because business processes change, new systems are introduced or taken off-line and the architecture needs to be resilient enough to cope with this; something that RPC isn't good at.

    Cheers,

    Ross
    http://www.muleumo.org
  14. SOA (rules of thumb for async EDA)[ Go to top ]

    However, RPC doesn't work well with application integration because there is no allowance for what I call 'the contract addendum' Where an application being integrated needs more information than what is currently exposed by your remote API. In order to allow this application to integrate with your exisiting infrastucture you have to alter existing interfaces making the integration strategy brittle. By decoupling your applications via a message architecture, you are saying that the message format on the bus is the contract between your applications. This is far more flexible as you can add additional contact information to message that is only used by applications that need it, whilst not affecting the other applications.

    This issue is about polymorphic content of the message, not the level of coupling the call protocol imposes. If the RPC header (the contract) allows a polymorphic parameter, you achieve both loose coupling and transactionality.

    You may still need XML to express polymorphism if you are unsure that both ends of the chain are implemented in java. I have a production system that uses this approach: CORBA call as transport protocol, including routing/security/transaction information, XML as information content of the message. No one of the routing nodes (three in the simplest scenario) need parse any XML, only the final recipient, or any intermediate content consumer, does. And the call protocol allows for both synchronous and asynchronous interactions. Of course that would work also with plain RMI, less efficiently with JMS which is async/non-transactional only.

    In my experience, whenever an architecture introduces the concept of bus, the reason lies in the architects not knowing how to make the components interact, i.e. unclear contract. In the end, the result will be tightly coupled endpoints that fake loose coupling, with all the overhead of the additional protocols added to the need of maintaining transactional / conversational state by means of application component tweaking: keep track of transaction ID everywhere, duplicate data on local DBs just in case the "asynchronous bus" does not deliver it and does not tell us it did not, etc.
    The importance of decoupling here is paramount because business processes change, new systems are introduced or taken off-line and the architecture needs to be resilient enough to cope with this; something that RPC isn't good at.

    This is the difference between RPC and RMI. The call method is the same. But RMI is polymorphic, so it has an extensible contract, whereas RPC does not. And note that you can use RMI with stateless objects in a full-fledged SOA.
  15. In my experience, whenever an architecture introduces the concept of bus, the reason lies in the architects not knowing how to make the components interact, i.e. unclear contract. In the end, the result will be tightly coupled endpoints that fake loose coupling,
    You nail it down. Next thing we hear scream: "business requirements have changed! - now we have to redo everything" :)
  16. SOA (rules of thumb for async EDA)[ Go to top ]

    By decoupling your applications via a message architecture, you are saying that the message format on the bus is the contract between your applications. This is far more flexible as you can add additional contact information to message that is only used by applications that need it, whilst not affecting the other applications.

    Agreed. All of what you've said is very true for heterogeneuos application integration scenarios. However, the shop I'm in takes an extreme view of integration in that they consider interaction between the front-end and the back end to be more of an application integration scenario. Apparently they could potentially have different types of front ends requesting services from the same backend and in their view messages should be the service contracts (not the backend component methods or aggregations thereof exposed in a sync/async fashion which is the more usual view) and that's why this insistence on being able to 'reuse' the messages to the extent that in the event the backend changes, the front-ends can still interoperate with the different backend through the same messages. They attach more importance to the data inside those messages, probably more of a reflection of the fact that this shop is more of a data modeler's world where it's the data that drives the business logic. Not that I'm saying it should be the other way round. But that's a topic for another debate :-)
  17. SOA[ Go to top ]

    Sounds like another classic case of "resume-driven" architecture.
  18. SOA[ Go to top ]

    they are planning to use an architecture where the interaction between the presentation layer (Servlets/JSP) and the business logic layer(EJBs/POJOs) is via a Message Bus/synchronous MQ/JMS request-reply model

    This is a total bastardization of SOA. True SOA advocates large-grained services with a small "surface area". That is, services should do something more meaningful than render HTML and the messages between services should not be RMI style chatting. The absolute worst thing I ever heard was a so-called expert from IBM suggesting you ought to create a "logger service". Yes, that's right. Why couple your application to a specific logging implementation, when you can just invoke a web-service instead? Arghhhh...
  19. SOA[ Go to top ]

    The absolute worst thing I ever heard was a so-called expert from IBM suggesting you ought to create a "logger service". Yes, that's right. Why couple your application to a specific logging implementation, when you can just invoke a web-service instead? Arghhhh...

    Jacob,

    I don’t understand your statement. Are you're stating that it would be wrong to create a logging service but correct to create logging web-service?

    I would have though that logging functionality is an ideal candidate for a low-level 'core' service. A single place to log and view those logs across the enterprise using consistent logging structures. This is especially important when implementing large, distributed systems where it is notoriously difficult to trace threads of activity.
  20. SOA[ Go to top ]

    The absolute worst thing I ever heard was a so-called expert from IBM suggesting you ought to create a "logger service". Yes, that's right. Why couple your application to a specific logging implementation, when you can just invoke a web-service instead? Arghhhh...
    Jacob,I don’t understand your statement. Are you're stating that it would be wrong to create a logging service but correct to create logging web-service?I would have though that logging functionality is an ideal candidate for a low-level 'core' service. A single place to log and view those logs across the enterprise using consistent logging structures. This is especially important when implementing large, distributed systems where it is notoriously difficult to trace threads of activity.

    Having a single place to store logs is not necessarily the same thing as having a logging service. Do you really want to invoke a web service every time you log a message? That's would make me go "Arghhhh..." too. In fact, it did. It especially seems like one of those tight couplings that SOA is supposed to avoid. What happens when the logging server dies? Do you lose all the messages or do the processes hang?
  21. best mission-criticality of Java/J2EE with low-cost, flexible ways to modify/update business apps to meet those pesky -- always changing -- business goals.
    “Changing business requirements” – that is favorite song of unskilled architects who cannot accommodate pretty predictable and small requirements into lame architecture.

    Just 2c observation
  22. "Changing business requirements" that is favorite song of unskilled architects who cannot accommodate pretty predictable and small requirements into lame architecture.Just 2c observation

    Wow, wow ! Hold on a minute. Thausands of big and small companies die each year because they cannot predict market changes and accomodate their businees according to those changes. How on earth it suddenly become "pretty predictable and small requirements" ? Does your business never change ?
  23. Nice story, but[ Go to top ]

    nothing is really new.

    For me what the author described "ESA" is not much different from the business process management (BPM) system people have been talking, developing and using for so many years.

    Web service just gives BPM a better/new way to integrate in between heterogenous systems.

    One thing I do agree, companies start utilizing Web services and SOA to implement some real and mission critical applications. Still, a lot of lessons need to be learnt.