File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Web Services and the fly likes web service not available Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "web service not available" Watch "web service not available" New topic
Author

web service not available

Mohit Sinha
Ranch Hand

Joined: Nov 29, 2004
Posts: 125
Hi All,

We recently completed a java application and working on converting the same to web service. We have some specific java web services related question. The application is a plain java app(no web components or ejb).
I read somewhere we can deploy this deliverable in web service engine and don't require an app server as such. Can someone provide input on this.
Also what is the bundle type in such case a simple jar or ear file.

Another question is say if the web service is not available due to some reason but the jar/ear is deployed. How is this scenario generally taken care in the web service world. Like is it the responsibility of the web service client which on failure to connect to web service decides on alternative path or is there anything the web service (server deployed) can do

Regards,
Mohit
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41599
    
  55
The common web service engines are built around servlets (Axis, Metro), so you need a servlet container to deploy them, but no full JEE server.

As to the service not being available, I can picture two scenarios. Firstly, teh container/server itself might be down; in that case the client won't be able to connect and needs to take appropriate action.

Secondly, the container might be up, but the service is unable to function - maybe some other resource the service needs is unavailable. In that case the service should accept the connection, but return an appropriate error message to the client.


Ping & DNS - my free Android networking tools app
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
Mohit, what does the Java application actually do? Also, are there currently existing applications that will use these web services (implemented by the Java application)?

A web service enables applications to connect. It is an integration technology.

The application is a plain java app(no web components or ejb).
I read somewhere we can deploy this deliverable in web service engine and don't require an app server as such. Can someone provide input on this.


The application cannot be "deployed" in a SOAP engine as a web service. Unless the application only does one thing, you will need to extract the logic of something in the application that you want to share with another application and create the web service parts. So, depending upon what the application does, you might create many web serivces, or if there are no feasilble client applications, then you should not create any web services.

Another question is say if the web service is not available due to some reason but the jar/ear is deployed. How is this scenario generally taken care in the web service world. Like is it the responsibility of the web service client which on failure to connect to web service decides on alternative path or is there anything the web service (server deployed) can do


As mentioned, a client (application|component|object) should be designed to handle the failure of the web service.
Mohit Sinha
Ranch Hand

Joined: Nov 29, 2004
Posts: 125
Thanks Ulf and James.

So from the deployment perspective I understand the web service would be a war and can be deployed in a basic java web server(servlet container).

Regarding what the java app to be converted to web service does,functionality wise its one solution which does a lot of complex business logic in POJO's and communicates with the database (via OR mapper hibernate).

Mohit
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
So from the deployment perspective I understand the web service would be a war and can be deployed in a basic java web server(servlet container).


Not exactly. In terms of Axis-based web services, the Axis SOAP Engine is implemented with Java servlets and this is deployed and hosted on a Java-based web server.

The Axis SOAP Engine is deployed on the web server as a WAR.

Once the SOAP Engine is deployed, you then register the web services with the SOAP Engine via WSDD configuration files. The files that implement the web service are not in the WAR file of the SOAP Engine, they are in their own jar file that is in the classpath of the web server.

The execution path is:

client object ---> web server ---> SOAP Engine ---> web service ---> SOAP Engine ---> web server ---> client object

Hope this helps.
[ December 15, 2008: Message edited by: James Clark ]
Mohit Sinha
Ranch Hand

Joined: Nov 29, 2004
Posts: 125
Awesome response. That really cleared a lot of my misunderstandings.

So this is how JAX-WS is in general or what you mentioned in the above post is specific to AXIS.
Say when I start converting the java app to a web service (bottom up approach) do I have to take care of registering the web service to the soap engine specifics or these are taken care automatically by Axis tool support and in the end I get on complete deployable unit.
We are in the early stages and figuring out the easiest way of doing this. I also heard a lot of Xfire.
Can you suggest the best in business tools for the same.

Thanks Again
Mohit
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Originally posted by Mohit Sinha:
Regarding what the java app to be converted to web service does,functionality wise its one solution which does a lot of complex business logic in POJO's and communicates with the database (via OR mapper hibernate).


