 | |
Guests: Inderjeet Singh, Sean Brydon, and Sameer Tyagi MDR-EdO: Welcome to today's Java Live chat on Java BluePrints for Service-Oriented Architecture. As many of you know, the very popular Java Blueprints program provides best practices, guidance, and sample applications for developing enterprise Java applications and web services. Recently a number of Java BluePrints-related projects have been established on java.net. One of these is the Java BluePrints Solutions Catalog which presents (among other things) best practices, guidance, and sample applications for developing a Service-Oriented Architecture (SOA) with web services. Today's guests are two key members of the Java BluePrints team, Inderjeet Singh and Sean Brydon, and Enterprise Java architect, Sameer Tyagi. They're here to answer your questions about SOA and the Java BluePrints for SOA. So let's begin. Who has the first question? rpark: So I'm assuming the Service should, generally speaking, always be a wrapper around the "real" business logic? Is the best practice to use a SOAP XML format? Sameer Tyagi: A service exposes business logic and has certain characteristics and system level requirements. XML is the format for web services. Sam Uri: What's the distinction between web services and SOA? Is an SOA simply some related collection of web services? If I use web services as part of an application, am I using a service-oriented architecture? Inderjeet Singh: Web services is a set of XML-based technologies (SOAP, UDDI, WSDL) that are the means by which interoperable application-to-application communication is carried out on the World Wide Web through a set of standard programmatic interfaces. Web services is a set of implementation technologies, whereas SOA is an architectural style or strategy. SOA uses web services. alias: What do you think are the most common pitfalls people face when approaching an SOA? Sean Brydon: One common pitfall when creating a service is to make the service too fine-grained, with a chatty interface. Services should be more coarse grained. Another pitfall in J2EE is to just take an existing Remote EJB or Session Facade and expose it as a web service. Char: A part from the soap messages themselves are going to change due to the new set of WS-* protocols. Will some of the protocols affect how messages are delivered within a message server? Inderjeet Singh: As the WS-* protocols continue to evolve, better mechanisms will arise that add additional quality of service features such as reliability. Steve Pawloski: OK. So what is SOA? and what is the relationship between web services and SOA? Sameer Tyagi: SOA is an architectural style, a philosophy and paradigm for building distributed applications. Web Services is an implementation of SOA with a particular technology. Also while SOA is a new term, the notion of services is not. Service oriented design is really a perspective on how developers understand and build out application functionality. Guest: Could you give an example of too-fine-grained versus coarse grained? Inderjeet Singh: Whether a service method is fine-grained or coarse-grained generally depends on the application requirements. However, an example of a coarse-grained method could be a single method to accept a purchase order for fulfillment, whereas its fine-grained counterpart will be multiple methods that accept different sections of the purchase order. DKroot: What is particularly wrong with exposing a Session Facade as a web service *if* its interface is coarse-grained? Sean Brydon: Here are a couple of issues with just taking a remote EJB that was designed to be accessed with RMI-IIOP and then implementing the service interface to expose it as a web service. One problem could be that the EJB was designed with IIOP capabilities in mind and those capabilities are not matched by web services. For example, if your remote EJB facade has transactional attributes, this won't work for a web service. IIOP supports distributed transactions but web services don't do that today. Another could be that an existing EJB facade may expose types that are supported by Java & RMI-IIOP but not by web services. For example, common types such as Collections in Java are not supported as interoperable web services. Stuart: What patterns emerge in the BluePrints relative to the service abstraction layer? Inderjeet Singh: By "Service abstraction layer," I assume you mean the layer that handles all the interactions with the clients of the services. In Chapter 3 of our book, Designing Web Services with the J2EE 1.4 Technologies, we present some strategies for designing the service interaction layer. rpark: Is there a best practice for handling login/credentials for SOA and/or WS? Sameer Tyagi: There are a variety of ways to do this at the message layer or transport layer. With web services, at the message layer you can use tokens from WS-Security in the headers (see specs), or in the transport layer with mechanisms like HTTP Basic, Certificates, etc. Scott: How can someone contribute to the BluePrints catalog of sample applications on your java.net project? Sean Brydon: Our first step will be to start a very interactive feedback approach. We will soon set up a way to discuss the topics in the catalog and get community feedback from the early stages. We are looking into other ways to get contributions also. Stay tuned at the cpcatalog project on java.net. bijal: Using SLSB's local interface functionality, we use fine grained service methods for intra-application usage, and remote interface functionality for exposing coarse grained business methods. Any comments with that approach? Sean Brydon: Generally that sounds fine. Local EJBs are more common and can be fine grained. Remote EJBs should be used more sparingly, only when you really need remote access over IIOP. Web services endpoints would be even less common and more coarse grained. weiqigao: What are some of the basic tenets of the SOA architectural style? How does it differ from other architectural styles before it? Sameer Tyagi: SOA is a design style for creating shared, reusable, distributed services. (By "other architectural styles," I think you really mean technologies). Theoretically one could argue that it is possible to build out SOAs with Jini, CORBA and other technologies. The key point is that all of them are "implementation" technologies. What web services and XML in particular bring to the table (among other things) is the ability to build standards driven, coarse grained, loosely coupled, self-describing services, interoperable services. Developers can abstract and expose the functionality of applications through interfaces that are independent of underlying service implementations. That is, there is an inherent level of independence between the service implementation and the interface used by clients, such as separation of "what" from "how"). Al: How many SOA architected applications do you guys have already available? Inderjeet Singh: The Java Adventure Builder Reference application illustrates a service-oriented architecture in action. This application is now available on java.net. In the application, the consumer website interacts with the order processing center through web services. The order fulfillment center interacts with various partners and suppliers through web services. Guest: I would like to ask you to further explain why it is not a good idea to expose my session EJB remote interface as a web service directly? Inderjeet Singh: Generally, web service interfaces should be a at a higher level of granularity than enterprise bean interfaces. However, some session facades may be appropriate to be converted to web service interfaces. alias: How long before the inevitable "Patterns for SOA" book appears? ;-) Sean Brydon: I hope there will be lots of books on SOA patterns. For starters, you can check out the latest BluePrints book, Designing Web Services with the J2EE 1.4 Platform. Chapter 8, on architecture, has some interesting topics though it does not address pattern explicitly. Also, the latest Core J2EE Patterns book is still a central part of developing a SOA application with patterns. So you don't always need a new book. bijal: Can multiple services share the same domain model or should each service "own" a domain? Inderjeet Singh: In some cases, it is natural to have multiple services that share the same domain model. For example, in the adventure builder application, the order processing center exposes two web services: one for accepting customer orders for fulfillment, and the other for checking the status of an existing order. bijal: Should a presentation layer interact directly with the service layer or with some lower layer? Inderjeet Singh: Both are appropriate depending on the level of coupling you want. If the presentation layer is a part of the same application that contains business logic, it is natural to directly access the business logic layer. If the presentation layer is using content from various internal and external sources, it is appropriate to access those sources through web services. rpark: Specifically, I'm interested in "idempotent endpoints.". Sean Brydon: Can you be more specific? This is addressed in the Solutions Catalog (Early Access) in the idempotent entry and also online at the Designing Web Services with the J2EE 1.4 Platform page. rpark: Sorry... part 1 of the question got lost. So... specifically related to idempotent endpoints, can you give an example of how one might correlate messages? Meaning, can you give a specific example that would demonstrate the correlation ( Sameer Tyagi: Also, you may find this discussion helpful. Sean Brydon: How to pass a correlation ID is also discussed in the BluePrints Solutions Catalog, in the topic for passing context information. In a nutshell...here are some ways to pass a correlation ID: 1) Add a correlation ID parameter to the service interface. 2) Add a correlation id to the xml message payload. 3) Add a correlation id to the SOAP message. The pros and cons of each approach are discussed in the Solutions Catalog. alias: Where are you seeing the greatest SOA adoption? And, is that where it should be? What are the natural/logical applications (apart from what may or may not be actually happening)? Sameer Tyagi: I think a lot of organizations are still trying to figure out what SOA means to them, interpreting and trying to make sense of all the hype. The fact is that it has to be driven by service based development, which means a change in mind set for many. SOA must address the process (as in business activities performed), the environment (as in organization, people), the consumer and the dynamics of the interaction, the resources, the infrastructure and of course the technology choices. But keep in mind, SOA and web services are not the solution to every problem, and not every application in the enterprise needs this style (for example, applications in a realtime or high performance environment, applications that don't necessarily need loose coupling, etc). Applications that go across platform boundaries and the enterprise seem to be the typical candidates that customers use to drive SOA adoption in the organization. Guest: What are the main components of a development framework best suited for developing applications under SOA? Sean Brydon: Not sure exactly what you mean by framework? But the J2EE 1.4 SDK provides the platform for creating services. The J2EE 1.4 SDK has support for XML, SOAP, ws-i interop, JAXP, JAX-RPC, etc. This provides most of the components you need. You could try it at the Downloads page. moleary: Do you agree with the view that the domain model should attribute only classes or should the domain objects be rich in nature containing logic relevant to the domain model? Inderjeet Singh: If you are using object oriented technologies to create the domain model, it makes sense to make full use of object facilities while representing the domain model. So, it makes sense to include logic where appropriate. However, if the domain model is essentially auto-generated (for example, it is merely an object-relational mapping), there may not be much scope for adding additional logic. Scott: What tools do you recommend to developers when creating these types of applications? Are there any free tools currently available today to aid developers? Sameer Tyagi: The right tools are important to achieve developer productivity, time to market and ROI. The programming tools and IDEs need to give developers the facilities to expedite implementation of SOA and web services. Sun has a commitment to simplifying developer lives (see Java Studio Enterprise and other releases on Sun.com). You also need to look at other areas like web service testing, web services management and monitoring, and the tools you would use in that area. Inderjeet Singh: Scott, you may also want to check out the Kitty hawk announcement regarding what Sun will be doing for helping SOA development and deployment. pieoui: How (where) do you include business rules (as business object's methods? Somewhere else?) Sameer Tyagi: These would typically go in your component based model where you implement your business logic (think service implementation). bijal: In the presence of database abstraction technologies like Hibernate, where do you see the role of DAO pattern which has been designed to abstract out the underlying persistence storage? Inderjeet Singh: The DAO pattern provides a mechanism where a developer can plug-in a persistence mechanism of their choice. The technologies like EJB 2.0 CMP, Hibernate, and the upcoming EJB 3.0 specification reduce the need for using a custom mapping greatly. So, the pattern is useful in some limited cases where the standard technologies do not provide sufficient mechanisms. Al: Is there any JSR effort related to SOA? Inderjeet Singh: All the web services, the XML-related JSRs, and the J2EE platform JSRs are related to SOA. JSR 208 (Java Business Integration) is also relevant to SOA. Guest: Can you touch upon the portability of these types of applications? Any way of ensuring applications are portable to different server environments? Sean Brydon: Portability is easy if you follow the J2EE specification. Web services designed and deployed on J2EE 1.4 are also portable. Services in J2EE are just like any application in J2EE, they are portable if the application follows the J2EE 1.4 specification. Some of the key technologies available are briefly discussed in the latest BluePrints book, Designing Web Services with the J2EE 1.4 Platform, in Chapter 2. bijal: How much OO based design should we sacrifice in our pursuit of SOA? Do you see them existing side by side, in what proportions? Sameer Tyagi: I don't think they are mutually exclusive. Service-orientation is also an OO concept (think abstract data types), where the interface of your object is not just function calls but is based on messages. SOA abstracts that at a higher level. Sean Brydon: SOA and OO: In terms of web services there are some OO capabilities that are not available in an interoperable web service. For example, inheritance is not supported by ws-i. MDR-EdO: Well, we've quickly come to the end of our session. I thought we had a very nice set of questions -- thanks to all of you who submitted them. And special thanks to our guests, Inderjeet, Sean, and Sameer for their answers. Sean Brydon: Thanks for getting involved in the Java BluePrints Community! Inderjeet Singh: Thanks for participating in the chat. If you have any further questions, please send them to our mailing list, j2eeblueprints-interest@java.sun.com. Also, check out our latest java.net project, Java BluePrints Solutions Catalog. Sameer Tyagi: It was great talking to you, sorry we couldn't answer all the questions because of time. Please feel free to reach me at s.t@sun.com. If you want to move to SOA today, consider the SOA readiness assessment. MDR-EdO: Last moderator (me) signing off. The forum is now unmoderated. | ||||
|
| ||||||||||||
Print-friendly Version
