I am currently dealing with semantic descriptions of web services, OWL-S more specifically. I'm not manually writing the annotations, I use this tool.
My point is not the annotations per se, but to know how close 2 web services are. So my idea was to try and compare their respective OWL-S descriptions.
What I'm looking for is maybe a matcher, an API (Java or Python) that would allow me to match two .owl files.
UPDATE : This is just my idea. If you can suggest something else that serves the same purpose you are welcome.
You could try LogMap, it's a framework for ontology matching. You can try it from the web interface. In case of problem you can contact directly the authors of the tool too.
Related
I have a situation where two components are being designed that have some similar presentation requirements, but have been built using different technology stacks (one is java and the other is .net). For one feature, the developers are propsing using a web service that returns HTML so that both components can re-use the same display logic. I have been told that it is a bad practice to use a web service in this fashion, and that a web service should focus only on data.
In terms of web-service or SOA best practrices, should you return HTML from a web service?
If it's actually a web service (i.e. meant to be called by scripts), HTML is a bad idea, as you'll have a difficult time handling error situations.
A well-designed XML or JSON answer is probably the way to go these days.
Which approach (Contract-First/Code-First) should be used when creating Web services with Apache Axis2? If I choose the contract-first approach, which tool should I use to create wsdl? I am using the WSO2 platform.
Contract-first is the best approach IMHO. The reason is quite simple. When you code first and generate a WSDL, it might change. This may cause problems for other teams working on client code based on that WSDL.
In case of contract first, the WSDL will always be the subject of discussion between teams, and it will not just change because of code changes, but only when all parties agree.
It is best to use versioning in it as well.
You can create a WSDL in Eclipse, which also has excellent checks (requires internet access).
Definitlety contract first.
Interfaces are the way to go for strong typed web services.
I am a noob to web services world. I need to develop a login validator module and expose it as a service. I want it to be service independent, i.e I should have the option of exposing it as a SOAP service or REST service in the future.
What pattern should I follow ? Sorry if I am unclear in my requirements, I can clarify as per need.
Thanks !!
Edit : I am using Eclipse as an IDE and Jersey libraries. I am not into any framework, simply using the MVC pattern. I find a lot of difference between SOAP ann REST methods, so I want my methods to be implementation independent - i.e I should be easily able to use my method through a SOAP or REST service call as per need. What should I do for maximum flexibility ?
Picking a good MVC framework and understanding how to use it properly can help ensure that your feature is "service independent". Most of the documentation I've read for good frameworks suggest that you keep your business logic separate from your controller.
If you read the documentation for the tools that you use, and ensure that there is a layer between your business logic and your controllers, then that will make the job of switching from SOAP to REST or some other protocol much, much easier.
Since you mentioned you're using Eclipse in your comment below, I'm assuming you are using or are willing to use Java:
Restlets
http://www.restlet.org/
Spring 3.0 REST
http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/
Develop your service as a POJO. Make sure to respect staless pattern.
Create an EndPoint class for each publication type you require (Soap, Rest, EJB, JMS, what ever)
Use appropriate standard to expose your EndPoint. For Soap and Rest the JAX-WS api and implementations can do it for you using java annotations on your EndPoint.
That's it !
This is quite a concept idea. I would like to create a website that can be extend by different programmer a bit "a la facebook"
Let's me explain i want to develop a very simple core application that for example would store images and i want to develop or allow external developer to develop web app that would be able to act on the image i can take this example of an OS that would store files and you can "install" different program for example to view the files or edit.
How can i reproduce the model in the Web / cloud plateform using API ?
I hope this question make sense to any body.
Thank you by advance
Web Services. Try looking up REST and SOAP.
The Semantic Web is trying to solve this by publishing structured data with common ontologies.
See this example, describing the user's photos as RDF, using the FOAF ontology:
http://www.semanticoverflow.com/questions/201/describing-in-a-foaf-file-assets-of-a-user-photo-album-video-album-etc
The Semantic Overflow website is an excelent resource to find out more about the semantic web in general, and how creating webservices that use a common set of interfaces can allow a greater reach, because tools don't have to be specific to a website.
My gut feel is that document based web services are preferred in practice - is this other peoples experience? Are they easier to support? (I noted that SharePoint uses Any for the "document type" in its WSDL interface, I guess that makes it Document based).
Also - are people offering both WSDL and Rest type services now for the same functionality? WSDL is popular for code generation, but for front ends like PHP and Rails they seem to prefer rest.
Document versus RPC is only a question if you are using SOAP Web Services which require a service description (WSDL). RESTful web services do not not use WSDL because the service can't be described by it, and the feeling is that REST is simpler and easier to understand. Some people have proposed WADL as a way to describe REST services.
Languages like Python, Ruby and PHP make it easier to work with REST. the WSDL is used to generate C# code (a web service proxy) that can be easily called from a static language. This happens when you add a Service Reference or Web Reference in Visual Studio.
Whether you provide SOAP or REST services depends on your user population. Whether the services are to be used over the internet or just inside your organization affects your choice. SOAP may have some features (WS-* standards) that work well for B2B or internal use, but suck for an internet service.
Document/literal versus RPC for SOAP services are described on this IBM DevelopWorks article. Document/literal is generally considered the best to use in terms of interoperability (Java to .NET etc). As to whether it is easier to support, that depends on your circumstances. My personal view is that people tend to make this stuff more complicated than it needs to be, and REST's simpler approach is superior.
As mentioned it is better to choose the Document Literal over RPC encoded whenever possible.
It is true that the old java libraries (Axis1, Glue and other prehistoric stuff) support only RPC encoded, however in today's most modern Java SOAP libs just does not support it (e.x. AXIS2, XFire, CXF).
Therefore try to expose RPC encoded service only if you know that you need to deal with a consumer that can not do better. But then again maybe just XML RPC could help for these legacy implementations.
BiranLy's answer is excellent. I would just like to add that document-vs-RPC can come down to implementation issues as well. We have found Microsoft to be Document-preferring, while our Java-based libraries were RPC-based. Whatever you choose, make sure you know what other potential clients will assume as well.