But what form of input drives this application? You already ruled out component calls (ejb) and web calls (servlets) which leaves GUI, command line, file input or database input (i.e. batch). This is important because this can effect the style of the web service that you want. Everybody assumes that you are talking about SOAP web services because they are well established. If however you are trying have web service support for an AJAX-style web interface then JSON-over-HTTP or RESTful web services may actually be a better fit.

But regardless of the style of web service that you need, don't expect the establishment of the web service to only require minimal effort. You still need to design your interface to the web service provider with the needs of the web service consumer in mind. Also the business logic in your POJOs in your existing application may not be easily reused inside the service implementation (which is what James was trying to elude to). There may be some considerable rework required so that both implementations can share the same logic.

And, as James also pointed out, there is no one, universal form of deployment for web services. The deployment depends on the style of web service that you choose and the implementation of the web services stack. The only thing that all of them have in common is that they require some form of web server somewhere. And there are cases where that web server should not be servlet container (pre-servlet 2.4 API to be specific) - like web services to support a Comet web application (common for AJAX front ends). NIO-based servers like Grizzly or Apache MINA are better suited for that kind of task.

And regardless of the web service style and web service stack, the consumer (client) has to take responsibility for taking the appropriate actions whenever it cannot connect to the web service provider or when the web service provider returns an error (as Ulf has already pointed out) - but that is simply the nature of client responsibility in the case of remote invocation in a distributed environment; web services technology hasn't changed that and it is highly unlikely that any future remote invocation technology will ever change that.
Mohit Sinha
Ranch Hand

Joined: Nov 29, 2004
Posts: 125
Thanks Peer.

---------------
Everybody assumes that you are talking about SOAP web services because they are well established.
----------------
Yes I am talking about SOAP/WSDL combination web services only (JAX-WS approach).

---------------------------
But what form of input drives this application? You already ruled out component calls (ejb) and web calls (servlets) which leaves GUI, command line,
file input or database input (i.e. batch). This is important because this can effect the style of the web service that you want.
-----------------------------
This is currently the client responsibility to whom we are delivering this solution. Since we are in the early stages we are not sure about the WS client type (but it could be either a web app or another web service. This Client hates EJB )
I am not really understanding how the WS client type can impact the way a WS (server component) is developed. Isn't this purported feature of web services i.e. the web service can cater to any client request type w/out any hassle.

The application we are developing falls under a niche business expertise. Clients generally use it as part of their business application stack and it is always nested among other client applications and part of their workflow process
-------------------
You still need to design your interface to the web service provider with the needs of the web service consumer in mind.
Also the business logic in your POJOs in your existing application may not be easily reused inside the service implementation (which is what James was trying to elude to).
There may be some considerable rework required so that both implementations can share the same logic.
--------------------
The whole purpose of taking the web service route in our case is from invocation perspective so the client calling application can easily communicate with the application in question. With respect to the application underneath it is exposed via an interface which comprises a single method with custom java objects as method parameters. This single method is implemented by an Impl class. This Impl class just orchestrates the flow of our business logic components which are neatly layered. Whatever these business components need will be provided by the Impl class which just delegates the incoming input and invokes the business components in a synchronized workflow style.
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
Thanks. Great questions

JAX-WS is a specification. Apache Axis is an implementation of one part of the specification (the runtime). There are other parts of JAX-WS.

Yes, you have to register the web service with the SOAP Engine, as I mentioned earlier.

You must first identify that you need a web service. Are their client applications that will use this web service? If no, then what are you developing a web service for. If there are client applications that will use the service, you need to analyze them all to determine the best way to design the interface for the service, i.e. coarse-grained, fine-grained, data-oriented, process-oriented, indempotent, etc.

Then you need to determine how you will mange the service and establish policy. All this should take place way before you start thinking about tools.

In regards to tools, check out CentraSite and IBM's Federated Enterprise Service Bus.
[ December 15, 2008: Message edited by: James Clark ]
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Originally posted by Mohit Sinha:
SOAP/WSDL combination web services only (JAX-WS approach).


