Discussions

News: IBM and BEA Partners in Crime, Announcing Joint Specifications

  1. IBM and BEA are collaborating on specifications that will enable developers to write code that accesses some areas of the application server in a standard manner (e.g. it will work in both servers). The companies announced three specifications: Service Data Objects, WorkManager and Timers.

    Service Data Objects

    Service Data Objects (SDO) is designed to simplify and unify the way in which applications handle data. Using SDO, application programmers can uniformly access and manipulate data from heterogeneous data sources, including relational databases, XML data sources, Web services, and enterprise information systems. For more information about the goals and architecture of SDO, see the whitepaper "Next-Generation Data Programming: Service Data Objects."

    Download resources:

  2. Service Data Objects specification:
  3. Next-Generation Data Programming: Service Data Objects white paper (pdf)
  4. SDO Javadoc (zip)
  5. SDO Java API sources (zip)


  6. WorkManager

    The Work Manager for Application Servers specification provides an API for application-server supported concurrent execution of work items. This enables J2EE-based applications, including servlets and EJB apps, to schedule work items for concurrent execution. This will provide greater throughput and better response time. After an application submits work items to a Work Manager for concurrent execution, the application can gather the results. The Work Manager provides common "join" operations, such as waiting for any or all work items to complete. The Work Manager for Application Servers specification provides an application-server-supported alternative to using lower-level threading APIs, which are inappropriate for use in managed environments, as well as being too difficult to use for most applications.

    Download resources:

  7. Work Manager for Application Servers specification
  8. Work Manager Javadoc (zip)
  9. Work Manager Java API sources (zip)


  10. Timers

    The Timer for Application Servers specification provides an API for using timers in an application-server supported fashion. This enables J2EE-based applications, including servlets, EJB apps, and JCA Resource Adapters, to schedule future timer notifications and receive timer notifications. The Timer for Application Servers specification provides an application-server supported alternative to using the J2SE java.util.Timer class, which is inappropriate for use in managed environments.

    Download resources:

  11. Timer for Application Servers specification
  12. Timer Javadoc (zip)
  13. Timer Java API sources (zip)


  14. Read More

    IBM Site: Specifications: Service Data Objects, WorkManager, and Timers

    BEA Site: BEA and IBM Joint Specifications

    IBM, BEA join on Java strategy

