TMC Introduces SOA Blueprints; Public Review Open

Discussions

News: TMC Introduces SOA Blueprints; Public Review Open

  1. The Middleware Company is introducing SOA Blueprints, an effort done in conjunction with BEA Systems to create best practices for developing applications using service-oriented architectures. SOA Blueprints contains an open specification, third-party expert involvement, and upcoming implementations using multiple technologies.

    SOA Blueprints models a fictitious corporation selling a generic service, GeneriCo, which has multiple real-world applications described in an architecturally neutral way, permitting implementations to come from the middleware community using a variety of technologies including Web Services, J2EE and .NET. GeneriCo includes a unified service-oriented security provisioning system, a multi-function employee portal and an HR application. These utilize services that depend upon databases and legacy systems.

    The SOA Blueprints specification is now open for public review at www.MiddlewareRESEARCH.com/soa-blueprints. The community can get involved by posting their feedback here or contacting The Middleware Company off of the SOA Blueprints Web site. SOA Blueprints is designed to be expandable and to grow over time, so the applications currently defined are not static. Third party experts from the community, BEA, Collaxa, CapeClear and CGEY have been involved in pre-release feedback.

    The first implementation will be based upon BEA WebLogic Platform 8.1 with early releases on display at BEA eWorld 2004 next week. TMC is also interested in starting a community-based open source J2EE implementation. Individuals interested in participating in this effort, should get in touch with Steve Wilkes, steve@middleware-company.com.

    TMC and BEA also plan to engage dozens of SOA technology firms. SOA software leaders will be invited to participate in the expert review, endorse this effort and to explore areas of the specification that can be implemented using their technology. The SOA Blueprints Web site will promote and document each of these implementations done by various vendors. The use of a specification to define GeneriCo allows organizations to compare and contrast multiple implementations using different products.
    "This effort fortifies how SOA can be applied to real world problems," said Salil Deshpande, CEO at The Middleware Company. "The SOA Blueprints specification captures realistic enterprise scenarios allowing the middleware industry to create, compare, and contrast multiple implementations using diverse technologies. SOAs are increasingly becoming the de-facto standard for enterprise systems, but until now, there has been little documentation on their best practices."
    See the TMC Press Release

    Visit SOA Blueprints: www.MiddlewareRESEARCH.com/soa-blueprints.

    Threaded Messages (36)

  2. If this thing is for public review, why do you require registration! You should allow anyone to download it without giving up personal information.

    If people comments on it, you will get their e-mail address anyway!

    I'm just bored to have to register to so many site just to download stuff that someone claim is for anyone to see.
  3. WebServices != SOA
    Here

    Why isn't Jini an option?
  4. As I understand DAO, stateless beans, servlets are SOA too.
    Is SOA about some special service, protocol and XML or
    about any stateless service ?
  5. it's hard for me to call your stateless session bean from .Net...
  6. it's hard for me to call your stateless session bean from .Net...
    Use some adapter like web service to call service like stateless session bean.
  7. What is SOA?[ Go to top ]

    it's hard for me to call your stateless session bean from .Net...
    Interop is just part of SOA.

    This article takes a stab at defining SOA. http://www.adtmag.com/article.asp?id=7472

    It says in part, SOA is an application architecture that exposes services to clients. The pieces are said to be "loosely coupled".

    There has been some discussion as to the finer points. Some have said
     - Boundaries are explicit. This means remoteness is not transparent
     - interaction is message-oriented and defined by Schemas. This means no RMI !!
     - services are autonomous, or independent.
     - exchanges are negotiated - like, "parlez vois francais? No? then we speak english."

    For example see a thread on the sister site
    http://www.theserverside.net/news/thread.tss?thread_id=26018

    RMI is still useful in tightly-coupled designs, where one can assume (and count on) Java everywhere. But as a technical underpinning for SOA, it doesn't satsify.
  8. Something Mark Hapner alluded to in his presentation at The Serverside Symposium was that there really is no standard definition for SOA. There are definitions floating around but unlike CORBA there is no globally accepted way of telling whether an architecture "satisfies SOA" or not. Hopefully this work and others will motivate such work.
  9. WebServices != SOAHereWhy isn't Jini an option?
    I think this is an interesting point. I don't agree that going the Jini route is a terribly viable way to go, because it does not address the cross platform/cross language issues. I do however agree that WebServices != SOA.

    SOA is a shift in thinking, where you architect your system to integrate better with legacy peices, as well as more flexible in adapting to future changes. I like basing SOA on XML and (to a lesser extent) protocols because it allows you to better interact with other (non-java) system. Even if you are only using Java now, you may want to add in non-java peices in the future, or you may need to interact with future versions of Java that break compatibility. It's unlikely that future versions of TCP/IP, HTTP, XML will not be compatible with the current versions.

    Also, with projects from Xerces to XMLBeans, almost every platform has tools for dealing with XML, and it is easy to build XML documents that can change over time, while clients using those docuements can easily be built to roll with those changes.

    That being said, it is important to decide how much flexibility you want to add to your system as well as where that flexibility should be. I think coming up with Best Practices and Patterns around making these decisions are important, and this blueprint should help lead that effort.

        Will Pugh
        Principal Technologist
        BEA Systems
  10. SOA is a shift in thinking, where you architect your system to integrate better with legacy peices, as well as more flexible in adapting to future changes. I like basing SOA on XML and (to a lesser extent) protocols because it allows you to better interact with other (non-java) system. Even if you are only using Java now, you may want to add in non-java peices in the future, or you may need to interact with future versions of Java that break compatibility. It's unlikely that future versions of TCP/IP, HTTP, XML will not be compatible with the current versions.
    I am not expert and I do not know SOA definition, but if it is about protocols then it is not very usefull thing, any "bridge" can solve this problem and I see no problems to generate adapters. I do not think marshaling or RPC internals is some kind of architecture, looks like SOA is used just as a new name for RPC over HTTP.
    I have tried Google and it found this SOA definition
    http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html
    "Now we are able to define a Service Oriented Architecture (SOA). SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners."
    So amost evrything is SOA by this definition :), it must be possible to find more definitions, but I think most will be more abstract than XML or HTTP.
  11. I am not expert and I do not know SOA definition, but if it is about protocols then it is not very usefull thing, any "bridge" can solve this problem and I see no problems to generate adapters. I do not think marshaling or RPC internals is some kind of architecture, looks like SOA is used just as a new name for RPC over HTTP. I have tried Google and it found this SOA definitionhttp://webservices.xml.com/pub/a/ws/2003/09/30/soa.html"Now we are able to define a Service Oriented Architecture (SOA). SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners."So amost evrything is SOA by this definition :), it must be possible to find more definitions, but I think most will be more abstract than XML or HTTP.
    Perhaps I did not explain myself terribly well. SOA is more abstract than XML+HTTP. The point Calum made about SOA != Web Service I completely agree with. My points above are based on pointing out why Web Service/XML/HTTP/etc. are popular to build SOAs, rather than language or platform dependant technologies. I mean sure you can build bridges as future technologies are created or you can build bridges to legacy systems, but it is a lot more work than to use some of the XML tools that are already widely available on many system.

    SOA is the more abstract notion of building systems that are more easily integrated with legacy system and more flexible to potential changes in the future. One of the key concepts that comes out of this is loose-coupling, and document-centric services. Many of the technologies and ideas this is based on have been aroung for a while.

    I think the "high order bit" in SOA is being able to build systems that are able to change with time more easily, and where changes to a service to not necassarily force changes to a client. Simple abstraction helps you do some of that by making the implementation of a service independant of the interface. SOA is pushing that one step further to say that clients can survive certain changes to the service itself.

    For an example, imagine the GetProduct service in the Spec. Let's say you have ten clients using that service. Then you want to create a new application that needs to know what the next higher quality product in a product line is. If you architect the service such as the way we did it in the blueprint, you can add an additional field to the XML document returned by GetProduct to include the ID of the next product up the product line. Since, it is XML it is much easier for the existing clients to ignore additional fields than if we were depending on Java Serialization.

    That being said, I think you could still adhere to SOA priciples and implement it usign bridges and custom serialization to better deal with document versions, etc. I just think it would be harder (and potentially more fragile).
  12. If you architect the service such as the way we did it in the blueprint, you can add an additional field to the XML document returned by GetProduct to include the ID of the next product up the product line. Since, it is XML it is much easier for the existing clients to ignore additional fields than if we were depending on Java Serialization.That being said, I think you could still adhere to SOA priciples and implement it usign bridges and custom serialization to better deal with document versions, etc. I just think it would be harder (and potentially more fragile).
    It looks like "dynamic" vs "static" or "compiled" vs "scripting",
    both are good and usefull. I think about SOA as about "stateless service", it is very simple architecture and lets to make programming more declaratyve, AOP + SOA must be a good combination. It is possible to use some interface definition language or JAVA to declare service and AOP to implement aspects declared by service.

    interface Products {

      @Query "SELECT * FROM PRODUCT_TABLE WHERE name like $1"
      @Authorization AUTHENTICATED_USER
      @Check "$1 != null"
      @Transactional
      @Log "$currentUser recieved products by $1"
     
      Collection<Product> findProducts(String param);


    }

    XML, RMI or just a method call in the same process, anything can be used for implementation, infrastucture stuff is not domain specific and can be generated or replaced by aspect implementation, It can run in container or it can be self contained. Service declaration is reusable by any implementation strategy (It can be manual too). So I think architecture is more than implementation strategy and this architecture (SOA) is very friendly for aspects like RPC,Security,Transactions,Validation,Data Access and the value of this architecture comes form simplicity.
  13. I like what you're saying here. In general, I feel that if one wants to build an SOA platform that is Java/C++/C/etc. specific then we shouldn't say they are "not satisfying SOA". IMHO, the primary intention of the "loose-coupling" in SOA is in the traditional OO sense where dependencies of the services are reduced to a single direction towards the ESB (this has been common in the MOM/EAI space). Certain platforms may be language independent which is fine but I would question eliminating those that aren't from the definition.
  14. I think language independace is not the part of architecture, but it can help to implement programming language agnostic systems. This idea is very old, neutral definition language like WSDL,IDL,ODL and limitation for types like "automation types". It is language and platform neutral by design, but we use adpters and bridges in practice anyway (CORBA -> DCOM, JAVA -> .NET) probably this problem is not technical.
  15. I don't agree that going the Jini route is a terribly viable way to go, because it does not address the cross platform/cross language issues. I do however agree that WebServices != SOA. SOA is a shift in thinking, where you architect your system to integrate better with legacy peices, as well as more flexible in adapting to future changes.
    This is a pretty amazing comment. I think it really indicates how much of Jini and Java some people are really missing. Java and Jini are in fact targeted at creating the ability to work across mulitple OS platforms. In order to move your legacy applications into a more distributed system, you should do whatever minimal changes it takes to provide the needed paths into and/or out-of the legacy apps. What you have to focus on is protocol neutralization.

    What XML does is propigate protocol knowledge everywhere. Everyone has to learn about the document schema, and create the coding/decoding logic to turn documents into native data, or turn native data into documents. There has been a whole collection of work done to make this happen, and it has been volumonous and repetative.

    If you instead, put protocol neutralizers at these legacy applications, and provided RMI based semantics into and out of these applications, then you'd have no data conversion. With Java's code downloading, you'd have automatic inter application compatibility. One of the most important things about using JINI for this kind of integration is that with version 2.0, the Jini Extensible Remote Invocation (JERI) API provides a plugable stack that will let you talk any protocol you want, in and out of Java applications. And, because its is a documented API, each protocol only has to be done once, and can then be made available for others to use.

    If you hang around the Jini mailing lists for a while, you'll see that there are a completly different set of issues that are discussed from what seems important in the web services world. And, in general, the issues discussed are much broader in scope because people are doing some very distributed, high scale integration stuff, that requires some fairly sophisticated thinking and Jini often presents a fairly straightforward solution because there is not the extra layer of translation of XML involved.
  16. This is a pretty amazing comment. I think it really indicates how much of Jini and Java some people are really missing. Java and Jini are in fact targeted at creating the ability to work across mulitple OS platforms.
    Hmmm. This is interesting. I thought Jini was just a Java thing? Are you saying it also does interop well with .net and other non-Java languages, or just that you can run Java on other platforms?
    In order to move your legacy applications into a more distributed system, you should do whatever minimal changes it takes to provide the needed paths into and/or out-of the legacy apps.
    I agree. My point is that often times doing the minimum work necassary to build services on a legacy system may not be to build a Java program to act as an intermediary. Sometimes the most practical solution may be to use some of the many XML and SOAP tools out there to create a service on top of your legacy system. This may be Java, this may be something else.
    What you have to focus on is protocol neutralization. What XML does is propigate protocol knowledge everywhere. Everyone has to learn about the document schema, and create the coding/decoding logic to turn documents into native data, or turn native data into documents.
    I don't think this is entirely accurate. There are many ways from XMLBeans to JSR 181 where documents can simply be treated as Java Objects and Services can simply be treated as Java methods.

    As I alluded to in an earlier post, I feel the "high-order bit" is loose-coupling, document based services (and all the patterns + best practices the come from this). Maybe you can do this using Jini if you want to assume all your systems will run Java.
  17. This is a pretty amazing comment. I think it really indicates how much of Jini and Java some people are really missing. Java and Jini are in fact targeted at creating the ability to work across mulitple OS platforms.
    Hmmm. This is interesting. I thought Jini was just a Java thing? Are you saying it also does interop well with .net and other non-Java languages, or just that you can run Java on other platforms?
    I am saying that Jini utilizes features of the Java platform RMI and code downloading, that specifically deal with interop in a way that makes it possible for a Java application to interact with any other type of application. The fact that other languages don't have downloaded code is what makes it so meaningful to them to use XML. They need a neutralization strategy that is unified for them. Jini applications can utilize code downloading to allow them to seemlessly integrate multiple applications which provide similar programatic structure; e.g. multiple vendors accounting software, or multiple vendors field measurement equipment.
    In order to move your legacy applications into a more distributed system, you should do whatever minimal changes it takes to provide the needed paths into and/or out-of the legacy apps.
    I agree. My point is that often times doing the minimum work necassary to build services on a legacy system may not be to build a Java program to act as an intermediary. Sometimes the most practical solution may be to use some of the many XML and SOAP tools out there to create a service on top of your legacy system. This may be Java, this may be something else.
    This is only attractive if you think that you must have XML everywhere, instead of buying into the power of the Java platform and more specifically utilizing code downloading to defer binding till runtime, yet make it absolute.
    What you have to focus on is protocol neutralization. What XML does is propagate protocol knowledge everywhere. Everyone has to learn about the document schema, and create the coding/decoding logic to turn documents into native data, or turn native data into documents.
    I don't think this is entirely accurate. There are many ways from XMLBeans to JSR 181 where documents can simply be treated as Java Objects and Services can simply be treated as Java methods.As I alluded to in an earlier post, I feel the "high-order bit" is loose-coupling, document based services (and all the patterns + best practices the come from this).
    Why would you want to spend time, over and over converting an XML document just to get simple data out of it. The structure of the XML document, and the specification of any particular schema is no different than what was done with the Java language specification. It provides very definite interpretations of data values and their representation. This is different than what C, C++ and just about any other language has ever done. Thus, with Java, you really have no advantage in using XML to standardize the representation of your data. I understand that some people will argue that the infinite extensibility of the document for other users makes it way more flexible than hard coded method signatures in a Java interface. I guess that my only response to that is that if you have this problem repeatedly, you still don't understand your application domain, and it is probably fragile and subject to frequent troubles with malformed documents.

    What I have see happen is that the document grows like a weed, but some things start getting hacked off of it, and eventually something important is being removed as an optimization somewhere, and finding the offending code is difficult. With method signatures, this happens at build time, and you can move on to solving real problems.
    Maybe you can do this using Jini if you want to assume all your systems will run Java.
    I guess I am still not sure why people are against this. I am not sure what specific feature any other language in wide use today provides that Java can not provide if needed. They all run on the same hardware executing the same instructions. So, in the end, any advantage is merely a cosmetic issue. Some might be substantial to solve because of language restrictions.

    Software design is about creating solutions. If you are left without an API that speaks the language of solutions in your problem domain, then you might need to do some more work. But, throwing out the language because it doesn't have a solution for you today is what has kept the software world churning out repetative software for new languages and platforms instead of solving real problems.

    For me, Java finally draws the line in the sand in such a way that I can feel comfortable adopting it as my language of choice for the age of "The network is the computer". If you are still in the age of "The network is attached to my computer", then you may still need other languages that let you into the internals of your computer so that you can try and make it work as a distributed system.

    SOA is about recognizing that the network is the computer and that what you need to be able to do is have multiple computers talk to each other in a very efficient and effective programming paradigm. XML is not "efficient" for use on same language systems. It is effective for some types of applications. However, it does not scale well with rapidly changing but tightly dependent systems, because it adds a level of unknown into the protocol level that causes a ton of extra programming work to occur (either mechanically, or automated over time) to create the wealth of actual code needed to convert XML formatted data to the native programming values needed by the application.

    I could keep going, but I'd guess if you don't understand the magnitude of these issues yet, that I'm not going to convince you here.
  18. Java and Jini are in fact targeted at creating the ability to work across mulitple OS platforms.
    Heterogeneity also regards processing language. Jini misses this.
  19. I think this is an interesting point. I don't agree that going the Jini route is a terribly viable way to go, because it does not address the cross platform/cross language issues. I do however agree that WebServices != SOA. SOA is a shift in thinking, where you architect your system to integrate better with legacy peices, as well as more flexible in adapting to future changes. I like basing SOA on XML and (to a lesser extent) protocols because it allows you to better interact with other (non-java) system.
    There are a couple of reasons for at least having a glance at Jini, because Jini (and of course CORBA) have been doing Srvice related processing and handling SOA issues for years- such as distributed transactions, resource leasing, location transparency,etc.

    Jini requires some Java on the network, but the proxies that Jini dynamically loads into the client can either be remote proxies (RMI, JERI, etc.) or could have all the code required to contact a system over any other protocol, such as SOAP/HTTP, XMLRPC, CORBA, Sockets, etc. Even the full process can be downloaded into the client (i.e. local proxy). All that is required is that a Java system will maintain a proxy for the service in the Jini federation (even if that service is somewhere else or in another language, or in a resource constrained device - see the Jini surrogate architecture. The surrogate concept can be applied to any system, not just a device. By using this concept, a Web Service implemented in C#, or a bespoke system implemented with a specific C network protocol, can be connected to through Jini; the Java code required to interface with this system is built and loaded by a service surrogate and joined into the federation. When the client downloads the service proxy and invokes it, instead of talking to the surrogate, all the code to talk to the real service (WS, C network protocol) is now already loaded into the client and when you invoke it, operations are made on the real application, not the surrogate. The surrogate just ensures that the service remains registered etc.

    The issue that I have with XML, is that it is actually still a protocol, and we use standardised parsers and strings to remove binary and platform inconsistencies.

    I think to simply apply SOA to just legacy integration (application integration) is not all there is to the story; SOA is a great architecture for grids and enabling location transparency (application distribution)
  20. Web Services and SOA[ Go to top ]

    WebServices != SOAHereWhy isn't Jini an option?
    I recommend you to RTFD (read the finished document :). Quote:
    While Web services and SOA are usually thought to be synonymous, they are not. It should be made clear that Web services are an important tool and one implementation method for SOA, but there are other patterns that may be more appropriate for any given use-case.
    Piece,

    //ras
  21. If any tools avialble for this
  22. I've got some questions about the way the term "component" is used
    in the SOA Blueprint, especially looking at section 3.3.2.

    Where I'm coming from, a component would be something assembled by
    a couple of arbitrary (object-oriented ;) ) objects. I guess this is
    not the way the term "component" is used here ? My question doesn't
    focus on whether there's something obejct-oriented about a component,
    but rather on which abstraction layer in the application design it
    would be fit ?

    Further, I'd like to ask whether section 3.3.2 means that a component
    has always a more-or-less direct representation in the database. In
    other words, is this what the term "entity" used in the first sentence
    in section 3.3.2 wants to express ?

    Thanks,
    Matthias
  23. Thanks for reviewing the specification.

    The use of the word component is more a description than a reference to other uses of the word in software. What we wanted to convey here was that there are three major levels of granularity in services, and to do that we needed to give them names.

    A "component service" is the smallest granularity of service and cannot be decomposed further to other services (but it will obviously contain code to do something useful). It does not have to access a database, that is merely an example of something it could do.

    Hope this helps clarify this point.

    Steve Wilkes
    The Middleware Company
  24. I'm fine with having components defined as fine-granular "things", used by
    Business Services and Workflow Services (Figure 3).

    Now, I'd like to further qualify the term "Services" in "Component Services",
    as being used in Figure 3 and section 3.2.2.
     
    Simply put, I'm wondering whether the spec allows for a component service to be
    a "SOA service" or not. In other words, looking at Figure 3, I'm asking where to
    draw the line to have or have not a SOA architecture (just by looking at Figure
    3).

    Interpreting the text I've read so far, I'd say the spec says that a component
    service doesn't make a SOA architecture on its own. (For example p.9, last
    sentence above Figure 3.)

    This leads me to two questions:

    1. How does a "real" "valid" SOA service compare exacly to a component service ?

    2. Looking at Figure 3: would a Workflow Service really cover/hide all the
    Business Services for an application (in order to speak of an application which
    uses/relies on a SOA) ?

    I'd like to show Figure 3 to somebody else and point to the level where one
    could speak of having a SOA architecture. I don't want somebody to point to the
    component services level and speak of a SOA. As far as my understanding goes,
    one should be able to speak of a SOA form the business services level onwards.

    "The use of the word component is more a description than a reference to other
    uses of the word in software. What we wanted to convey here was that there are
    three major levels of granularity in services, and to do that we needed to give
    them names."

    I like the notion of different "levels of granularity in services", and I like
    the term "component service". But I'd like to clarify/specify that a component
    service on its own doesn't make a SOA service and/or architecture: Say, I expose
    my component service by a WSDL description -- am I a SOA-compliant application
    or not ? :)

    While all of this might appear to be crystal clear from one viewpoint, I'd like
    the spec to leave no room for interpretation here.

    Thanks,
    Matthias
  25. Granularity Process[ Go to top ]

    In addition to Matthias' questions, which I share, I have some questions around the granularity. I really like that you call out the different levels of granuality between services and components. That alone separates you from other vendors that are so-called experts in this space. What would be really beneficial is to provide some sort of process/criteria for determining what is a service and what is a component. What I've experienced is too many people think components are services and then you get an explosion of "services" and all sorts of performance and scalability problems are run into. I don't want anyone to re-live the growing pains of CORBA and RMI in this respect.
  26. I downloaded and read this expecting to learn things about best practice SOA. Foolish me.

    I downloaded and read this expecting to learn how all the parts of an SOA interacted, much like the j2ee blueprints showed off how the platform worked.
    Foolish me.

    It seems that this document is designed to show off how the Weblogic Platform fulfills these requirements. Umm, that's great, but don't go calling this a blueprint or a best practices document. Perhaps call this a "Marketing Requirements Grist" document. One where we can once again go through the petty pointscoring of a petshop! hooray! The only winner from such an exercise is The Middleware Group.

    Where's the Service Management (Oh, bea doesn't sell one?). Identity based services? (Oh, bea doesn't sell that either?).

    At the moment, this blueprint document is as realistic as section 2.5 of the document. What kind of Architecture document puts out of scope the very things that architecture is supposed to deal with?! Madness.

    Actually, are there any licencing costs for implementing this? I'm curious, being all for transparency as I am.

    regards,
    dk-
  27. Where's the best practice?[ Go to top ]

    Denis,

    Thanks for your comments. One of the major things we are trying to achieve with this exercise is bound within the issues you are raising. There are currently no best-practices for SOA. There needs to be something understandable and attainable that leads to these.

    This specification is not a finished piece. It is a work in progress. There are things specifically out of scope for this version of the specification because we needed to scope it realistically. We cannot define every aspect of SOA in one document.

    This specification and associated implementations will grow over time. As part of this exercise we are trying to build an open-source initiative to provide a reference implementation of the specification (ie. not bound to any vendor and definitely no license costs).

    Please email more comments and recommendations to the soa-blueprints-feedback email as suggested on the site so they can be incorporated into the next version.

    Thanks and regards,

    Steve Wilkes
    The Middleware Company
  28. Even if SOA /= WS, I assume this can be implemented with the current WS stack.

    You use the notions of TOPIC or QUEUE or ... to describe processes interacting. However, there is no such thing defined in the current WS-* specs.

    So what is the idea behind these blueprints:...
    1) to define SOA at a very abstract level, the TOPIC notion being loosely modeled on the JMS model, and let implementors implement the notion with a combination of WS-ReliableMessaging, WS-Adressing WS-Eventing or whatever is necessary, but in a "proprietary" way

    or
    2) to define SOA blueprints where I can mix and match participants and interoperate, e.g. BEA for HR and Collaxa for Security. In this case TOPIC or QUEUE must be clearly defined.

    Or perhaps I missed something ...
  29. This is a good point. Would you suggest possibly replacing "TOPIC" with "async pub/sub mechanism" and "QUEUE" with "async point-to-point mechanism"?
  30. This is a good point. Would you suggest possibly replacing "TOPIC" with "async pub/sub mechanism" and "QUEUE" with "async point-to-point mechanism"?
    This would be a nice syntactic move, but it does not really address my point.
    The story of WS and SOA and ESB ... is somehow confused between the transport level (http, JMS) and the "session" level (SOAP, WS-*).
    Many people like to make-believe that because you run SOAP on JMS, it becomes asynchonous and all the nicities of loose coupling.
    Not so of course. The value of JMS is to bring some reliability (one and only one). Unfortunately you loose interoperability which is the main value of WS. So contrarily to what ESB companies marketing arm claim, this is a road to nowhere in the B2B space, and only limited to a small scale A2A.
    What we need is the semantic equivalent of a MOM at the WS-* level. Probably with something like WS-TOPIC and WS-QUEUE since these concepts have been proven valuable.

    Back to the topic of the thread, this is why the usage of the words "topic" and "queue" must be very careful.
    My preferred solution would be that the blueprint document defines (in an annex) a realistic and interoperable way to implement WS-TOPIC and WS-QUEUE with the WS-* toolkit, since it seems that these concepts are necessary to explain the blueprints..
    One cannot expect that the average "WS architect" is able to make its way thru the WS-* maze of overlapping and competitive specs; one day, ws-i.org will be able to write someting about that, but we are not there yet.
    It is of little interest to have the BEA implementation of the blueprint and then the IBM one and the MS one. Back to proprietary. I assume nobody wants to implements its SOA architecture with one vendor only.
    The only valuable implementation of these blueprints are the hybrid one. Valuable in the sense that we will learn something collectively from this endeavour, as opposed to a tentative from the vendor side to convince skeptical users that SOA is ready for prime time..
  31. I'm sorry but I've got to shoot this paper down.

    You can't claim to know how to put together a set of blueprints for SOA if you don't even know what SOA means!

    SOA = Service Oriented Architecture not Same Old Architecture which incidentally this paper seems to hint at.

    Key word is Service, so first define service before you proceed, while you are at it explain why its different from Component and Object. Then you've made a first step in understanding. Without knowing what you're talking about, this looks like a Cargo cult definition of what goes on in IT, nothing more, nothing less.
  32. Hi Carlos,
          
          I agree with many of your comments however I think this approach makes sense. Typically one will come up with use cases prior to designing a system and that's analogous to I see occurring here. I think unfortunately right now that many people are out there presenting definitions of service, etc. and this is leaving us with a plethora of definitions for a single term.

          I wholeheartedly agree (and have also been posting) that SOA is not equivalent to previous architectures although it certainly shares some concepts. I also am all for open specifications for SOA, ESB, etc. I believe Mark Hapner indicated this as well at the symposium. IMHO there needs to be a body with representatives from the main players (including Microsoft) to create such specifications and definitions.

    Thanks,
    John Harby
  33. Hi (Dave or John?),

    Did you just implicitly agree that there are no decent definitions of SOA?

    You seem to imply that gathering a set of use cases of "SOA" helps you build a "SOA" based application. Well unfortunately, this may work for gathering requirements, however doesn't work for fundamental things. Like I said, Cargo cult science, just because you immitate the behavior doesn't mean it'll work, you have to understand its underpinnings. That's precisely why I feel this paper is just a smorgasborg of current practices and has nothing to do with SOA (is you can find a decent definition of that!).

    Carlos
  34. Hi (Dave or John?),
    Sorry, my ISP was out and I was using a friend's machine.
    Did you just implicitly agree that there are no decent definitions of SOA?
    I don't know if I'd agree that there are no "decent" definitions but I would agree that there is no common definition or standard.
    You seem to imply that gathering a set of use cases of "SOA" helps you build a "SOA" based application. Well unfortunately, this may work for gathering requirements, however doesn't work for fundamental things. Like I said, Cargo cult science, just because you immitate the behavior doesn't mean it'll work, you have to understand its underpinnings. That's precisely why I feel this paper is just a smorgasborg of current practices and has nothing to do with SOA (is you can find a decent definition of that!).Carlos
    I believe that gathering a set of use cases does contribute to a specification. Do you propose creating systems and architectures out of thin air with no possible applications then hoping someone can apply them?
  35. Let me get this straight, you are gathering use cases from projects that have proclaimed themselves as conforming to SOA?

    In otherwords, your methodology seems to be, find all projects that use the term SOA, collect their patterns and then proclaim them as blue prints for SOA. In the meantime, never even defining what SOA means. Then you proclaim that the methodology to be perfectly sound?

    Sounds to me you're just documenting Same Old Architectures.

    I don't propose creating systems out of thin air, I propose using unambiguous definitions when discussing technical architectures. Everyone can agree on "pipes and filters" or "client server", but "service oriented"? So long as vendors continue to sit on the fence as to its actual definition, consumers will continue to be sold snake oil.
  36. Well, you can have your view and I'll have mine. I believe this effort will serve to unify vendors and drive towards a common baseline SOA specification. Time will tell who is correct.
  37. I think key point here should be the term 'business', i.e. business service. I would define 'SOA service' as a Business Domain level Service. Business domain is a specific business area of interest (subject matter) from the point of view of a business, like ePayments for example. Business Domain Service (SOA Service) can be consumed via different channels (organizational units, networks, media etc.) and is always accompanied with Service Contract which provides means to define, document and implement consistent standards for
    -development (design approach, reuse, functional decomposition, transport)
    -content (business payload, performance/costing, transport-specific)
    -implementation (performance levels, availability, security)

    Next level of services are the services inside the business domain and I call these services Business Process Services (Workflows, Business Process Components). These can be multi-level services, i.e. each business process can have other business processes as it's activities.

    Next layer of services is optional and these are called Business Services (Business Component Services). These are services exposed from Business Objects (business entities, domain object model). This is optional because not every business software system will be implemented using domain driven design.

    Lowest level of services are Utility Services (utility component services, component services) which are reused by Business Process Services and Business Component Services layers.

    Service always implies that a component is remotely accessible.