Just be careful - there is a reason why web service annotations have a nickname of "web service magic pixie dust".

This Client hates EJB )


Well, that probably also means that the client is also "in line" to soon hate SOAP/WS-*

In terms of the "technological adoption curve" SOAP/WS-* is tracking EJB pretty closely, i.e.:
  • Initial hype towards making distributed computing easy (and interoperable (in the case of EJB between different Java Enterprise vendors)).
  • Initial quick adoption by "high end clients" with specific requirements and deep pockets.
  • Technology assimilates more and more complexity as it gains more capabilities geared towards the "high end clients" with their specific requirements.
  • "Mainstream clients" become disenchanted with the added complexity that they now have to deal with even though they only have much more general and simpler requirements.
  • "Mainstream clients" give up on the technology and move to simpler "disruptive" technologies.

  • RPC and REST Dilemma, Disruption, and Displacement (PDF)

    EJB gave rise to Hibernate and Spring which ultimately reduced the importance of EJB. The same thing is happening now to SOAP/WS-* as it is being undercut by the other web service types. I'm just waiting for somebody to publish the "Service-Oriented Development without SOAP/WS-*" book (the SO equivalent to Rod Johnson's "J2EE Development without EJB").

    I am not really understanding how the WS client type can impact the way a WS (server component) is developed. Isn't this purported feature of web services i.e. the web service can cater to any client request type w/out any hassle.


    This isn't the first time that technology has been over-hyped. If, for example, your application was a GUI application and you were looking to move to a comet web application you may think [web services == SOAP]. JavaScript clients can technically consume SOAP web services. However they much rather consume JSON rather than SOAP/XML and they really don't get the benefit of the SOAP overhead. Furthermore comet web applications tend to use long-standing HTTP requests for which the servlet architecture is an ill fit as servlets were designed around the notion that you would always want to be returning responses as quickly as possible - rather than have them hanging around. So a SOAP web service stack running in a servlet container would not be a prime candidate for a comet web application. This is one of the reasons IBM has embarked on Project Zero where services are exposed as a collection of web resources rather than SOAP endpoints.

    Furthermore there are many mistakes that you can make on the web service provider side that can give some web service consumers, um..., indigestion.

    With respect to the application underneath it is exposed via an interface which comprises a single method with custom java objects as method parameters.


    This sounds an awful lot like you "want to beam your objects over the inter/intranet" with the help of SOAP web services - this is a starting point for many web service projects that cause a lot of suffering and anguish and ultimately have disappointing results. You already have your Java-based logic and you want to expose it as a web service - the typical "contract last" approach. To find out why that is a bad idea have a look at Why Contract First?. Even if you use "contract-last" - your "precious Java objects" will not appear on the consumer side. The consumer-side SOAP web service stack will merely generate object-approximations of the payloads of the various legal SOAP messages that can be exchanged between the provider and consumer (in the case of a non-Java consumer Java objects wouldn't make any sense anyway) and those payloads are XML documents - not objects.

    And in terms of service-oriented development "service contract design" always comes before "service logic design". "Bottom-Up Delivery" refers simply to an analysis approach that narrows its analysis scope to the immediate project requirements rather than the prior establishment of a service inventory blueprint typical of "Top-Down Delivery".

    This Impl class just orchestrates the flow of our business logic components which are neatly layered. Whatever these business components need will be provided by the Impl class which just delegates the incoming input and invokes the business components in a synchronized workflow style.


    Services are not equivalent to components. Typical service models are the utility service, business entity service and task service. The business entity service is the most common type of service. With SOAP web services the business entity's public manifestation is the entity's XML document. Oddly enough a characteristic of a good business entity's design is that it is agnostic: it only encapsulates functionality that is not specific to any one application or business process. So often business entity services will only have operations that create, retrieve, update and delete entities and mainly encapsulate logic to enforce internal constraints of the entities in the context of these operations (this is what makes business entity services so reusable). Task services are the ones that orchestrate or choreograph the entity services to realize business processes; that is what makes task services non-agnostic and less reusable.

    So by your description your logic cannot be represented by one service - it sounds like you need multiple services. Also don't make the mistake of thinking [DB table row == EJB entity == SO Entity]. Typically service-oriented entities are coarser grained than DB table rows or EJB entities - e.g. if you want to look at a PO line you'll probably have to get the entire PO entity.
    [ December 15, 2008: Message edited by: Peer Reynders ]
    Mohit Sinha
    Ranch Hand

    Joined: Nov 29, 2004
    Posts: 125
    From the business standpoint this app is one service. It caters to some specific business complexity. The components comprised within this app will not hold much value individually.

    From the above post what I gather converting this application to expose as web services is not the right way to go.
    Typically we package this solution as a core java app and is integrated in client systems. This time around we have a specific requirement to expose the same as web service endpoint using the jax-ws (soap/wsdl) stack.
    Are you saying this will not work for our case.


    Mohit
    Peer Reynders
    Bartender

    Joined: Aug 19, 2005
    Posts: 2922
        
        5
    Typically we package this solution as a core java app and is integrated in client systems


    Which means it usually is only available to a Java client - so any Java/OO specific idioms aren't going to matter.

    This time around we have a specific requirement to expose the same as web service endpoint using the jax-ws (soap/wsdl) stack.


    Technically speaking that is not a "requirement" - that is a solution approach. What problem are you trying to solve? There is no point to a service that doesn't have a consumer. Most of the time interoperability is the goal when web service solutions are being sought. With a web service you create the opportunity for non-Java clients to use your solution. However if your solution exposes itself through a Java/object centric design it may very restrict its potential audience to clients which use a (Java) JAX-WS stack. Furthermore all information is exchanged in XML - XML can only carry semi-structured data (no behavior like objects) and is notoriously bad at representing object cycles. The point is that to realize a web services full potiential you have to design it as a web service that non-JAX-WS clients can consume. That means you do not simply crank out an OO model and sprinkle it liberally with annotations. You design the various data entities that are exchanged between the consumer and the provider "to conduct their business" (capture them in an XML schema) and then use them in your web services contract (WSDL). For such a design you have to know what the web service consumers needs are - the already existing object model is often not a good starting point for an effective web service contract - it just happens to be the easiest for developers who have been developing Java applications.

    Are you saying this will not work for our case.

    Of course it will "work" - however the value of the outcome of such an effort could be dubious - and may be a bit of a maintenance headache.

    Your have to understand that JAX-WS is a web service stack - a framework to build SOAP web services in Java.
    That doesn't mean that the resulting service has the license to force Java, components, and object-orientation "onto the rest of the (SOAP) web service world" (including its consumers). SOAP web services are a separate paradigm - therefore the design of the service needs to fit that paradigm.
    Jimmy Clark
    Ranch Hand

    Joined: Apr 16, 2008
    Posts: 2187
    From the business standpoint this app is one service. It caters to some specific business complexity. The components comprised within this app will not hold much value individually.


    What would be the output of the "web service" which a client application would use or display?

    If a non-Java, remote client application needed to execute the processing, then it could do so via SOAP web service. The service would execute the processing and return a return code, e.g. succeeded, failed

    If a Java-based, remote application needed to execute the processing, then it could do so via SOAP web service.

    If many applications needed to execute the processing that this application executes, it could do so via SOAP web service.

    If there are no client applications that need to execute the processing, there is no need for a web service.

    The web service can be designed to enable client applications to execute the application by (1) sending a JMS-based message and have a message consumer then call the web service via SOAP message, or (2) directly calling the web service via HTTP URL.

    The best bet, for loose coupling, is to set up a set of message queues and have the client applications send the SOAP request to the message queue. Message listeners will listen for the messages and forward the SOAP message to the web service.
    Mohit Sinha
    Ranch Hand

    Joined: Nov 29, 2004
    Posts: 125
    Currently the output sent back to the client is a custom java object.
    I understand the external apps consuming this web service would be java based.
    When you say "via SOAP web service" I infer this as "soap based web service" which acts as a client to the "web service" server app in question.

    May be I did not elaborate enough but why do you feel I am talking about
    building web service with no clients to consume the same.
    What I meant is we will build the web service(producer) where as the responsibility of constructing a web service consumer lies with the client organization.
    Earlier I said no web component because a UI app does not serve the purpose. It will only end up being a test harness without any real production value. This is more back-end centric
    kind of application which provides specific business intelligence to existing applications.

    Thanks again for all the detailed explanations.

    Mohit
    Peer Reynders
    Bartender

    Joined: Aug 19, 2005
    Posts: 2922
        
        5
    Originally posted by Mohit Sinha:
    What I meant is we will build the web service(producer) where as the responsibility of constructing a web service consumer lies with the client organization.


    Understood. However whenever you have two development teams working on opposite sides they still need to agree on an "interface" - in the case of a web service - the web service contract. All you currently have is a "custom java object".


    I understand the external apps consuming this web service would be java based.


    OK. But why is a web service solution required? There are other ways of having communication between a Java client and a Java server. Is potential interoperability with non-Java clients an issue? If yes, it needs to understood that interoperability with web services doesn't happen by default. There are many mistakes that can be made on the provider side that can restrict consumers to particular platforms and even web service stacks. Interoperability needs to be deliberately pursued and verified.

    Currently the output sent back to the client is a custom java object.


    Well, that custom object better have particular characteristics because you have to keep in mind:
  • The SOAP envelope payload is simply an XML document
  • The client is generated from the WSDL that is published by the web service endpoint - it not based on your custom Java object. So the client artifacts may have little resemblance to your Java objects.


  • So
  • Your custom classes better not encapsulate any behavior - XML can only transfer data, no code, no objects. The data will be merely bound to the generated client side class artifacts - classes that are not equivalent to your Java classes. So your custom Java classes better resemble DTOs.
  • Any object graphs inside the custom java class cannot contain cycles (XML is hierarchical).
  • In general object members should be other custom object types or Java types with standard mappings (JAXB Mapping of XML Schema Built-in Data Types). Even standard collection types can be problematic - Lists are reduced to arrays while Maps require special handling (Mapping your favorite class)


  • Ideally you should take that "custom java class" and decompose it to the public data that comprises its content and organize this data into an (hierarchical) XML document. Capture the document's structure in an XML Schema definition - and only use the most commonly used XML Schema features to do so. That is, avoid more advanced features like enumerations, inheritance, restriction, etc. Just because these features are in XML Schema and JAX-WS supports them doesn't mean that "an arbitrary client's" SOAP web service stack will support them. So don't be tempted to mimic your own solution object model in the XML schema - simpler is better. Once you have that document defined you can use it in the web service contract (WSDL) and wsimport can generate an equivalent object representation for the XML document. Now use your service logic to populate that "equivalent object representation" before you return the result to the client. (Note that all of this assumes a document/literal SOAP web service). These are the type of tactics that you have to employ to maximize the opportunity for interoperability.
    Mohit Sinha
    Ranch Hand

    Joined: Nov 29, 2004
    Posts: 125
    Thanks again, Peer.

    The scenario we have is exactly similar to the way you described in the last post. The output custom object is a DTO in nature. No operations in it.
    The reason we are going with web services as I have mentioned earlier is because of client required this offering as a web service solution.
    At this juncture I have very little information on the type/number of client applications consuming this solution.
    As you state we do not have circular kind of references in the custom java output object and should fit in well with XML's hierarchical nature.

    ------------------------
    Once you have that document defined you can use it in the web service contract (WSDL) and wsimport can generate an equivalent object representation for the XML document. Now use your service logic to populate that "equivalent object representation" before you return the result to the client. (Note that all of this assumes a document/literal SOAP web service). These are the type of tactics that you have to employ to maximize the opportunity for interoperability.
    -------------------------
    You mean to say change the current output object to use the one as created above (generated via wsimport).


    ----------------------
    OK. But why is a web service solution required? There are other ways of having communication between a Java client and a Java server.
    -----------------------
    EJB/RMI sort of solution is ruled out. What are you hinting at when it comes to communication between distinct applications.


    Mohit
    Peer Reynders
    Bartender

    Joined: Aug 19, 2005
    Posts: 2922
        
        5
    Originally posted by Mohit Sinha:
    You mean to say change the current output object to use the one as created above (generated via wsimport).

    Correct - at least in the SOAP web service situation.

    EJB/RMI sort of solution is ruled out.

    So "SOAP web services" was chosen as the lesser of two evils? This still fails to illuminate why exactly SOAP web services are considered to be a superior solution for your particular type of problem (which is exactly?).

    What are you hinting at when it comes to communication between distinct applications.

    For example, many anti-EJB shops use Spring which offers a variety of solutions, the most interesting of which is the HttpInvoker which uses the HTTP protocol and Java's own serialization mechanism (Example App); this type of solution allows you to stay entirely in the "Java Universe".

    My main point and concern is that somebody may have chosen "SOAP web services" because of the supposed potential of "universal accessibility" (interoperability), regardless of platform. That kind of potential can only be realized if the SOAP web service is developed in the appropriate manner (contract first) - it doesn't happen when SOAP-over-HTTP is simply used as a remoting protocol for an existing Java application/component (contract last).
    Mohit Sinha
    Ranch Hand

    Joined: Nov 29, 2004
    Posts: 125
    Hi Peer,

    I keep learning more and more from your insightful responses as I keep reading them again and again. There are couple of your thoughts which I wanted to understand in more depth.

    You mention in one of the above post
    =========================
    Services are not equivalent to components.
    =========================
    Typically what is criteria for qualifying a piece of functionality as a Service. Can some components be elevated to be defined as a Service or is it that a functionality piece can be a component for one solution and behave as a service in another. Is it totally business orientation or coarse granularity that decides a particular functionality is a service?
    I was looking for some examples to get this distinction clearly but could not find anything pertaining to the same. Most SOA articles tend to be theoretical, none explain practical scenarios what can be a service and what cannot.
    What should only remain a component and should not be confused to be made as a service.

    You also mention
    ===============
    SOAP/WS-* as it is being undercut by the other web service types.
    ===============
    I believe you are referring to REST here. Is there anything that has caught your attention and provides a more efficient/easier way of doing things than in SOAP/WS* world.


    Regards,
    Mohit
    Peer Reynders
    Bartender

    Joined: Aug 19, 2005
    Posts: 2922
        
        5
    Originally posted by Mohit Sinha:
    What should only remain a component and should not be confused to be made as a service.


    It has more to do with the design approaches that are taken. As a result a well designed service could be converted to a component and you would still have well-designed component - the reverse is not necessarily true. Best practices for service design tend to apply to components as well, but given the environment that components are deployed in, component-designers take liberties that service-designers just shouldn't take. Just like it is possible to build an object-oriented solution in Ada, it is also possible to build a service-oriented solution with components - as long as service-oriented principles are adhered to and as long as you accept the "hard limitations" that your component technology imposes.

    At this point you should notice that you are building a service-oriented solution in an object-oriented language (Java) which creates an impedance mismatch right from the start - there is no such thing as a "service-oriented" language. There doesn't need to be. Service-orientation focuses on the environment that the services exist in and how those services (through messages) interact - it doesn't care how the service logic is implemented.

    So the differences between services and components can be observed in two areas:
  • Components tend to be finer-grained than services.
  • Component clients tend to be more tightly coupled to their components than (ideally) service consumers are coupled to their service provider.


  • Granularity:

    Lets look at a pseudo service contract definition for a purchase order service (normalized):


    Sidenote: If you are wondering why you need PoDelIdDoc and PoUpdDoc then you have to remember that document-oriented services don't have operations - the document type determines the operation - so the above could just as easily be:



    Now we can denormalize the Purchase Order service and end up with:


    This denormalized version exposes the finer-grained operations getItem, getHeader, updateItem, and updateHeader which in effect duplicate functionality that can be covered by the "get" and "update" operation. While there are sometimes reasons to allow this type of denormalization in a service, exposure of finer-grained functionality is usually a characteristic of a component. The interface is more detailed and there is more for the consumer to get coupled to. So a technical contract like the one represented by PoDenorm is more typical for a component while PoNorm is more typical for a service.

    PoNorm creates "more work" for the consumer as it has to retrieve and navigate the entire PO to access a single line item. PoNorm creates potentially "more work" for the provider because it may have to on "update" compare the update values in the update document to the current values of the PO to determine the necessary cascade actions to make a consistent update to the underlying PO. For example, the component-style PoDenorm contract makes it easy to detect changes to the headers or items because they would happen through the updateHeader and updateItem operations; the service-style PoNorm contract has to detect these changes through inspection of the contents of PoUpdDoc (and possibly the current state of the PO). So the coarser grain interface of PoNorm may require more logic but also reduces the consumer's dependencies on finer-grained functionality and therefore its coupling.

    Coupling:

    Obviously components like Java EJBs and .NET Enterprise Services (COM+) exhibit Contract-to-Technology coupling as their technical contract is based on proprietary communications technology. Ideally services should be decoupled from vendor-specific technology as supported by the use of, for example, open XML and web service standards.

    Components tend to exhibit Contract-to-Implementation coupling (the coupling of the service contract to its implementation environment). For example, platform specific types, structures, and idioms are exposed in the service contract (other than just basic types or custom types that are composed of basic types).

    Components often can exhibit Contract-to-Logic coupling if their logic is designed before their contract (interface) is defined. Services can exhibit the same kind of coupling but contract first development is supposed to avoid that. For both components and services this is simply an issue of "separation of concerns" - in this case the separation of the interface from the implementation.

    Component design is often guided by object-oriented design principles which have some commonalities with service-oriented design principles. However there are also important differences.
  • Service-Orientation does not support the notion of service inheritance as this would reduce service autonomy.
  • Because of the lack of inheritance, generalization and specialization actually refer to a different characteristic under service-orientation. Coarser grained (more generalized) services can sometimes be decomposed into finer grained (more specialized) services.
  • Because of the lack of inheritance, polymorphism isn't supported by services. There can't be an "Abstract" service. The closest parallel to polymorphism are identically named capabilities across numerous services, e.g. consistent use of standardized verb-based, CRUD-style operations within entity services.
  • "Composition" in service-orientation doesn't imply an ownership structure between services like it would in object orientation. One service cannot own another. "Aggregation" ("has-a") doesn't even apply. One service can merely "use" another
  • Services need to remain stateless and delegate management of state.


  • So all of the above is supposed to build a case for "Services are (ideally) coarser-grained and more loosely-coupled than Components" and that their differences lie mainly in the differing manner in which components and services are (supposed to be) designed.


    I believe you are referring to REST here. Is there anything that has caught your attention and provides a more efficient/easier way of doing things than in SOAP/WS* world.


    Well, (POX) XML-over-HTTP and JSON-over-HTTP have their place too. What makes RESTful web services so interesting is that they are a better match for services on "the web". The majority of services are "entity services" anyway which tend to have a READ,UPDATE,DELETE interface which matches the HTTP verbs GET, PUT, and DELETE - this is the reason why RESTful web services have been seen as an ideal implementation for "data services" (though more can be done with them once you can wrap your head around it). In such a case RESTful web services can be more "effective" but that doesn't necessarily mean that they are an "easier or more efficient way of doing things" from the development perspective. It's often "easier" to use the code generators that are part of the WS-* based development environments - but that doesn't make it the "correct" approach.

    And furthermore, just like there is an impedance mismatch between object-orientation and service-orientation, there is also an impedance mismatch between object-orientation and resource-orientation. You will still have to re-think how to approach the design of a resource-based web service.

    Transitioning From Object-Oriented to Resource-Oriented Programming is a bit extreme, but it makes a point.
    [ December 22, 2008: Message edited by: Peer Reynders ]
     
    Don't get me started about those stupid light bulbs.
     
    subject: web service not available