Threaded Messages (51)

  • Ok, so I think I get it...

    Service Data Objects = object model that does what EJBs were supposed to do but are more portable and easier to integrate with other Service Objects.

    Timers = cron jobs for the Java platform

    But I don't get WorkManager? I thought IBM and BEA were big proponents of BPEL4WS? How would an API that manages "concurrent execution of work items" coexist with a workflow manager? When work items are running concurrently the object model will need to support dynamic decisions based on the results of the work items. Isn't that workflow?

    Don't get me wrong. I'm not complaining about these. I see my company (www.PushToTest.com) making pretty good money providing enterprises with best practices to build scalable and well performing systems built with Service Data Objects. Boy does that sound like a big testing project! :-) Come on in boys the water sure is warm!

    -Frank Cohen
    http://www.pushtotest.com
    Free open-source test automation tools
  • Hi Frank,

    > But I don't get WorkManager? I thought IBM and BEA were big proponents of BPEL4WS? How would an API that manages "concurrent execution of work items" coexist with a workflow manager? When work items are running concurrently the object model will need to support dynamic decisions based on the results of the work items. Isn't that workflow?

    WorkManager is a lower level primitive than a complete workflow manager/engine. I would envision that workflow engines would make use of something like this WorkManager API. Workflow engines need to do things like execute a business process specified in a flow language like BPEL, maintain potentially long-running state, etc.

    So, WorkManager is just a nice concurrency utility that meets the sweet spot of what app developers commonly need. There are a few other standards efforts in this area:
     - The just-approved JCA 1.5 spec has a Work Manager, but it is specific to JCA. We needed something more generic that can be used in EJBs, Servlets, or any other managed environment.
     - This WorkManager is similar in purpose to the Executor and ExecutorService interfaces in the up-and-coming JSR-166 ("Concurrency Utilities") that is slated for Tiger/J2SE 1.5. Note that JSR-166 doesn't explicitly create an API for managed environments/containers, and that the timing is off for using 166's java.util.concurrent interfaces in a J2EE 1.4 timeframe.
  • New Threads?[ Go to top ]

    I've gotten used to hearing Java technologists begin talks about concurrency with the "Java threading is bad and needs fixing" mantra. It seems like Work Manager adds another layer on top of the current thread model. To bad the proposed new spec isn't titled "New Threads".

    -Frank
  • Trojan horse ?[ Go to top ]

    Let's see :

    Service Data Objects : seems like JDO

    WorkManager : Good, doesn't covered by J2EE specs

    Timers : J2EE 1.4 Timer Service

    I think that these specifications hide some danger behind.

    First : It seems like a way to attract people to these platforms. A very good marketing strategy would be: "Hey guy, BEA WebLogic and IBM WebSphere have many parts portable". Nothing more far to the reality.

    Second : I'm not sure if developing specs. offside JCP umbrella is a good thing for J2EE. This doesn't promote anyway competitiveness. BEA and IBM will have the late word for this specs.

    In resume, I think that this is a clear step to fight agains open application servers like JOnAS, JBoss and those that will appear in the future.

    Martín
  • Trojan horse ?[ Go to top ]

    Let's see :

    >
    > Service Data Objects : seems like JDO

    Not quite... So, the main idea behind SDO is to provide uniform client access to heterogenous data sources. Towards this end, the core SDO spec provides a dynamic data API and a metadata API, as well as a general pattern for how collections of data are retrieved, mutated, and committed back. It doesn't provide transparent persistence for JavaBeans, like JDO does. The two concepts are generally orthogonal and complementary, although there is naturally an interface point between SDO and other persistence technologies. The intent is that SDO integrates nicely with other persistence mechanisms--the whole point is to provide uniformity such that programmers, tools, frameworks can treat data uniformly. But SDO is not always what the programmer needs or wants--sometimes your CMP entity beans, JDO, Hibernate or whatever is fine.

    To show that there is some precedent here, someone just recently pointed me at OpenSymphony's (the WebWork people) PropertySet (http://www.opensymphony.com/propertyset/). This has aspects of the core SDO concept of a dynamic data API that can be used acrossed heterogenous data sources.

    > WorkManager : Good, doesn't covered by J2EE specs
    >
    > Timers : J2EE 1.4 Timer Service

    Yes, EJB 2.1 introduces a timer service. It's EJB specific though. For more motivation, check out Billy Newport's blog on why we need something beyond java.util.Timer and the ejb timer service:

    http://bnewport.typepad.com/devwebsphere/2003/09/j2se_timer_lets.html

     
    > I think that these specifications hide some danger behind.
    >
    > First : It seems like a way to attract people to these platforms. A very good marketing strategy would be: "Hey guy, BEA WebLogic and IBM WebSphere have many parts portable". Nothing more far to the reality.
    >
    > Second : I'm not sure if developing specs. offside JCP umbrella is a good thing for J2EE. This doesn't promote anyway competitiveness. BEA and IBM will have the late word for this specs.

    As has been mentioned in the news articles and explained at http://dev2dev.bea.com/technologies/commonj/index.jsp, JSR proposals are being submitted to the JCP for these specification areas.


    > In resume, I think that this is a clear step to fight agains open application servers like JOnAS, JBoss and those that will appear in the future.

    These specs that IBM and BEA published are royalty free--implementations from both open source and commercial vendors are welcome. This should promote experimentation, feedback, refinement, etc. and should provide valuable information into the expert groups in the JCP.
  • Re: Trojan horse ?[ Go to top ]

    Thanks for your comments John, they have been very explanatory. I'll quote some of them.

    >
    > JSR proposals are being submitted to the JCP for these specification areas.

    That will be good.


    > These specs that IBM and BEA published are royalty free--implementations from both open source and commercial vendors are welcome. This should promote experimentation, feedback, refinement, etc. and should provide valuable information into the expert groups in the JCP.

    Yes, but the problem I see is that BEA and IBM take advantage of their big staffs to develope some 'standard' and 'open' extensions. Yes, they are royalty-free but open source applications servers cannot affront the implementations of all the open standards out there. Open source servers can afford easily the implementation of a standard lead by a community like JCP because in such scenario all the competitors have equality conditions. But, to me, there is no doubt that in thise case BEA and IBM are trying to play with advantage.

    Anyway, I think, as a developer, that innovation and competition is always good for us.
  • SDO, Trojan horse ?[ Go to top ]

    So, the main idea behind SDO is to provide uniform client access to heterogenous data sources.

    That's just a glimpse of how service data can be used. The Global Grid Forum also imagines distributed indexes of service data to support monitoring and discovery. If service availability is itself modeled as service data, this enables service registries and groups, akin to JXTA peer groups, Jini federations, or UDDI. That's a crucial part of autonomic computing. While it's too late for the upcoming WSDL 1.2, there's rumor that service data might appear in WSDL 2.0.
  • Re: Trojan horse ?[ Go to top ]

    Martin,
    SDOs are nothing like JDOs. An SDO is kind of like ADO objects from Microsoft. You'd use an SDO to return a set of records/rows/data from a service to a client. The SDO is self describing. It's pretty useful IMHO.

    Timers are not the same as J2EE 1.4 Timers. Timers allow a POJO to be invoked at a later time, it's like a managed J2SE Timer. So, a servlet can use Timers to invoke a POJO in 10 seconds without writing an EJB but if the servlet application crashes then the timer is lost. It's a transient or non persistent timer.

    As for your summary point, I disagree. JBoss or Jonas can completely free to implement these interfaces themselves and I wouldn't be surprised at all to see them provide the first public implementations of these APIs before the J2EE vendors do :)

    Billy
  • New Timer?[ Go to top ]

    Yes, EJB 2.1 introduces a timer service. It's EJB specific though.

    >For more motivation, check out Billy Newport's blog on why we need
    >something beyond java.util.Timer and the ejb timer service:

    >http://bnewport.typepad.com/devwebsphere/2003/09/j2se_timer_lets.html

    I just read the blog and though I agree with him, one thing stuck me as odd. So ok J2SE's timer is bad but the new J2EE 1.4 Timer??? What happened to JCP when they come up with the Timer? Now if ppl realized that it's not a good solution then why pass it?

    I'm kinda sick of ppl saying this is not good and that is bad. With JCP we should have been able to prevent it in the first place, not when it's done and shipping to the mass.
  • Seems to be confusion.[ Go to top ]

    WorkManager adds application threading to J2EE applications like async beans in WAS 5.0E. It's not about workflow, it's about finally adding threading to J2EE applications. It basically allows servlets and EJBs to create short lived or daemon threads and also supports a wait/join primitive to allow the application to block until one or all of those threads finish.

    The Timer support is basically a managed J2SE Timer, it's different than the EJB 2.1 Timer because the timers are transient, non persistent, non transactional. Example, suppose you wanted to prune an inmemory cache every 30 seconds, you'd use a Timer, not an EJB 2.1 Timer bean. I hope thats a good example.

    Billy
    (IBM)
  • Good Example?[ Go to top ]

    "Example, suppose you wanted to prune an inmemory cache every 30 seconds, you'd use a Timer, not an EJB 2.1 Timer bean. I hope thats a good example."

    Billy, should the cache service not handle this itself. How many cache products do not come with such a configuration? Maybe I am confused by the term "inmemory cache"? How is this cache deployed and accessed? This seems more like container/system internals than application development.

    Is the intended API user a cache or similiar embedded enterpise service provider?

    I am sure the proposed service(s) are required and useful for some customers, its just I think a better example is required, ;-).

    Regards,

    William Louth
    Product Architect
    JInspired

    "Tune and Test with Insight"
    www.jinspired.com
  • Seems to be confusion.[ Go to top ]

    WorkManager adds application threading to J2EE applications like async beans in WAS 5.0E. It's not about workflow, it's about finally adding threading to J2EE applications. It basically allows servlets and EJBs to create short lived or daemon threads and also supports a wait/join primitive to allow the application to block until one or all of those threads finish.

    >

    I'd rather see these specifications address a common way to locate the TransactionManager and a common way to propagate security credentials to another Thread(or if there is one excuse my ignorance). I've found spec created work managers, like JCA's for instance, to by clunky, over designed, and usually non-optimal. I find writing my own threading to be more maintainable and more performant. So, again, back to my point, standardize on tx and sec lookup and propagation. Something as simple as providing an extension of java.lang.Thread that abstracts-out propagation may be sufficient enough.

    Bill
  • Seems to be confusion.[ Go to top ]

    |
    |I find writing my own threading to be more maintainable and more performant.
    |

    Except for the fact that creating your own threads completely bypasses any thread-pooling (ie perf tuning) which affects the whole server - let alone the appserver.

    But I agree with you - I dont remember reading anything about security/transaction context propagation.
    Is that intended to be addressed?

    -Nick
  • Seems to be confusion.[ Go to top ]

    The J2EE context of the creator is propagated to the POJO Work/Timer. The POJO can use the java:comp of the web app that created the Work/Timer. If the creator of the Work/Timer was authenticated and then it starts a Work/Timer then the POJO when invoked will also be authenticated.

    The POJO can start transactions just like normal J2EE code.

    Billy
  • Seems to be confusion.[ Go to top ]

    There is also the point that one is expressly forbidden to start a thread within the context of an EJB invocation... ;)

    I've seen many, many different approaches to trying to work around threading issues within an EJB-based system. It seems that the WorkManager will finally provide a mechanism to work with the container to manage threading. This seems like Goodness to me.

    Dave
  • Re: Seems to be confusion.[ Go to top ]

    From the original blog:

    ---------------------------
    So, servlet customers can use JavaBeans as their listeners and when they are invoked on these asynchronous events, then they have access to the JNDI from the owning webapp, the security credential (if present). The JNDI is important because when an application looks up databases, ejbs or web services then it does this through JNDI. If the JNDI for the creating component was not available then the absolute JNDI name would have to be hard coded (or property) in the application, this defeats the reasoning behind the whole ref thing.
    ----------------------------

    It's not clear to me that what is proposed achieves any of this. There is
    no specified or implied relationship in the specification between the JNDI
    environment in the listener and that of the timer owner. Can the TimerListener
    use the java:comp/env space of the web app that created the timer?

    Kim Topley
  • Re: Seems to be confusion.[ Go to top ]

    It's not clear to me that what is proposed achieves any of this. There is

    > no specified or implied relationship in the specification between the JNDI
    > environment in the listener and that of the timer owner. Can the TimerListener
    > use the java:comp/env space of the web app that created the timer?
    >
    > Kim Topley

    Yes.
  • Re: Seems to be confusion.[ Go to top ]

    Thanks for the clarification. Is this recorded somewhere in the
    specification? Seems like it should be, especially if you want to
    enable third-party implementations. I wouldn't want to develop an
    application making this assumption unless I could see it somewhere
    in black and white.
  • Re: Seems to be confusion.[ Go to top ]

    It's in the JavaDocs, I think people may be just reading the white paper. The JavaDocs have a lot more information.

    There will be a TCK to verify correct interpretation and I guess the docs will improve with feedback :)

    Billy
  • POJO Timer[ Go to top ]

    Is there a good framework?

    I have a cache that wishes to reset ...
  • Hi,
    Is IBM and BEA going Microsoft way by introducing these services.
    I seriously think this will defy the very purpose of EJB's i.e Portability.

    Any comments ?

    Cheers !!!
    Aashish
  • <!-- Is IBM and BEA going Microsoft way by introducing these services.
     I seriously think this will defy the very purpose of EJB's i.e Portability.-->

    I think you are right. This kind of attitude can not only hurt EJB/J2EE, but the whole JCP. If you see software industry patterns closely I think IBM is the biggest monoply in the market,even bigger than Microsoft. First they supported standard to kill the competition,then they are trying to eliminate it by defying the process. Good move:-)
  • <!-- Is IBM and BEA going Microsoft way by introducing these services.

    >  I seriously think this will defy the very purpose of EJB's i.e Portability.-->
    >
    > I think you are right. This kind of attitude can not only hurt EJB/J2EE, but the whole JCP. If you see software industry patterns closely I think IBM is the biggest monoply in the market,even bigger than Microsoft. First they supported standard to kill the competition,then they are trying to eliminate it by defying the process. Good move:-)


    I don't see how this hurts EJB, J2EE, the JCP or anyone else. Don't the JSRs usually come from vendors anyway? I might agree with you if IBM (or BEA) was going it alone, but in this case, the fact that it is coming from 2 main vendors will hopefully speed up the process of getting important features into J2EE.
    From what I've seen, it looks like IBM and BEA are doing the right thing.
    How does this hurt anything?
  • <!--I don't see how this hurts EJB, J2EE, the JCP or anyone else. Don't the JSRs usually come from vendors anyway? -->

    Yes, but they have to go through an approval community. If the community don't pass it, they can not proceed. That is the power of community and that was my point. Come through the proper channel don't invent your own wheel.
  • The problem with JCP[ Go to top ]

    While I like the concept of the JCP, in practice it tends to move pretty slowly.

    Not to mention I think BEA and IBM are joining forces to combat the rising trend against free application servers. Although it does seem like strange bedfellows, it's in their own best interests to develop some sort of unifying standard to make themselves look like they have an edge on JBoss and the like.

    I don't think it's a good business practice to always consult with your competitors first, which is what the JCP forces them to do.

    And hey, if no one likes it and it blows up in their face, that's just a chance they'll have to take. Not that IBM is going anywhere anytime soon.
  • <!--I don't see how this hurts EJB, J2EE, the JCP or anyone else. Don't the JSRs usually come from vendors anyway? -->

    >
    > Yes, but they have to go through an approval community. If the community don't pass it, they can not proceed. That is the power of community and that was my point. Come through the proper channel don't invent your own wheel.


    That is my point as well. They are ultimately going through the right channel, they are just speeding up the process by ensuring that at least 2 major vendors already agree on what the feature is and what the interfaces should look like. It always seems like everyone is complaining about the slowness of the JCP. To me, this shows how vendors can cooperate to speed things up, while still ensuring portability.
  • they are just speeding up the process by ensuring that at least 2 major vendors already agree on what the feature is and what the interfaces should look like. It always seems like everyone is complaining about the slowness of the JCP. To me, this shows how vendors can cooperate to speed things up, while still ensuring portability.

    Eventually all the other usual suspects will be joining the JSR's, like SUNW, ORCL, IONA, SAP. Everyone has the same voting power. Do you think by then the process will remain as "speedy"?
  • Eventually all the other usual suspects will be joining the JSR's, like SUNW, ORCL, IONA, SAP. Everyone has the same voting power. Do you think by then the process will remain as "speedy"?

    Yes, I take it as given that the other JCP expert vendors will endorse the proposal for fear of being left behind. If only one expert vendor makes a proposal, then its likely just stinky proprietary stuff. But if a proposal is already blessed by two of the biggest expert vendors, then that amounts to a supplier mandate. Then again, maybe the JCP can always find some excuse to drag things out forever.
  • Partners in crime-- I do no think this is a crime. They have to compete with other products and cannot sit around until sunw JCP process comes thru. Since the specifications are open it makes others app server vendors to implement it also. Good job IBM and BEA
  • Partners in crime-- I do no think this is a crime. They have to compete with other products and cannot sit around until sunw JCP process comes thru. Since the specifications are open it makes others app server vendors to implement it also. Good job IBM and BEA

    I think we're witnessing the introduction of second tier to the standards process. First a few reputable vendors make an open specification, and then maybe later the JCP tackles it later in some geologic time. I like standards, since they give me something to stand on. I need the traction. So any collaboration that produces useful enterprise patterns is good.
  • With these JSR's are BEA and IBM trying to set the agenda for the next version of J2EE and/or EJB? How long do you think it takes the JCP to get these JSR finalized?
  • Allow me to quote from the cnet article:

    One analyst said that the collaboration between IBM and BEA is notable for its exclusion of Sun Microsystems. Java steward Sun directs the Java standardization process and controls the Java brand, but with only single-digit market share, Sun's Java server products lag behind BEA and IBM significantly, according to Gartner Dataquest numbers.

    "You could say this announcement is the beginning of the end of Sun's leadership in the Java space, as the two market leaders are now collaborating explicitly on driving the direction of Java," said Jason Bloomberg, an analyst at research firm ZapThink.

    Now do you still think I'm kidding? Viva the Java Republic! More info at http://viva.sourceforge.net/action.html

    - Gerald

    PS: For more insight, check out the Eclipse site at http://www.eclipse.org and study the logo in the upper left corner in detail.
  • "You could say this announcement is the beginning of the end of Sun's leadership in the Java space, as the two market leaders [BEA+IBM] are now collaborating explicitly on driving the direction of Java," said Jason Bloomberg, an analyst at research firm ZapThink.

    Anything that enhances Java necessarily increases the value of Sun's Java intellectual property.
  • To what extent? I mean... this clearly has some effect on other existing JSR´s and proposes a different solution for the same probs...

    Why don´t they work on some consensus? Well, i don´t know why I ask... I know the answer already...
  • Good for Java[ Go to top ]

    I had a perspective on this news that seems to differ from that of many people.

    It seems to me that efforts that lead to real J2EE app server interoperability are GOOD for the J2EE community. Will this lead to increased market share for the two companies as well ? Sure. In my opinion, the current situation, in which a dozen (well, actually many more) app server vendors compete for share, leads to confusion among customers and slows rather than accelerates innovation in the J2EE world. As a customer, I would definitely prefer a smaller number of competitors with tools that interoperate to a large number of vendors with features deliberately designed to be incompatible with any other product. I want competition but what I see today is chaos and misleading information published by all competitors ... and that makes me uncertain about J2EE and the future of Java.

    I think that efforts like this provide real benefits to the customer and that IBM and BEA deserve respect for breaking the walls built by competition in this instance. I think in general that the J2EE world needs to mature a little bit. Bombarding the customer with change and added complexity and proprietary innovation is hurting now. I perceive a slow but steady erosion of trust in Java and J2EE. I think it's time to consolidate the platform publicly and honestly and start winning back some of the trust of the customer. Otherwise ... there won't be much to compete for after a few more years of the current hype.

    Just my view ...
  • Anything that enhances Java necessarily increases the value of Sun's Java

    > intellectual property.

     I guess you're dreamer. Nobody really cares about technology. IBM and BEA and whoever will just rebrand their offering. The power of the Java brand is just an illusion.

      - Gerald

    PS: To see what I mean check out Eclipse, Websphere, Jikes and so on.
  • Ulterior motive behind the spec[ Go to top ]

    The real reason behind the specifications:

    http://www.manageability.org/blog/stuff/ibm-bea-joint-spec

    Carlos
  • Ulterior motive behind the spec[ Go to top ]

    Do you care to elaborate why EJB leads to "stovepipe" applications? Are Portals written using EJB (SLSB and MDB) "stovepipe" applications? Is loosely-coupled architecture always the best approach? In your opinion, can BEAS and IBM push their new JSR's through JCP quickly so people can take advantage of these technologies?
  • Ulterior motive behind the spec[ Go to top ]

    Portal merely put lipstick on the pig. There's barely any integration between each EJB application you develop.

    Like I said in my piece without MDB and JCA it would be almost impossible to address the integration problems of an enterprise.

    I don't know how fast BEA and IBM can work, however they have products today, albeit running using non-standard capabilities.
  • Ulterior motive behind the spec[ Go to top ]

    I think the community on these forums are not consistent. I see many people bash the EJB spec and we need something better. Then, IBM and BEA do something, and people do not like it. SDO is only a data access layer that implements the Table Module Pattern specified in Martin Fowler's book. SDO can be used with Stateless Session Bean or MDB's and does not compete with the EJB spec at all (except for Entity Beans). JDO and Entity Bean implement a Domain Model. Now with J2EE/Java you have a choice. If you decide your application needs a rich object domain model, you can go the Entity Bean/JDO route Route, while if you need a Table Module implementation, you can use SDO. I think the J2EE spec was missing a solid Table Module implementatio to compete with ADO. Also, if you think about combining Java Server Faces with SDO, tooling can drag a JSF control ontoo a JSP that is linked to an SDO component, much like ASP/ADO. Now we can have tooling, but based on a standard solid standard. I think this is just great news. I do not see how POJO concept relates to SDO in this nature.

    Comments my own, not my employer IBM
  • Ulterior motive behind the spec[ Go to top ]

    <!-- I think the community on these forums are not consistent. I think the J2EE spec was missing a solid Table Module implementatio to compete with ADO. Also, if you think about combining Java Server Faces with SDO, tooling can drag a JSF control ontoo a JSP that is linked to an SDO component, much like ASP/ADO. Now we can have tooling, but based on a standard solid standard. I think this is just great news. I do not see how POJO concept relates to SDO in this nature. -->

    I don't know what are you talking about. What ever you can do with ASP/ADO you can do it with JSP/JDBC. If by Table Module implementation you meant some thing like ADO.NET (in memory representation of your database e.g tables,views,schemas,etc)then the right place to resolve this issue is JCP and JSRs related to JDBC API.
  • Ulterior motive behind the spec[ Go to top ]

    I was speaking from a tooling perspective. Currently, there are no standard tools for dragging a JDBC compoenent onto a JSP page to accomplish what Viusal Studio does with ASP/ADO. (There are vensor specific tools, but not standard ones). One could have a JSF compoenent linked to an SDO object that is implemented as JDBC. SDO, however, will support more than JDBC. However, SDO can also be viewed as a type of data delagate that can be wrapped in a standard way and used on a visual tooling pallete. So
  • Ulterior motive behind the spec[ Go to top ]

    Roland:

    You said:
    >>SDO is only a data access layer that implements the Table Module Pattern specified in Martin Fowler's book. <
    Assuming your statement about SDO is true, Fowler makes it clear that he decidely prefers the Domain Model except in simple applications, when you can use Table Gateways and Row Gateways.

    What you seem to be saying is that IBM and BEA are addressing a very small niche with SDO, n'est pas?
  • Ulterior motive behind the spec[ Go to top ]

    Fowler may prefer a Domain Model, but that does not mean that it is the dominent implementation in the market place. Fowler is an OO fundamentalist and OO fundamentalist prefer a domain model. If Table Module is just a small niche, then .NET would be out of business.

    SDO will not be limited to a specific type of data access. So it can also be viewed as a data delegate or business delegate as well.
  • Ulterior motive behind the spec[ Go to top ]

    Fowler may prefer a Domain Model, but that does not mean that it is the dominent implementation in the market place. Fowler is an OO fundamentalist and OO fundamentalist prefer a domain model. <

    Domain Model is not the dominant implementation? Then why all the hue and cry over entity beans? It shouldn't be that big a deal. To the contrary, entity beans ARE the Domain Model, but it doesn't work all that well because of the implementation of entity beans - and after about a billion dollars was overspent implementing EJB's, everyone found this out, at least according to Gartner Group. Hence Hibernate, et al.

    >> If Table Module is just a small niche, then .NET would be out of business. <
    Last time I checked market share, this was pretty much true.
  • Ulterior motive behind the spec[ Go to top ]

    I think there are just as many if not more plain JDBC applications out there than Entity Beans. J2EE market share does not equal domain model market share. I think certain applications need a domain model and others do not, once an architect determines this, then one can choose something like Entity Beans, JDO, or Hivernate. It is not a bad thing to have a choice between Table Module or Domain Model, having J2EE support both I feel is a positive.
  • No conspiracy here[ Go to top ]

    I don't see any conspiracy or ulterior motives here.

    IBM and BEA are the top two vendors here and their app servers have a
    number of non-standard features. A lot of these are useful for enterprise
    applications and I suppose some are driven by the needs of customers.

    But a side-affect is that these extra toppings affect portability and the
    top two are trying to increase portability between their app servers and
    any others who go by these specs. Nothing wrong here.

    I don't see this as an attempt to bypass JCP. They certainly cannot wait
    for JCP approval to implement a feature/service that many customers need
    immediately. Also, let's not forget that a lot of enhancements/additions
    to J2EE specs have come from IBM and BEA and these existed as non-standard
    features in their app servers before they became part of the J2EE standard.
    In fact, I see an advantage in having these tried and tested features being
    incorporated into the standard as opposed to something raw/untested (remember
    BMP?)

    Regards,
    Kalyan (not working for IBM or BEA)
  • Websphere 6.0[ Go to top ]

    Will Websphere 6 implement these specifications (WorkManager, Timer, SDO) ?
  • JSR 235: Service Data Objects[ Go to top ]

    JSR-235
    Service Data Objects

    http://www.jcp.org/en/jsr/detail?id=235
  • JSR 237 and JSR 236[ Go to top ]

    JSR 237 - Work Manager for Application Servers
    http://jcp.org/en/jsr/detail?id=237

    JSR 236 - Tiime for Application Servers
    http://jcp.org/en/jsr/detail?id=236
  • Oracle comments on the standardization process of SDO (IBM and BEA specify first, then hand-over to JCP for ratification), which in many ways are in line, with some of the more critical comments in this thread.

    ORACLE'S JSR-REVIEW BALLOT COMMENT:
    While voting to support the technical work in this JSR, Oracle is concerned about the manner in which it was introduced into the JCP. IBM and BEA, by publishing specifications and publicly committing to implement them as published in the very near term, are dramatically altering the JCPs normal mode of operation; instead of working with major stakeholders to develop a consensus specification, they are imposing on the community their preferred approach and trying with their combined market shares to assure its adoption.